幹壞事是進步最大的原動力
在 Twitter 上看到 OS X 接藍芽耳機時的音質問題：
开启Mac蓝牙的aptX和AAC 编码支持。https://t.co/YdcuXeZlKE
sudo defaults write bluetoothaudiod "Enable AptX codec" -bool true
sudo defaults write bluetoothaudiod "Enable AAC codec" -bool true
靠，音质提升立竿见影啊，我的狗耳都能听出来，为啥 Apple 这两个不是默认开启的。坑啊。 pic.twitter.com/Ztv4zrwBXX
— Leask Wong (@Leaskh) March 22, 2018
看了一些討論，看起來除了蘋果自己的耳機外，其他家的藍芽耳機不一定會開 AAC 或是 aptX。雖然現在沒有其他家的藍芽設備，但以後如果買了要注意一下...
Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」，或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇)，最近在 ARM 上發現 jpegtran 的效能不是太好，花了不少力氣最佳化，發現有意外收穫：「NEON is the new black: fast JPEG optimization on ARM server」。
他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%，但發現只有 26% 左右的效能：
Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.
In this case, however, I was disappointed to discover an almost 4X slowdown.
而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速，於是作者就想到，把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助：
Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?
而 porting 完後重新測試發現達到了 66% 的效能，已經超過本來的目標... 另外在批次處理中，也比 Xeon 快了：
繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能)，也許能提供更進一步的加速：
While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.
如果再把這些指令實做出來，會發現單 core 的效能已經到 Xeon 的 83%，而批次的速度又提昇了不少：
最後是整台伺服器都跑滿時的測試，會發現整台的效能差不多 (其實 ARM 的版本還贏一些)，但吃電量不到一半，而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題)，用電效率來到 6.5 倍：
With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.
這篇在提醒之後在 ARM 上寫最佳化時，不要只從 SSE porting 到 NEON，要多看一下有沒有其他指令集是有幫助的...
在「FTC Warns Companies ‘Warranty Void if Removed’ Stickers Are Flatly Illegal」這邊看到的新聞。FTC 的新聞稿則可以在「FTC Staff Warns Companies that It Is Illegal to Condition Warranty Coverage on the Use of Specified Parts or Services」這邊看到。
主要是因為美國的聯邦法 Magnuson–Moss Warranty Act (在 STATUTE-88-Pg2183.pdf 這邊可以看到條文 PDF，雖然看起來是掃描的圖檔，但有透過 OCR 處理讓大多數的文字都可以搜尋)。
這套聯邦法保護消費者在接受保固時不受嚴苛的限制。法條裡面並沒有強制規定一定要有保固，但規定了如果有保固時，有哪些行為是受到規範的，以避免消費者受到不平等的對待：
The law does not require any product to have a warranty (it may be sold "as is"), but if it does have a warranty, the warranty must comply with this law. The law was created to fix problems as a result of manufacturers using disclaimers on warranties in an unfair or misleading manner.
其中這段條文讓 FTC 認為「拆封喪失保固」違法：
(c) No Warrantor of a consumer product may condition his written or implied warranty of such product on the consumer's using, in connection with such product, any article or service (other than article or service provided without charge under the terms of the warranty) which is identified by brand, trade, or corporate name; except that the prohibition of this subsection may be waived by the Commission if—
(1) the warrantor satisfies the Commission that the warranted product will function properly only if the article or service so identified is used in connection with the warranted product, and
(2) the Commission finds that such a waiver is in the public interest.
在 FTC 的新聞稿中提到他們發給六家警告，列出了其中三家的文字，在媒體的報導裡面也都找出來這些文字分別是從哪些公司出來的，包括了 Hyundai (現代)、Nintendo (任天堂) 以及 Sony (索尼)：
“The use of [company name] parts is required to keep your… manufacturer’s warranties and any extended warranties intact.” = Hyundai.
“This warranty shall not apply if this product… is used with products not sold or licensed by” = Nintendo.
“This warranty does not apply if this product… has had the warranty seal on the [product] altered, defaced, or removed” = Sony.
不過在另外一邊，Reddit 上 Nintendo 區的討論也蠻有趣的：「FTC Staff Warns Companies that it is Illegal to Condition Warranty Coverage on the Use of Specified Parts or Services : nintendo」，裡面就稍微扯遠了一些，提到了改機之類的保固問題...
另外值得一提的是，同一家媒體在 2016 年的時候就有報導類似的事情了，不過看起來當時沒什麼改善：「Microsoft, Sony, and other companies still use illegal warranty-void-if-removed stickers」，這次由 FTC 出手應該會再更有力道一些。
前陣子在「Rent out your GPU compute to AI researchers and make ~2x more than mining the most profitable cryptocurrency.」這邊看到的消息，服務網站是「Vectordash: GPU instances for deep learning」。
起因是搞計算的弄不到顯卡計算，而雲服務的 GPU 又太貴，所以再找方法解決... 結果注意到 cryptocurrency 計算的獲利與雲服務的 GPU 中間有不少差價，於是就弄出一個服務來媒合手上有顯卡與需要科學計算的人，一邊提供較高的獲利給本來在挖礦的人，另外一邊提供較低的價錢給需要科學計算的人。
目前支援的平台有限 (Nvidia 的顯卡，另外不支援 Windows，不知道是不是 Linux only)，其他支援目前都還沒列 ETA，不過感覺是個解決大家痛點的服務 (而且挖礦這邊就是在拼獲利)，應該有機會弄得很大...
繼續觀望... XD
去年年底的時候 Percona 的人在 AWS 上測試 Percona XtraDB Cluster 的效能，尤其是針對底層應該選擇哪種 EBS 的部分給了一些建議。可以參考先前寫的「Percona 分析在 AWS 上跑 Percona XtraDB Cluster 的效能 (I/O bound)」這篇。
當時的建議是用 io1，雖然是比較貴，但對於效能比較好。
而後來 Percona 的人收到 AWS 工程師的建議，可以用另外一個方式，可以在 gp2 上拉出類似的效能，但成本會比 io1 低不少：「Percona XtraDB Cluster on Amazon GP2 Volumes」。
這個方式是利用 gp2 會依照空間大小，計算可用的 IOPS。在官方的文件裡是這樣描述 gp2 的效能 (IOPS)：
General Purpose SSD (gp2) volumes offer cost-effective storage that is ideal for a broad range of workloads. These volumes deliver single-digit millisecond latencies and the ability to burst to 3,000 IOPS for extended periods of time. Between a minimum of 100 IOPS (at 33.33 GiB and below) and a maximum of 10,000 IOPS (at 3,334 GiB and above), baseline performance scales linearly at 3 IOPS per GiB of volume size. AWS designs gp2 volumes to deliver the provisioned performance 99% of the time. A gp2 volume can range in size from 1 GiB to 16 TiB.
在這個前提下，需要 10000 IOPS 的效能會需要 3.3TB 以上的空間，所以 Percona 就被 AWS 的工程師建議直接拉高空間重新測試：
After publishing our material, Amazon engineers pointed that we should try GP2 volumes with the size allocated to provide 10000 IOPS. If we allocated volumes with size 3.3 TiB or more, we should achieve 10000 IOPS.
首先是測出來的效能，可以看到沒有太大差異：
接下來就比較儲存成本，大約是 io1 版本的一半價錢：
如上面文件中提到的，gp1 不完全保證效能，但統計出來經常能夠提供出 3 IOPS/GB 的效能。而 io1 則是保證效能，不太需要擔心效能不穩定的問題。就是這個差異，反應到成本上面就有蠻大的差距。善用這點設計系統，應該會對整體成本有蠻大的幫助... (但對 latency 就未必了，尤其是 P99 之類的數值)
算是另外一種搞法讓大家可以考慮...
在 Twitter 上看到 Matthew Prince (Cloudflare 的創辦人與現任 CEO) 提到了目前的進展，貼出一張兩者用電量的差距 (235W 與 150W)：
Why we’re switching to ARM-based servers in one image. Both servers running the same workload at the same performance. pic.twitter.com/wMFKS0Avkt
— Matthew Prince (@eastdakota) March 21, 2018
兩者差了 85W，如果以五年來算就差了 3723 度的電，另外再考慮 PUE 與機櫃空間租用的成本，長期應該是頗有機會換掉原來的 x86 系統。反過來看，短期有轉換測試成本以及 (可能會有的) 較高的故障率 (畢竟是白老鼠 XD)，再來是機器本身價錢差距，這些都是會想要知道的...
在 tweet 後 Matthew Prince 有回答一些問題，另外可以看到後續會有更多細節會整理出來，但感覺應該是調整的差不多決定會換過去了？這邊算是延續去年十一月「Cloudflare 測試 ARM 新的伺服器」這篇所做的事情，當時他們拿到 ARM 的工程板在測試，就已經跟 Xeon 打的差不多 (有輸有贏)，現在應該又改善更多...
看 retweet 數可以看出來大家還滿期待的，畢竟 ARM 上面的 Linux 本來就因為行動裝置很熱，現在主要還是差在有沒有穩定的伺服器可以用。
Raspberry Pi 3 推出了 Model B+ 的新版本：「Raspberry Pi 3 Model B+ on sale now at $35」。
除了 CPU 速度稍微快一些以外，另外支援了 802.11ac/5Ghz 的無線網路 (官方宣稱可以跑到 ~102Mbps，相較於先前在 2.4Ghz 只能跑到 ~35Mbps)，以及更快的有線網路 (官方宣稱可以跑到 ~315Mbps，相較於先前的 ~95Mbps)。
然後是支援 PXE：
Raspberry Pi 3B was our first product to support PXE Ethernet boot. Testing it in the wild shook out a number of compatibility issues with particular switches and traffic environments. Gordon has rolled up fixes for all known issues into the BCM2837B0 boot ROM, and PXE boot is now enabled by default.
以及支援 PoE 直接推動整台機器：
We use a magjack that supports Power over Ethernet (PoE), and bring the relevant signals to a new 4-pin header. We will shortly launch a PoE HAT which can generate the 5V necessary to power the Raspberry Pi from the 48V PoE supply.
或是吃更多電 XDDD
Note that Raspberry Pi 3B+ does consume substantially more power than its predecessor. We strongly encourage you to use a high-quality 2.5A power supply, such as the official Raspberry Pi Universal Power Supply.
所以看到這張圖時就不意外了 XDDD (風扇！)
只是風扇的細節要再找一下，在產品頁上好像沒看到...
Update：風扇那張圖的產品頁看起來在「Raspberry Pi PoE HAT」這頁 (參考下面的 comment)。
在 MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字，這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」)，說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大：
Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).
他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速，在新版應該可以改善不少。但即使如此，文章內還是在實體機器上看到了 40% 的效能損失：
A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.
然後後面就在推銷 MariaDB 的 Aria Storage Engine 了，不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的，因為接下來五年應該都還是愈的到 KPTI，應該還是有人在用 MyISAM...
Netflix 的 Brendan Gregg 整理了他測試 KPTI 對效能的影響：「KPTI/KAISER Meltdown Initial Performance Regressions」。
與其他人只是概括的測試，他主要是想要針對可量測的數字對應出可能的 overhead，這樣一來還沒上 patch 的人就可以利用這些量測數字猜測可能的效能衝擊。
他把結論放在前面：
To understand the KPTI overhead, there are at least five factors at play. In summary:
- Syscall rate: there are overheads relative to the syscall rate, although high rates are needed for this to be noticable. At 50k syscalls/sec per CPU the overhead may be 2%, and climbs as the syscall rate increases. At my employer (Netflix), high rates are unusual in cloud, with some exceptions (databases).
- Context switches: these add overheads similar to the syscall rate, and I think the context switch rate can simply be added to the syscall rate for the following estimations.
- Page fault rate: adds a little more overhead as well, for high rates.
- Working set size (hot data): more than 10 Mbytes will cost additional overhead due to TLB flushing. This can turn a 1% overhead (syscall cycles alone) into a 7% overhead. This overhead can be reduced by A) pcid, available in Linux 4.14, and B) Huge pages.
- Cache access pattern: the overheads are exacerbated by certain access patterns that switch from caching well to caching a little less well. Worst case, this can add an additional 10% overhead, taking (say) the 7% overhead to 17%.
重點在於給了量測的方式，以第一個 Syscall rate 來說好了，他用 sudo perf stat -e raw_syscalls:sys_enter -a -I 1000 測試而得到程式的 syscall 數量，然後得到下面的表格，其中 X 軸是每秒千次呼叫數，Y 軸是效能損失：
用這樣的方式提供給整個組織 (i.e. Netflix) 內評估衝擊。
