幹壞事是進步最大的原動力
也是在 Hacker News 首頁上看到的資訊，Starlink 的天線在五十度時會停機：「Starlink dishes go into “thermal shutdown” once they hit 122° Fahrenheit」。
這篇報導是出自 Reddit 上的消息，苦主住在亞利桑那州，美國的南部地區，以緯度來說的話大概跟大阪差不多：「This could be a problem. Only noon in AZ...」。
Reddit 的討論裡面有提到用撒水的方式降溫，但這樣對熱帶與亞熱帶地區好像不太友善啊，陽光大一點應該就會過熱？看起來是個得改善的點了...
Hacker News 首頁上看到的文章，講 Spectre Mitigation 的效能損失：「Spectre Mitigations Murder *Userspace* Performance In The Presence Of Frequent Syscalls」，對應的討論串在「Spectre Mitigations Murder Userspace Performance (ocallahan.org)」。
看起來作者是在調校 rr 時遇到的問題，幾年前有提到過 rr：「Microsoft 的 TTD 與 Mozilla 的 RR」。
對此作者對 rr 上了一個 patch，減少了 mitigation code 會在 syscall 時清掉 cache 與 TLB，這個 patch 讓執行的速度大幅提昇：「Cache access() calls to avoid syscalls」。
另外作者提到了他的硬體是 Intel 的 Skylake，他又再跑一次 pre-patch 與 post-patch 的速度，可以看到在 pre-patch 前，mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s)，而 post-patch 後大幅降低 syscall 的使用，就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。
就目前知道的 mitigation 方式來說，這個猜測應該是對的...
在去年年底 AWS 的公佈的「re:Invent 2020 – Preannouncements for Tuesday, December 1」裡面提到兩個有趣的產品，一個是 Amazon ECS Anywhere，另外一個是 Amazon EKS Anywhere，現在 Amazon ECS Anywhere 開放了：「Getting Started with Amazon ECS Anywhere – Now Generally Available」。
這兩個服務都是把自家的機器 container 化然後讓 AWS 的服務直接管理，只是一個是 ECS (AWS 自家的規格)，另外一個是 EKS (基於 Kubernetes)，這次丟出來當然很重要，不過還是會等 EKS Anywhere 出來後一起比較看看。
價錢的部份就是照機器數量算，一台機器大約 USD$7.38/month，以 bare metal 等級的機器來說倒是沒什麼問題：
You pay $0.01025 per hour for each managed ECS Anywhere on-premises instance. An on-premises instance is a customer-managed instance that has been registered with an Amazon ECS cluster and runs the Amazon ECS container agent.
這樣讓地端的機器更容易上雲，不過離台灣本地沒有 region 在網路的 latency 上就有點討厭了，另外一種搞法是找 dedicated hosting 或是自己塞機器進 colocation hosting，然後掛上這類服務？
在「USB Type-C Specification 2.1 allows up to 240W Extended Power Range (EPR)」這邊看到這個規格：
Extended Power Range cables have additional requirements to assure that these cables can deliver the full defined voltage and current range for USB PD EPR operation. EPR cables shall functionally support a reported 50 V and 5 A o peration. The minimum functional voltage that a cable shall support is 53.65 V. The electrical components potentially in the path of V BUS in an EPR cable, e.g. bypass capacitors, should be minimally rated for 63 V.
All EPR cables shall be Electronically Marked and include EPR-specific information in the eMarker as defined by the USB PD specification. As defined in the USB PD specification, EPR cables are marked as 50 V and 5 A capable. All EPR cables shall be visibly identified with EPR cable identification icons as defined by the USB-IF. This is required so that end users will be able to confirm visually that the cable supports up to as high of PDP = 240W as defined in the USB PD specification.
也是基於 E-Marker 晶片的關係，除了充電頭支援外，線本身也得支援。這解決了目前很多家桌機都自己搞 >100W 的 dock 來支援高瓦數的充電，推出一個標準來涵蓋收斂...
會不會搞到以後連桌機都可以用 USB-C 界面供電啊...
在「Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance」這篇文章裡面，作者在示範各種奇技淫巧調教校 HTTP server。
在 Hacker News 上的討論也蠻有趣的：「Extreme HTTP Performance Tuning (talawah.io)」。
雖然是在講 HTTP server，但裡面有很多東西可以拿出來獨立用。
想特地拿出來聊的大項目是「Speculative Execution Mitigations」這段，作者有些說明，除非你真的知道你在做什麼，不然不應該關掉這些安全相關的修正：
You should probably leave the mitigations enabled for that system.
而作者是考慮到 AWS 有推出 AWS Nitro Enclaves 的前提下決定關掉，但我會建議在 *.metal 的機器上才這樣做，這樣可以避免這台機器上有其他 AWS 帳號的程式在跑。
測試中關了一卡車 mitigation，得到了 28% 的效能提昇：
Disabling these mitigations gives us a performance boost of around 28%.
這其實比預期中多了不少，這對於自己擁有實體機房跑 Intel 平台的使用者來說，很吸引人啊...
這次 Amazon EC2 的機器又推出一些新規格了：「Amazon EC2 High Memory Instances now available for on-demand usage」。
然後每次推這些機器的時候都會提到 SAP HANA，都沒有其他的例子可以說... 話說業界就只剩下這套系統是完全都沒在考慮分散式架構嗎 XDDD (完全沒用過)
SAP customers continue to leverage AWS as their platform of choice and innovation. Some are in the early stages of their SAP cloud journeys and are focused on executing their migration. Others have hardened their SAP systems on AWS and are innovating around their core business processes with advanced AWS services.
另外他有提到 24TB 的機器，在 Amazon EC2 Instance Types 這邊可以翻到 u-24tb1.metal：
In 2018, we released High Memory Instances in response, which now offer up to 24TB of memory in a single instance.
不過你會發現在 Amazon EC2 On-Demand Pricing 這邊翻不到 24TB 的價錢，先前在「EC2 推出 18TB 與 24TB 的機器...」這邊有過這些機器買三年 RI 才能用，所以這次推出來 12TB 的機器算是隨時租用的機器裡面記憶體最多的了...
u-12tb1.112xlarge 在 us-east-1 的價錢是 USD$109.2/hour，想要玩的人可以測試看看，至少應該玩的動 XD
Backblaze 昨天放出來 2021Q1 的硬碟報告：「Backblaze Drive Stats for Q1 2021」。
前半部沒有什麼意外，HGST 的硬碟比起其他家的看起來還是好不少。
比較有趣的是首次拿 SSD 與 HDD 對決，這邊比較的對象是開機碟。可以看到如果以 2021Q1 的時間來看，SSD 的 AFR 低不少：
拉長到 lifetime 來看也還是低不少：
但裡面也有提到 HDD 的最大壽命比目前 SSD 都高不少，時間看起來可能還不夠長，算是一個很初步的資料...
以往 Amazon EC2 的機器爛到開不起來時只能「看」到 Console 的輸出，然後要把 root volume 掛到其他機器上修正，接著再掛回來 (然後沒修好就要再重複...)，現在總算可以透過 EC2 Serial Console 來操作了：「Troubleshoot Boot and Networking Issues with New EC2 Serial Console」。
不過裡面有一些限制，首先機器必須是基於 AWS Nitro System，這個部份在「Amazon EC2 Instance Types」這邊可以翻到是不是 Nitro，比較新的 family type 應該都是 (像是 t3/t3a/t4g 都是 Nitro，但 t2 不是)：
EC2 Serial Console access is available for EC2 instances based on the AWS Nitro System. It supports all major Linux distributions, FreeBSD, NetBSD, Microsoft Windows, and VMWare.
另外是支援的區域目前只有幾個主力區域，不過公司在用的主力區 (新加坡) 也進去了，之後遇到問題的時候可以測試看看：
Twitter 上看到有些人有提到「總算啊...」之類的感想...
AWS 推出了 X2gd 機種，用 ARM 的 CPU，然後給更少顆，disk 也更小，但換來的就是價錢更低：「New Amazon EC2 X2gd Instances – Graviton2 Power for Memory-Intensive Workloads」。
把兩個用 ARM 的主機拿出來看看 us-east-1 的價錢，第一個是這次的 x2gd.medium，只有 1 vCPU + 59 GB SSD，但有 16 GB RAM，現在的價錢是 $0.0835/hr。
另外一個 r6g.large 則是 2 vCPU + 16 GB RAM，然後 EBS only，則是 $0.1008/hr。
再來是 Intel 的 x1e.xlarge，這邊是 4 vCPU + 12 GB RAM + 120 GB SSD，單價也差不多，不過記憶體少了點，$0.834/hr。
另外 Intel 也有 r5.large，2 vCPU + 16 GB RAM + EBS only，$0.126/hr。
最後一個是 AMD 的 r5a.large，跟 Intel 的 r5.large 也很像，2 vCPU + 16 GB RAM + EBS only，$0.113/hr。
這次推出的 X2gd 機種提供了只要記憶體的極端選擇，而且依照先前的經驗，Graviton2 真的很快，1 vCPU 未必會不夠用... 至少我 blog 的 PHP 與 MariaDB 都是跑在 t4g 上面，看起來比之前放在 VPS 上快不少 :o
在大約三年前 (2018 年年初) 的時候，在讀完 Spectre 之後寫下了一些記錄：「讀書時間：Spectre 的攻擊方式」，結果在 Bruce Schneier 這邊看到消息，Google 前幾天把把 PoC 放出來了：「Exploiting Spectre Over the Internet」，在 Hacker News 上也有討論：「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。
首先是這個攻擊方法在目前的瀏覽器都還有用，而且包括 Apple M1 上都可以跑：
The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.
即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度，也還是可以達到 60 bytes/sec 的速度：
While experimenting, we also developed other PoCs with different properties. Some examples include:
- A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
- A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.
比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨，目前在瀏覽器上只能靠各種 isolation 降低風險，像是將不同站台跑在不同的 process 裡面：
In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.
Apple M1 也中這件事情讓人比較意外一點，看起來是當初開發的時候沒評估？目前傳言的 M1x 與 M2 不知道會怎樣...