Amazon EC2 的網路效能

前一篇「在 AWS 上面的 OpenVPN Server 效能」最後的問題就是 EC2 instance 本身的網路效能,畢竟是公司要用的,還是實際測一下數字,之後有人接手的時候也比較清楚是怎麼選這個大小的...

這邊拿的是 AWSap-southeast-1 (Singapore) 的 EC2 測試,直接在同一個 subnet 裡面開兩台一樣的機器跑 iperf 測試。

機器開機後會先跑這串指令 (除了安裝 iperf 的指令,其他的是出自我自己 wiki 上的 Ubuntu 這頁),然後再重開機:

sudo fallocate -l 512M /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab; echo -e "net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr" | sudo tee /etc/sysctl.d/99-tcp.conf; sudo sysctl -p /etc/sysctl.d/99-tcp.conf; sudo apt update; sudo apt dist-upgrade -y; sudo apt install -y apache2-utils apt-transport-https build-essential curl dnsutils dstat git jq locales moreutils most mtr-tiny net-tools p7zip-full pigz prometheus-node-exporter rsync sharutils software-properties-common sysstat unrar unzip vim-nox wget zsh zsh-syntax-highlighting zstd; sudo apt install -y iperf; sudo apt clean

接下來就是一台跑 iperf -s,另外一台跑 iperf -c 10.x.x.x -i 1 -t 3600 讓他跑一個小時看結果了。

我都有跑 tmux 再連到這些機器上,這樣可以捲回去看每一秒的傳輸速度,就可以看出來變化了,不過這邊還是簡單的只列出最高速度 (burstable) 與穩定輸出的速度 (baseline):

EC2 instance Baseline Burstable vCPU RAM Pricing (USD$)
c6g.medium 500Mbps 10Gbps 1 2GB 0.0392
c6g.large 750Mbps 5Gbps (claimed 10Gbps) 2 4GB 0.0784
c6g.xlarge 1.25Gbps 10Gbps 4 8GB 0.1568
t4g.small 125Mbps 5Gbps 2 2GB 0.0212
t4g.medium 255Mbps 5Gbps 2 4GB 0.0424
t4g.large 510Mbps 5Gbps 2 8GB 0.0848
t4g.xlarge 1Gbps 5Gbps 4 16GB 0.1696

這邊沒列出來的是 burstable 可以持續的時間,但這跟你機器吃的網路資源有關,我就決定只用 baseline 來做決策了,這樣可能會多花一點錢,但會少很多麻煩。

另外這次在處理的過程有被同事提醒各種 bandwidth overhead,所以就順便查了一下資料:

  • OpenVPN 本身的 overhead 大約是 5% (跑 UDP 的時候):「OpenVPN performance」。
  • SSH 也有些 overhead,大約是 6% (把來回的封包都算進去):「What is the overhead of SSH compared to telnet?」。
  • rsync 的部份鐵定也有 overhead,但這邊就沒找到現成的文章有統計過了。
  • 另外我自己之前做實驗發現 TCP BBR 的 retransmission algorithm 還蠻激進的,會有 10% packet loss,改用預設的 CUBIC 會好很多,大約 1% 到 2% 左右。

綜合這些測試,我自己抓了 35% 的 overhead 來推估,最後是用 c6g.large 來養 VPN server。750Mbps 的實際流量大約可以包進 550Mbps 的原始流量,大約是 68MB/sec。

不過新加坡與印尼之間的 internet bandwidth 好像還是不太夠,有時候深夜跑也跑不滿... 不過之後 VPN 上的 client 會愈來愈多,應該是不需要降...

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「Amazon EC2 的網路效能」這篇。

最近在在調整跑在 Amazon EC2OpenVPN server 的效能,要想辦法把 network throughput 拉高,當作在導入 WireGuard 之前的 workaround,但看起來還是頗有用,記錄一下可以調整的部份...

在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode),然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading,最高速度卡在 42MB/sec 左右。

第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式,但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU,所以就開始想其他方法...

接著看到我們目前用的是 AES-256-CBC 了,網路上很多文章都有提到 AES-128-CBC 會快一些,但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了,這個就沒辦法了...

而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano,還是 100% 的 CPU loading,但直接多了 50%+ 的效能,到了 69MB/sec。

第二個解法是找資料時發現的 fast-io 參數,加上去以後可以再快一些,到 77MB/sec。

有了這兩個 workaround 應該就堪用了,接下來是發現在傳大量資料跑一陣子後速度會掉下來,於是開了兩台 t4g.nanoiperf 對測了一下,發現會逐步掉速:

  • 前 15 秒可以直接到 5Gbps,就是 AWS 網頁上宣稱的最高速度,接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps,後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的,但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是,居然不是四倍?),目前上了 c6g.medium,但看起來網路的部份也還是有瓶頸,在 46MB/sec 左右,要再想一下下一步要怎麼調整...

但以目前看到的情況總結,如果能用 ARM 架構就儘量用,效率與價錢真的是好 x86-64 不少...

Cloudflare 開始在正式環境用 ARM server 了

在「Designing Edge Servers with Arm CPUs to Deliver 57% More Performance Per Watt」這邊 Cloudflare 提到了他們在正式環境用 ARM 架構了:

Our first Arm CPU was deployed in production earlier this month — July 2021.

記得測了很多年,其中遇到測試到一半看起來還不錯,但原廠商決定不繼續做的,直到後來又有廠商投入,到現在總算是有比較成熟的產品可以用。

隔壁棚 AWS 上的 ARM 伺服器用起來也是香到不行,還沒有用過的可以試看看,至少我這台 blog & wiki 也都是跑在上面。

另外文章裡有提到目前 x86 的效能,新一代的 AMD 大概只比前一代多了 39% 的每瓦效能,但如果是把 ARM 拿進來比的話會到 57%:

Our most recently deployed generation of edge servers, Gen X, used AMD Rome CPUs. Compared with that, the newest Arm based CPUs process an incredible 57% more Internet requests per watt. While AMD has a sequel, Milan (and which Cloudflare will also be deploying), it doesn’t achieve the same degree of energy efficiency that the Arm processor does — managing only 39% more requests per watt than Rome CPUs in our existing fleet.

開始推上 production 後應該會愈換愈快,而且代表 Cloudflare 也會開始針對 ARM 平台最佳化。

AWS 宣佈 EBS io2 的新花樣 Block Express Volumes

看到「AWS Announces General Availability of Amazon EBS io2 Block Express Volumes」這篇,在 EBSio2 上面又推出了新的花樣 Block Express Volumes:

Today AWS announced general availability of io2 Block Express volumes that deliver up to 4x higher throughput, IOPS, and capacity than io2 volumes, and are designed to deliver sub-millisecond latency and 99.999% durability.

要再提供更高的效能,在 R5b 的機種下,單個 volume 可以拉到 256k IOPS 與 4000MB/sec 的傳輸速度,以及在 well-tuned 的環境下 (應該是多個 volume) 可以拉到 260k IOPS (多一點點) 與 7500MB/sec (將近原來的兩倍) 的傳輸速度:

Using R5b instances customers can now provision a single io2 volume with up to 256,000 IOPS, 4000 MB/s of throughput, and storage capacity of 64 TiB.

R5b instances are well-suited to run business-critical and storage-intensive applications as they offer the highest EBS-optimized performance of up to 260,000 IOPS and 7,500 MB/s throughput.

是個用錢炸效能的東西,用的到的就用...

在 ESP32 跑 Linux 作業系統

Hacker News 首頁上看到在有中國的開發者在 ESP32 上跑 Linux 作業系統:「Linux 5.0 shown to boot on ESP32 processor」,對應的討論在「Linux 5.0 shown to boot on ESP32 processor (cnx-software.com)」這邊可以看到。

文章最後面有提到這不是第一次在 ESP32 上跑 Linux:

Note it’s not the first time somebody runs Linux on ESP32, as last year the older Ubuntu 9.04 was demonstrated on ESP32.

看起來應該是作者覺得很有趣,所以還是提出來... 機器是 8MB PSRAM 與 2MB SPI flash:

ESP32 IoT processor supports up to 8MB PSRAM which makes it just enough to run a minimal version of Linux. There’s little practical application for it, but it may be fun to try, and one developer apparently managed to boot Linux 5.0.0 on a board with an ESP32 dual-core Xtensa processor connected to 8MB PSRAM and a 2MB SPI flash.

如果以 8MB RAM 來推算的話,大概是 i386 (80386) 到 i486 (80486) 時代的電腦?不過 ESP32 的 CPU 時脈快不少 (雖然架構不同不太能直接比較)。

25Gbps 的家用 Internet

Hacker News Daily 上看到「25 Gigabit Linux internet router PC build」這個,Hacker News 上的討論在「25 Gigabit Linux internet router PC build (stapelberg.ch)」這邊,文章裡面在講怎麼用 PC 建 25Gbps 的 router,不過大家基本上都是在討論其他事情...

先從服務本身來看,是瑞士的 ISP Init7 提供的服務:「Fiber7-X2」,月繳的話大約是 NTD$2100/month,打開 nerd mode 可以看到說明,是直接給你非 CGNAT 的動態 IPv4 位置以及固定的 IPv6 /48 位置:

The IPv4 address is part of our AS13030 backbone - not a Carrier-Grade-NAT address like with other providers. A fixed IPv4 or a /29 subnet are available for an additional charge. A static IPv6 /48 network is included free of charge. The addressing is done via DHCPv6-PD prefix delegation. Optimal ping times, transparent routing and an open peering policy make Fiber7 the kind of internet offer there always should have been.

另外翻了 FAQ,找到固定 IPv4 位置的價錢:「Can I get static IPv4 addresses?」,一個 IPv4 位置大約是 NTD$7200/year。

另外在「Recommended hardware」這邊看起來應該是沒提供 router,使用者要自己接準備 router 設備直接接,其中 25Gbps 的 Fiber7-X2 規格是:

Fiber7-X2: 25G SFP28 BIDI LR, 10 km, TX1270/RX1330 nm, LC-Simplex, Singlemode

在 ISP 推薦的硬體設備裡,支援 Fiber7-X2 的只有 MikroTik CCR2004-1G-12S +2XS,但只能跑到 15Gbps:

throughput: up to 15 Gbit/sec

難怪作者會想要自己搞 router...

順便查了一下 PCI Express 的速度資料,PCIe 3.0 下 2x 可以到 1.97GB/sec,勉勉強強擦到 25Gbps 的邊邊?文章作者這邊用了 PCIe 3.0 8x 的 Intel XXV710AM2 來解決。

整體裝起來看起來沒什麼問題,只能說是奢侈的煩惱 XD

AMD 推出 FidelityFX Super Resolution

AMD 推出了功能上類似於 NvidiaDLSS 的技術,叫做 FidelityFX Super Resolution (FSR),並且 open source 出來:「AMD FidelityFX Super Resolution is Here」,另外可以看一下 GPUOpen 官方網站裡面的內容。

DLSS 的機制上可以這樣解釋,遊戲輸出 1080p,透過 machine learning 運算的方式將畫質提升到 2K 或是 4K,這樣比起遊戲直接要計算 2K 或是 4K 的輸出內容,運算量可能會比較少。

不過 DLSS 只能跑在 RTX 20xx 與 30xx 系列的顯卡上,以前的舊顯卡不支援。而先前 AMD 公佈 FSR 的時候,除了是宣示 AMD 也推出類似的技術外,另外一個賣點是 FSR 可以跑在 Nvidia 的顯卡上。

而這次的消息則是又多說明了 open source 的釋出部份,將在七月中放出來:「AMD FidelityFX Super Resolution is Here」。

The source code for FidelityFX Super Resolution 1.0 will be coming to GPUOpen in mid July!

目前有七個遊戲支援,後續會有更多遊戲加入...

Starlink 的天線在五十度時會過熱停機

也是在 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 的討論裡面有提到用撒水的方式降溫,但這樣對熱帶與亞熱帶地區好像不太友善啊,陽光大一點應該就會過熱?看起來是個得改善的點了...

又再次看到了 Spectre Mitigation 的效能損失...

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」。

另外作者提到了他的硬體是 IntelSkylake,他又再跑一次 pre-patch 與 post-patch 的速度,可以看到在 pre-patch 前,mitigation 會讓系統慢超多 (從 2m5.776s 到 3m19.648s),而 post-patch 後大幅降低 syscall 的使用,就不會影響那麼多 (從 0m33.422s 到 0m36.160s)。

就目前知道的 mitigation 方式來說,這個猜測應該是對的...

Amazon ECS Anywhere

在去年年底 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,然後掛上這類服務?