Category: Hardware

Amazon EC2 的 M6g 系列正式推出了

先前提到 AWS 要在 EC2 上推出新的 ARM 架構主機 (參考「Amazon EC2 推出了新一代的 ARM 系統」這篇)，最近正式推出了：「New – EC2 M6g Instances, powered by AWS Graviton2」。

當時的定價還沒出來，現在正式開賣後可以拉出來看了。

拿 us-east-1 上 2 vCPU + 8GB RAM 這個級距的價錢出來，m5.large 是 USD$0.096/hour，m6g.large 是 USD$0.077/hour，低大約 20%，不過這是兩個不同的平台，只是抓一下感覺知道差距。

不過這個價差其實蠻有吸引力的，對於有支援 ARM 的應用程式，或是手上有 source code 的大型應用，可以測試看看效能有差多少，或是先等一下，這陣子應該就會有人初步測一些數字出來可以參考。

另外 AWS 有打算要出 C6g 與 R6g 的計畫，算是在雲上面補齊 ARM 的戰線：

We are not going to stop at general purposes M6g instances, compute optimized C6g instances and memory optimized R6g instances are coming soon, stay tuned.

目前支援的區域不算多，不過幾個老區域都先上了：

Now it’s your turn to give it a try in one the following AWS Regions : US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), and Asia Pacific (Tokyo).

Hacker News 上對實體機房的討論 (雲與地的討論)

看到 Hacker News 上的「Ask HN: Is your company sticking to on-premise servers? Why?」這邊在討論為什麼還是有公司使用傳統的實體機房。

用雲的價值在於彈性，因為雲上加機器的時間成本比傳統實體機房低很多：加的量小的時候，主要的成本就是簽核需要的時間 (即使是電子簽) 與 setup 的時間 (如果沒有自動化)，量大的時候可能會需要另外採購。

另外很多雲端服務的廠商除了 IaaS 以外也提供了很多 SaaS 的服務，這點對於建制的成本又降低了不少。

相反的，如果你的需求已經很固定了 (變動不大)，而且又已經有一定的規模了，用傳統實體機房自己搭建會便宜很多，即使包含人力維護成本也都還是低很多。

另外討論裡也有提到雲端的頻寬費用，這一直都是雲端的痛點：目前雲上面的頻寬都超貴，所以用規模大一點的雲端公司會透過架構上的設計，把大的流量利用 HTTP/HTTPS 的 CDN 省下來。像是使用 AWS 的 Netflix 設計了 Open Connect，藉以降低頻寬成本。

不過說到頻寬，AWS 的 Amazon Lightsail 就是個有趣的東西了，一樣是在 AWS 的架構內，但帳務上面把整包費用包的跟外面的 VPS 一樣...

AWS Elemental Link：直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link，可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上：「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎，大約 524 立方公分)：

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI，規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限)，然後設備除了透過一般電力供電以外，也可以用 PoE 供電，可以少接一條電源線：

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995，但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品，好像沒看到類似可以直接送到網路服務的產品...

AMD 平台的前面板與 USB...

在 Telegram 上看到這篇在講在 AMD 平台上遇到 USB 相容性的問題：

看了敘述與裡面連結提到的「Xperia XA2: Stuck on “Sending 'boot.img'”」與「Fastboot is getting stuck while trying to flash CWM onto Nexus 4」後，我就馬上想到我在換成 AMD 的平台後，遇到了一個感覺好像應該是有關的問題...

我遇到的問題是 YubiKey 在主機的前面板的四個 USB 接口都不會動 (抓的到，但是 browser 需要認證時 YubiKey 不會閃爍請使用者確認)，而接到 USB 2.0 Hub 上面也不會動 (這邊的 Hub 是接到後面 USB 3.0 的孔)，只有直接接到後面板的 USB 3.0 會動，所以我後來就買了一條 USB 3.0 的延長線，從後面的 USB 3.0 孔拉到桌上用...

昨天看到文章，為了確認這個情況，就到 PChome 24h 上找了一顆 USB 3.0 Hub，今天收到後接上 PC 測試，發現 YubiKey 就順利在登入時閃爍了，看起來之後在 AMD 平台上接 USB 的時候要注意一下，有狀況的時候要多測幾種不同的接法...

用 OpenCV 處理 webcam 的背景，再用 pyfakewebcam 接回給視訊軟體用...

最近武漢肺炎的關係，導致蠻多人會在家裡使用視訊會議，但背景一直是個問題... 然後就看到這篇文章：「Open Source Virtual Background」。

作者用 python-opencv 先處理 webcam 進來的影像 (看起來不只去背，還加上了 hologram 的效果 XDDD)，然後再用 pyfakewebcam 與 v4l2loopback 模擬成一個 webcam 餵回給視訊軟體，結果就惡搞成這樣了：

話說回來，最近各電商平台的 webcam 與視訊機都缺貨，還好之前有買個便宜的頂著，不然就得開筆電了...

AMD Ryzen Threadripper 3990X 在 Windows 上的效能

John Carmack 注意到在 AMD Ryzen Threadripper 3990X 上因為 Windows 的 group limit 限制而造成效能問題：

但這點可以透過打散到兩個 group 改善 (workaround) 而提昇速度：

然後順便看了一下目前 CPU Benchmark 網站上對於高階 CPU 的跑分數據「PassMark - CPU Mark High End CPUs)」，可以看到 AMD 最近真是香噴噴的，用 3950X (16C/32T，105W) 殺 Intel 目前最高分的 W-3275M (28C/56T，205W)，然後那個價差：

Intel 的 14nm 牙膏繼續擠...

Cloudflare 的另外一個策略：不熱門的資料只放到記憶體內

前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。

主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：

The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.

這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...

Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...

題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...

幫 2011 年的 Mac Mini 換 SSD

這台 Mac Mini 是我第一個蘋果產品 (退伍後在 PIXNET 的時候買的)，當時本來想在上面寫些東西，不過後來就一直當個終端機在用而已，到這幾年他的定位就是放在客廳當個播放器 (像是開 Twitch 或是 YouTube 在看)。

不過每次用都覺得開 Google Chrome 開的很慢，就興起將硬碟換成 SSD 硬碟的念頭了。至於記憶體，當初在買 Mac Mini 的時候應該是已經升級過，裡面是兩條 4GB 了，網路上是有人提到可以支援兩條 8GB，不過以目前客廳的用法，應該是用不到...

先對價錢做了一些功課，如果是自己處理，打算換成美光的 Crucial MX500，在 24h 是賣 $2,099 (不過後來是剛好有去光華一趟，就在光華買回來)，然後打電話問一下有提供更換服務的店家，500GB SSD 是 $3,500 換到好，1TB SSD 則是 $6,000。

以 500GB 的價錢倒是沒有到不能接受，但也不是能馬上就說 ok 的價位，還是得看一下有多麻煩才能決定要怎麼做。

所以就跑去看了一下 YouTube 上換 SSD 的影片，看起來只要有對應的螺絲起子，應該是可以自己換完。而我之前就有準備六角螺絲起子，應該是可以換下來：

實際拆的時候才發現，不只需要正六角的螺絲起子 (H 系列)，還需要星狀的螺絲起子 (T 系列)，本來想在 24h 下單隔天再來弄，突然想到這種東西在水電五金行應該有，當時才晚上八點，就跑去外面找了一組 (價錢也比 24h 便宜)，回來繼續拆...

有了正確的工具，拆開就簡單不少，反倒是裝回去折騰一陣子... 在裝有 WiFi 天線的那塊板子的四顆螺絲時卡了一個小時 (一直都只鎖的上去三顆)，最後本來是打算少鎖一顆螺絲，結果在準備放棄的時候突然暴力法把四個孔位都卡進去了，就順利把四顆螺絲都鎖上去...

接下來就是先開機進入 macOS Recovery 確認硬碟有被抓到，確認有被抓到以後，就可以準備重裝系統，這時候我拿 MBPR 下載 10.13 (High Sierra，這台 Mac Mini 能支援的最新版)，生出 USB 隨身碟裝機，然後插回 Mac Mini 重開機就可以裝系統了：

裝完後的開機速度很明顯快不少，裝軟體的速度也是，另外再打開一些網站看一看，冷啟動的速度都改善很多。

算是趁連假的時候整理一下硬體，還蠻有趣的...

Backblaze 的 2019 年度硬碟報告

Backblaze 丟出去年的報告了：「Backblaze Hard Drive Stats for 2019」。

WD/HGST 的還是最耐用，再來是 Toshiba 的，最後是 Seagate 的。

不過有一些硬碟沒有列到表上，像是「Seagate 16 TB Drives」這組因為 2019Q4 才剛裝上去，所以才 1440 drive days，因此還沒到門檻所以沒放進報告，但就 Backblaze 測試起來看起來是個好的開始：

In Q4 2019 we started qualifying Seagate 16 TB drives, model: ST16000NM001G. As of the end of Q4 we had 40 (forty) drives in operation, with a total of 1,440 drive days—well below our 5,000 drive day threshold for Q4, so they didn’t make the 2019 chart. There have been 0 (zero) failures through Q4, making the AFR 0%, a good start for any drive. Assuming they continue to pass our drive qualification process, they will be used in the 12 TB migration project and to add capacity as needed in 2020.

再來是把 2017/2018/2019 擺在一起看：

馬上可以看到的是 AFR 上升了不少，一個是因為 8TB 系列的硬碟進入中年期，另外是 Seagate 12TB 硬碟的問題：

The total AFR for 2019 rose significantly in 2019. About 75% of the different drive models experienced a rise in AFR from 2018 to 2019. There are two primary drivers behind this rise. First, the 8 TB drives as a group seem to be having a mid-life crisis as they get older, with each model exhibiting their highest failure rates recorded. While none of the rates is cause for worry, they contribute roughly one fourth (1/4) of the drive days to the total, so any rise in their failure rate will affect the total. The second factor is the Seagate 12 TB drives, this issue is being aggressively addressed by the 12 TB migration project reported on previously.

所以大原則還是跟以前差不多，沒有時間特別研究的話就先往 WD/HGST 這邊找...

EBS io1 推出可以同時掛到多台的選項

EBS 的 io1 推出了可以同時掛到 16 台 EC2 instance 的選項：「New – Multi-Attach for Provisioned IOPS (io1) Amazon EBS Volumes」。

先看支援的區域，傳統主力區域 (us-east-1 與 eu-west-1) 都支援了，而亞洲區這邊反倒是南韓先支援了：

Multi-Attach for Provisioned IOPS (io1) volumes on Amazon Elastic Block Store (EBS) is available today at no extra charge to customers in the US East (N. Virginia & Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Seoul) regions.

其中常用的目的是 HA：

Multi-Attach capability makes it easier to achieve higher availability for applications that provide write ordering to maintain storage consistency.

Heartbeat 類的應用應該可以用上這個東西，不過本來就可以透過 command line API 做到 detach & attach，用這個只是少了一個動作...

第二個想到的是，在實體機房的環境下，有些 filesystem (在「Shared-disk file systems」裡面可以翻到一些) 可以同時掛同一個 block storage (通常是透過 SAN)，現在在 AWS 上面也可以這樣搞了。

不過 io1 記得不便宜啊...