Raspberry Pi 5 在 shutdown 狀態時的電力消耗過高問題

在「Reducing Raspberry Pi 5's power consumption by 140x」這邊看到的,講 Raspberry Pi 5 在 shutdown 狀態下電力消耗過高的問題。

依據 Jeff Geerling 提到,在 shutdown 狀態下仍然會消耗 1.2W~1.6W:

Because of this, a Pi 5 will still sit there consuming 1.2-1.6W when completely shut down, even without anything plugged in except power.

也有提到解決方法是把 POWER_OFF_ON_HALT 改成 1,他給的範例另外有多一些設定,但跟這次的功耗問題無關:

[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1

依照文章裡面的說明設定好,重開再 shutdown 測試就可以看到整個降下來了:

Save that configuration and reboot, then next time you shut down, you should see power consumption go down from 1-2W to 0.01W or even less:

應該算是某種 bug 或是 regression,後續預設值應該會修正?

X (Twitter) 的工程團隊列出了最近做的事情

Hacker News 上看到的討論,在 Elon Musk 接手後的 X (Twitter),工程團隊做了什麼事情:「X Engineering Year Retrospective (twitter.com/xeng)」,原推在:

其中裡面有些蠻有趣的,出現了一些平常不太會出現的數字資訊。

我比較有興趣的關掉了加州 Sacramento DC 的這個部分,而光是這個 DC 就有 148k 台 server (是 server,不是 VM 或是 container),而且也提到電力少了 48MW,看起來是把這些 server 廢掉,而不是轉到其他機房?

- Shutdown the Sacramento data center and re-provisioned the 5,200 racks and 148,000 servers, which generated more than $100M in annual savings. In total, we freed up 48 MW of capacity and tore down 60k lbs. of network ladder rack before re-provisioning it to other data centers.

話說一個 Twitter 機房用 48MW... 查了一下台電網站,核三的一個機組的供電量也才 951MW:

而且 Twitter 服務要用到 148k server,hmmm...

XFCE (Xubuntu) 下的手動 lock + screensaver + DPMS 組合

桌機換成 Xubuntu 22.04 後會遇到手動鎖定螢幕時,螢幕不會進入省電模式,遇到的情況有點像是「DPMS Suspend on Screen Lock」這邊提到的情境。

這類問題如果用 search engine 一時間沒有找到解法的話,最好的方法都是直接去讀 source code,然後就發現透過 Ctrl+Alt+L 觸發的 /usr/bin/xflock4 其實是個 shell script,從 code 讀可以發現裡面只負責 lock 的部分,本來就跟 DPMS 無關。

我在下面提供的方案就是自己處理螢幕的部分,也就是自己先跑 DPMS 指令,然後再回頭呼叫 /usr/bin/xflock4

#!/bin/sh
/usr/bin/xset dpms force off
exec /usr/bin/xflock4

Ctrl+Alt+L 的觸發程式掛上來,這樣就會正常處理了...

Amazon EFS 推出 One Zone 版本

Amazon EFS 提供 One Zone 的版本,用較低的可靠度提供更低的價錢:「New – Lower Cost Storage Classes for Amazon Elastic File System」。

價錢大約是 53 折,不過要注意不在同一個 AZ 時使用會有頻寬費用:

Standard data transfer fees apply for inter-AZ or inter-region access to file systems.

目前想的到的是 /net/tmp 這類的用途,資料掉了也就算了,考慮到可靠度,其他的用途好像暫時想不到...

Apple M1 的效能與省電原因

Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋,可以當作一種看法:

可以在 Thread reader 上面讀:「Thread by @ErrataRob on Thread Reader App – Thread Reader App」。

看起來 Apple 在規劃的時候就有考慮 x86 模擬問題,所以在記憶體架構上直接實做了對應的模式,大幅降低了當年 MicrosoftSurface 上遇到的問題:

3/ The biggest hurdle was "memory-ordering", the order in which two CPUs see modifications in memory by each other. It's the biggest problem affecting Microsoft's emulation of x86 on their Arm-based "Surface" laptops.

4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.

另外一個比較有趣的架構是,Apple M1 上面的兩個 core 有不同的架構,一顆對效能最佳化,另外一顆對效率最佳化:

13/ Apple's strategy is to use two processors: one designed to run fast above 3 GHz, and the other to run slow below 2 GHz. Apple calls this their "performance" and "efficiency" processors. Each optimized to be their best at their goal.

在 wikipedia 上的介紹也有提到這兩個 core 的不同,像是 L1 cache 的差異 (128KB 與 192KB),以及功耗的差異:

The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, providing a configuration similar to ARM big.LITTLE and Intel's Lakefield processors. This combination allows power-use optimizations not possible with Apple–Intel architecture devices. Apple claims the energy-efficient cores use one tenth the power of the high-performance ones. The high-performance cores have 192 KB of instruction cache and 128 KB of data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB instruction cache, 64 KB data cache, and a shared 4 MB L2 cache. The Icestorm "E cluster" has a frequency of 0.6–2.064 GHz and a maximum power consumption of 1.3 W. The Firestorm "P cluster" has a frequency of 0.6–3.204 GHz and a maximum power consumption of 13.8 W.

再加上其他架構上的改善 (像是針對 JavaScript 的指令集、L1 的提昇,以及用 TSMC 最新製程),累積起來就變成把 Intel 版本壓在地上磨蹭的結果了...

Amazon EBS 的 Cold HDD (sc1) 降價 40%

剛剛看到 Amazon EBS 的 Cold HDD (sc1) 大幅降價 40%:「AWS announces 40% price reduction for Amazon Elastic Block Store (EBS) Cold HDD (sc1) volumes」。

Cold HDD (sc1) 主要是拿來堆資料的,直接掛上來操作比起 Amazon S3 還是方便不少,這次的降價算是懶人的福音?

現在的「Amazon EBS pricing」頁面已經更新了,想要比較的話可以從 archive.is 上面的「Amazon EBS pricing」對比。價錢的部份從十一月九號自動生效:

Amazon EBS customers automatically benefit from this new lower price, which is effective starting November 9th, 2020.

RDS 推出 ARM 版本

Amazon RDS 推出了 ARM 的版本:「New – Amazon RDS on Graviton2 Processors」,包含了 MySQLMariaDBPostgreSQL 的版本都有支援,不過看起來需要比較新版的才能用:

You can choose between M6g and R6g instance families and three database engines (MySQL 8.0.17 and higher, MariaDB 10.4.13 and higher, and PostgreSQL 12.3 and higher).

官方宣稱可以提供 35% 的效能提昇,考慮費用的部份會有 52% 的 c/p 值提昇:

Graviton2 instances provide up to 35% performance improvement and up to 52% price-performance improvement for RDS open source databases, based on internal testing of workloads with varying characteristics of compute and memory requirements.

對於 RDS 這種純粹就是個服務的應用來說,感覺應該不會有什麼轉移成本,只要測過沒問題,換過去等於就是現賺的。看起來等 RI 約滿了就可以切...

EC2 宣佈 Reserved Instances 降價

Amazon EC2 的 Reserved Instances 宣佈降價:「EC2 Price Reduction – For EC2 Instance Saving Plans and Standard Reserved Instances」。

文章裡先列出 M5/C5/R5 的:

可以看到 R5 在一年是完全沒動,然後有些也是 0%,不過大多數應該是都有降:

Below I’ve given a snapshot of some of the savings across the M5, C5, and R5 instance types, however there are also price reductions for the instance types C5n, C5d, M5a, M5n, M5ad, M5dn, R5a, R5n, R5d, R5ad, R5dn, T3, T3a, Z1d, and A1.

以這些資料看起來是降了一些,但實際想要翻 T3a 系列機器的歷史資料時發現不好找,用搜尋引擎可以在「Where can I find Amazon EC2 price history?」這邊看到「https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonEC2/current/index.csv」這個地方,看起來是「New – AWS Price List API」這邊的資訊,不過看起來沒有 RI 的資料,只有 AmazonEC2 的資料 (所以對應到的都是 $0.00)。

之後看看有沒有其他地方有留這些資訊好了...

GitHub 擴大免費版功能,以及付費版降價

GitHub 宣佈了提昇免費版的功能,以及付費版的降價消息:「GitHub is now free for teams」。

昨天是這樣:(從這邊撈的,然後發現好像有人寫了個機器人,每天都叫 web.archive.org 去撈一份...)

現在變成:

本來付費的個人方案 (Pro) 的功能都直接下放到免費版本了,而一般公司用的 Team 版本從 $9/m/user 降到 $4/m/user。有個富爸爸之後就可以任性...

Lambda 被放進 Savings Plans 了

前幾天才在 Ptt 上回了一些對 Lambda 與 Serverless 的想法,結果剛剛看到 Lambda 被納入 Savings Plans 裡面了:「Savings Plan Update: Save Up to 17% On Your Lambda Workloads」。

最多 17% 的折扣,看起來比其他的低不少,應該是因為 Lambda 比起 EC2 或是 Fargate 更動態的關係:

Today I am happy to be able to tell you that Compute Savings Plans now apply to the compute time consumed by your AWS Lambda functions, with savings of up to 17%.

現有的 Savings Plans 如果沒有用完的部份也會自動套用進去。先放著看看...