Scaleway 的 RISC-V 伺服器

看到「Scaleway launches RISC-V servers (scaleway.com)」這篇,Scaleway 推出了 RISC-V 的伺服器:「Elastic Metal RV1」。

先看對消費者比較有感覺的部分,未稅 €15.99/mo 大約是 US$17.34/mo,有 16GB RAM 這點算是蠻有競爭力的,目前常見的 VPS 大約是 1:5 左右 (1GB RAM 大約要 $4/mo),這邊直接接近到 1:1,光是這點在吃 memory 比較重的環境下就蠻吃香的。

另外從 Scaleway 的角度來看,有蠻多特別的特性,像是超省電與超高密度:

EM-RV1 servers are extremely energy-efficient, consuming between 0.96W and 1.9W per 1.8GHz core.

Incredibly dense, a 52U rack holds up to 672 EM-RV1s!

所以一台機器的 4 core 跑滿大約是 7.6W,看功耗與手機用的 ARM CPU 有點像,只是不知道 CPU 效能到底在哪個區間,等後續看看好了?

換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

AMD 在 AM4 腳位上再出四顆 CPU...

看到 AMD 的新聞稿楞了一下:「AMD Reveals Next-Gen Desktop Processors for Extreme PC Gaming and Creator Performance」。

出了四顆 5000 系列的 CPU 在 AM4 主機板上使用:

New AMD Ryzen™ 5000 Series Desktop Processors Bring More Performance to Legacy Socket AM4 Platforms

其中 5700X3D 這顆價錢算是很殺的 (US$249),對於吃 CPU cache 很重的遊戲會是個有趣的選擇,先前 X3D 最便宜的是 5800X3D (US$449),這顆算是個有趣的玩具...

另外 5500GT 這顆 US$125 也是個蠻有趣的產品,剛剛翻了一下原價屋上的 5600G 是 $4970,換算大約是 US$160,不確定是不是屬於輕量機種的範圍... (像是組給家裡老人家用?)

意外的讓 AM4 平台又多了一些硬體可以玩?

Mixtral 8x7B 的論文出來了

Hacker News 上看到 Mixtral-8x7B-v0.1 以及 Mixtral-8x7B-Instruct-v0.1 的論文出來了:「Mixtral 8x7B: A sparse Mixture of Experts language model (arxiv.org)」,arXiv 上的連結:「Mixtral of Experts」。

跟先前大家從公開資料研究的差不多,這個研究成果主要不是降低參數的大小,而是降低運算的量:

As a result, each token has access to 47B parameters, but only uses 13B active parameters during inference.

然後仍然是超越 GPT-3.5 的水準:

Mixtral was trained with a context size of 32k tokens and it outperforms or matches Llama 2 70B and GPT-3.5 across all evaluated benchmarks.

先看計算量的問題,Mixtral 8x7B 的 model 對 VRAM 要求仍然不是消費級 GPU 可以達到的,對一般家用電腦來說,還是需要 quantisation 降低精度換取對 VRAM 空間的壓力下降。

這點可以在 TheBloke/Mixtral-8x7B-v0.1-GGUF 這邊看到各種 quantisation 後需要的 VRAM 大小。

如果用 CPU 計算的話目前應該不是大問題,目前 LLM 的大小對於一般主機的 RAM 來說還不是問題 (單條 32GB,四條就有 128GB 了),加上現在 llama.cpp 主力已經是用 mmap 的方式在存取檔案,filesystem cache 可以在多次執行中重複使用,只是用 CPU 就不能對速度有太多想法了。

但如果往 GPU 這邊看的話就得取捨了,目前 GPU 中能跑 Mixtral 8x7B 最便宜的方案應該是兩張 3060 12GB 組成 24GB VRAM,一張約 NT$9k (~US$300),兩張約 NT$18k (~US$600),這樣的話有機會跑 mixtral-8x7b-v0.1.Q3_K_M.gguf,不過這邊寫「very small, high quality loss」。

如果 mixtral-8x7b-v0.1.Q3_K_M.gguf 的品質不能接受,希望計算品質好一點的話,三張 3060 Ti 12GB 組 36GB VRAM 的方案約 NT$27000 (~US$900),不過主機板可能要挑一下;這樣就有機會用需求 34.73 GB VRAM 的 mixtral-8x7b-v0.1.Q5_K_M.gguf 了,評語是「large, very low quality loss - recommended」。

最後岔題,剛剛算了一下成本,發現 3060 Ti 12GB 這張還是穩穩的 LLM 窮人卡,先前在「雲端上面的 GPU 資源費用,以及地端的 GPU 決策圖」這邊提到的決策圖,即使在 2023 年七月 4060 Ti 16GB 出了以後還是很好用... (約 NT$15k,~US$500)

世紀帝國系列裡的 AoE 與 AoK 使用組合語言加速的情況

Age of Empires (1997) 與 Age of Empires II: The Age of Kings (1999) 是當年兩個很紅的遊戲,有傳言裡面有很大一部分是用組合語言寫的。

剛剛在 Hacker News 上看到「Original Age of Empires 2 dev talks about its usage of assembly code (reddit.com)」這篇,看起來是原作者跳出來說明這段傳言 (講的更細),原文在 Reddit 的「AoE is written in Assembly - is this actually TRUE?! :O : aoe2」這邊。

32-bit 的 x86 組語部分有大約 13k 行,大多數 (11.5k 行) 是與繪圖有關的 (當年繪圖相關的功能都還是 CPU 在算):

There were about ~13,000 lines of x86 32-bit assembly code written in total.

The vast majority, about ~11,500 lines worth, was in the 'drawing core', which drew SLP sprites in a variety of ways (mirrored, stippled, clipped). The code for this was in a separate .asm file, which was "compiled" by Microsoft Macro Assembler 6.1 into a .obj file.

最主要的目的當然是效能,這邊提到隔壁棚的星海爭霸預設還是 640x480 的時候,AoE 這邊預設可以上 800x600:

The use of assembly in the drawing core resulting in a ~10x sprite drawing speed improvement over the C++ reference implementations, and AoE's drawing core was notably faster than competitors like StarCraft, which is why the default resolution 'out of the box' for AoE was 800 by 600, when nearly all our competition was 640 x 480 resolution - we could scroll the screen and fill it with sprites as fast or faster even though we had twice as many pixels-ish in the game world area.

後來到 64-bit 年代就變成用 C++,主要是因為 compiler optimization 的改進,以及多 CPU 與 multi-threading 的技術,讓計算力提升很多:

I re-wrote the assembly functions into C++ for both Definitive Editions, as they are 64-bit programs, and inline assembly was never supported by the 64-bit C++ compiler, and the vastly improved register sets and compiler optimizations made it un-necessary. Additionally, sprite drawing in the definitive editions is multi-threaded, and will use up to 4 cores for that task alone.

算是時代的演進,意外的留下一些記錄... 而更後面的時代則是把這些計算 offload 到顯卡上面了。

AMD Zen 3 與 Zen 4 上 FSRM (Fast Short REP MOV) 的效能問題

前幾天 Hacker News 上討論到的一篇:「Rust std fs slower than Python? No, it's hardware (xuanwo.io)」,原文則是在「Rust std fs slower than Python!? No, it's hardware!」。

原因是作者收到回報,提到一段 Rust 寫的 code (在文章裡面的 read_file_with_opendal(),透過 OpenDAL 去讀) 比 Python 的 code 還慢 (在文章裡面的 read_file_with_normal(),直接用 Python 的 open() 開然後讀取)。

先講最後發現問題是 Zen 3 (桌機版 5 系列的 CPU) 與 Zen 4 (桌機版 7 系列的 CPU) 這兩個架構上 REP MOV 系列的指令在某些情境下 (與 offset 有關) 有效能上的問題。

FSRM 類的指令被用在 memcpy()memmove() 類的地方,算是很常見備用到的功能,這次追蹤的問題發現在 glibc 裡面用到導致效能異常。

另外也可以查到在 Linux kernel 裡面也有用到:「Linux 5.6 To Make Use Of Intel Ice Lake's Fast Short REP MOV For Faster memmove()」,所以後續應該也會有些改善的討論...

Ubuntu 這邊的 issue ticket 開在「Terrible memcpy performance on Zen 3 when using rep movsb」這,上游的 glibc 也有對應的追蹤:「30995 – Zen 4: sub-optimal memcpy on very large copies」。

從作者私下得知的消息,因為 patch space 的大小限制,AMD 可能無法提供 CPU microcode 上的 patch,直接解決問題:

However, unverified sources suggest that a fix via amd-ucode is unlikely (at least for Zen 3) due to limited patch space. If you have more information on this matter, please reach out to me.

所以目前比較可行的作法是在 glibc 裡面使用到 FSRM 的地方針對 Zen 3 與 Zen 4 放 workaround,回到原來沒有 FSRM 的方式處理:

Our only hope is to address this issue in glibc by disabling FSRM as necessary. Progress has been made on the glibc front: x86: Improve ERMS usage on Zen3. Stay tuned for updates.

另外在追蹤問題的過程遇到不同的情境,得拿出不同的 profiling 工具出來用,所以也還蠻值得看過一次有個印象:

一開始的 timeit 算是 Python 裡面簡單的 benchmark library:

接著的比較是用 command line 的工具 hyperfine 產生出來的 (給兩個 command 讓他跑),查了一下發現在 Ubuntu 官方的 apt repository 裡面有包進去 (22.04+):

再來是用 strace 追問題,這個算是經典工具了,可以拿來看 syscall 被呼叫的時間點:

到後面出現了 perf 可以拿來看更底層的資訊,像是 CPU 內 cache 的情況:

接續提到的「hotspot ASM」應該也還是 perf 輸出的格式,不過不是那麼確定... 在「perf Examples」這邊可以看到 function 的分析:

而文章裡的則是可以看到已經到 assembly 層級了:

差不多就這些...

FreeBSD 14.0 釋出

FreeBSD 14.0-RELEASE 的公告也出來了:「FreeBSD 14.0-RELEASE Announcement」,比較完整的 release notes 在「FreeBSD 14.0-RELEASE Release Notes」。

先從官方列的 highlight 來看,首先比較重要的是 GENERIC kernel 支援 1024 cores:

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

看了一下 commit log 是從 256 變成 1024

先就 x86-64 這邊來看,目前「家用」最多的應該是 AMD7995WX (96 cores),舊版的 256 限制應該也還能撐住,但看 commit log 有提到,主要是預期這幾年應該會有更暴力的機器出現。

另外一塊是伺服器端,Intel 這邊有 8 sockets 的版本 (參考「Intel Xeon Sapphire Rapids to Scale to 4 and 8 Sockets」),如果都是接 8490H 的話就是 480 cores 了。

ARM 的話好像也可以堆,但不熟...

另外一個提到的重點是 TCP 預設的 congestion control 改成 CUBIC

The default congestion control mechanism for TCP is now CUBIC.

翻 commit log 可以看到是從 NewReno 換成 CUBIC 的,這樣就跟 Linux kernel 預設值一樣了。

再來比較重要的是在 release notes 裡面提到的,FreeBSD 15.0 將會拔光 32-bit 環境的支援,只留 armv7,這代表 Raspberry Pi 第一代的 armv6 也被淘汰掉了:

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.

然後有些我自己翻覺得還蠻有趣的。

首先是看到 non-root 的 chroot

The chroot facility supports unprivileged operation, and the chroot(8) program has a -n option to enable its use. a40cf4175c90 (Sponsored by EPSRC)

然後把 OpenSSH 內對 FIDO/U2F 的支援開起來了:

The use of FIDO/U2F hardware authenticators has been enabled in ssh, using the new public key types ecdsa-sk and ed25519-sk, along with corresponding certificate types. FIDO/U2F support is described in https://www.openssh.com/txt/release-8.2. e9a994639b2a (Sponsored by The FreeBSD Foundation)

ASLR 預設開啟:

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults. To disable for a single invocation, use the proccontrol(1) command: proccontrol -m aslr -s disable command. To disable ASLR for all invocations of a binary, use the elfctl(1) command: elfctl -e +noaslr file. Problems should be reported via the problem reporting system, https://bugs.freebsd.org, or posting to the freebsd-stable@FreeBSD.org mailing list. b014e0f15bc7 (Sponsored by Stormshield)

然後先前被罵臭頭的 WireGuard 支援也放回來了:(「FreeBSD & pfSense 上的 WireGuard 問題」)

The kernel wg(4) WireGuard driver has been reintegrated; it provides Virtual Private Network (VPN) interfaces using the WireGuard protocol. 744bfb213144 (Sponsored by Rubicon Communications, LLC ("Netgate") and The FreeBSD Foundation)

然後看到 Netflix 贊助的 kTLS 支援 TLS 1.3:

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)

然後 FreeBSD 長久以來 root 預設用的 /bin/csh 改成 /bin/sh 了:

The default shell for the root user is now sh(1), which has many new features for interactive use. d410b585b6f0

預設的 MTA 變成 dma (Dragonfly Mail Agent),看名字加上翻了一下 manpage,確認是從 Dragonfly BSD 移植過來的:

The default mail transport agent (MTA) is now the Dragonfly Mail Agent (dma(8)) rather than sendmail(8). Configuration of the MTA is done via mailer.conf(5). sendmail(8) and its configuration remain available. a67b925ff3e5

然後 portsnap 被拔掉了,現在就建議直接用 git 拉了,算是功成身退了:

The portsnap(8) utility has been removed. Users are encouraged to fetch the ports tree by using pkg install git and then git clone https://git.FreeBSD.org/ports.git /usr/ports. df53ae0fdd98

而 mergemaster 也被換成 etcupdate 了:

mergemaster(8) has been deprecated. Its replacement is etcupdate(8). 398b12691b4f (Sponsored by The FreeBSD Foundation)

然後支援 tarfs,而且可以用 zstd

The tarfs(5) file system has been added, which is backed by POSIX tar archives optionally compressed with zstd(1). 69d94f4c7608 (Sponsored by Juniper Networks, Inc.) (Sponsored by Klara, Inc.)

好久沒看 FreeBSD 的 release notes...

Cloudflare Workers 推出新的計費模式:以 CPU time 收費

CloudflareWorkers 這個產品 (serverless 產品線) 推出了以 CPU time 收費的模式:「New Workers pricing — never pay to wait on I/O again」。

在這之前大家都是以 wall time 在計費,但這對於會卡在 I/O 很久的應用來說很不利,這次 Cloudflare 提出方案改用 CPU time 來計費,的確有吸引到我的目光...

這是舊的:

這是新的:

就這兩張比較起來有個不是很確定的部分,現在不看 memory 用量收費了?Pricing 這頁裡面的資量已經把 「Standard」更新上去了,但好像還是沒提到 memory?

不過不是馬上生效,而是這個月的月底 2023/10/31 可以選擇切到新的方案:

Starting October 31, 2023, you will have the option to opt in individual Workers and Pages Functions projects on your account to new pricing, and newly created projects will default to new pricing. You’ll be able to estimate how much new pricing will cost in the Cloudflare dashboard. For the majority of current applications, new pricing is the same or less expensive than the previous Bundled and Unbound pricing plans.

另外明年 2024/03/01 會全部強制切到新的方案:

If you’re on our Workers Paid plan, you will have until March 1, 2024 to switch to the new pricing on your own, after which all of your projects will be automatically migrated to new pricing. If you’re an Enterprise customer, any contract renewals after March 1, 2024, will use the new pricing.

用 CPU time 的確是好不少,但不知道這個 billing 的方式沒有其他地雷...

Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂,比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西,發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門,而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的:

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到,就在他寫的 page 71 (PDF 的 page 90) 的 note 21:

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面,在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了,像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商:「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄:

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...