幹壞事是進步最大的原動力
AWS 開始陸陸續續在推出有 100Gbps 能力的 EC2 instance 了：「New – EC2 P3dn GPU Instances with 100 Gbps Networking & Local NVMe Storage for Faster Machine Learning + P3 Price Reduction」。
從「Amazon EC2 Instance Types」這邊可以看到先前只有 c5n.18xlarge 有支援 100Gbps 網路，現在推出的 p3dn.24xlarge 是第二個支援的...
另外是 P3 系列的降價消息，比較奇怪的是從 2018/12/06 開始生效，而不是從月初開始。另外區域與條件也有一些複雜，有常在用的人可以翻一下說明...
AWS 宣佈提昇了 Amazon EBS (gp2) 的效能：「Amazon EBS Increases Performance of General Purpose SSD (gp2) Volumes」。
本來上限是 10k IOPS，現在提升到 16k IOPS 了。另外最大傳輸速度也從 160 MB/sec 提升到 250 MB/sec：
Today we are announcing a 60% improvement in performance of General Purpose SSD (gp2) Volumes from 10,000 IOPS to 16,000 IOPS and from 160 MB/s to 250 MB/s of throughput per volume.
應該還是維持 3 IOPS per GB 的設計，但這對於想要用 gp2 堆效能的人來說算是好消息，可以用更大的空間堆出更多 IOPS 了... (像是「Percona 的人接受 AWS 的建議，重新測試了 Percona XtraDB Cluster 在 gp2 上的效能...」這篇)
看到「HashiCorp Vault 1.0」這則消息，Vault 要出 1.0 不是什麼新聞，重點是他把跟 Cloud Auto Unseal 的功能放出來了：
In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.
可以看在 AWS 上的作法：「Auto-unseal using AWS KMS」。
這樣在雲上的服務可以再降低風險...
AWS 推出了 Amazon Elastic Inference，可以讓你選擇 GPU 的量掛進 EC2 instance：「Amazon Elastic Inference – GPU-Powered Deep Learning Inference Acceleration」。
第一眼看到的時候在想這不是之前出過了嗎... 後來搜尋發現應該是針對圖形運算與 machine learning 的應用拆開使用不同的硬體？
所以在前陣子 AWS 公告將 Amazon EC2 Elastic GPUs 改名為 Amazon Elastic Graphics：「Amazon EC2 Elastic GPUs is now Amazon Elastic Graphics」。
舊的 Amazon EC2 Elastic GPUs (Amazon Elastic Graphics) 應該是針對圖形應用設計，而新的 Amazon Elastic Inference 則是針對 machine learning 設計。
AWS 對 EC2 instance 推出了休眠模式：「New – Hibernate Your EC2 Instances」。
休眠模式主要是透過保留記憶體內的內容 (會寫到 EBS 裡)，讓機器開起來比較快，不過這邊有要求 root EBS volume 需要加密：
When an instance is instructed to hibernate, it writes the in-memory state to a file in the root EBS volume and then (in effect) shuts itself down. The AMI used to launch the instance must be encrypted, as must the root EBS volume of the instance. The encryption ensures proper protection for sensitive data when it is copied from memory to the EBS volume.
費用的部分是 EBS volume 與 Elastic IP：
While the instance is in hibernation, you pay only for the EBS volumes and Elastic IP Addresses attached to it; there are no other hourly charges (just like any other stopped instance).
一般對外服務的伺服器好像用不太到... 應該是內部系統或是開發機的需求？
AWS 推出的新服務，AWS Ground Station：「AWS Ground Station – Ingest and Process Data from Orbiting Satellites」。
AWS 目前在地面上見了兩個基地站 (預定要成長到 12 個)，這個服務可以跟衛星溝通：
Ground Stations – As I mentioned earlier, we are launching today with 2 ground stations, and will have a total of 12 in operation by 2019. We will monitor utilization and demand, and will build additional stations and antennas as needed.
收費是按照分鐘計算：
Pricing – Pricing is per-minute of downlink time, with an option to pre-pay for blocks of minutes.
看起來是給租用衛星頻寬的人用的... 不過當初會決定作這個服務是吸了什麼 XDDD
看到 AWS 推出使用 ARM 架構的 EC2 instance 了：「New – EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors」。
在 Quick Start 頁面有 Ubuntu 18.04 (ARM) 可以選，開起來後操作跟標準的 Ubuntu 差不多... 連進去後 uname -a 可以看到是 aarch64：
ubuntu@ip-172-30-2-207:~$ uname -a Linux ip-172-30-2-207 4.15.0-1028-aws #29+nutmeg8-Ubuntu SMP Tue Nov 20 02:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
然後來看硬體規格，從最大台的 a1.4xlarge 來看是 16 vCPU + 32 GB RAM，定價是 $0.408/hr (這邊都拿 us-east-1 比較)。
對照 General Purpose 的 m5.4xlarge 是 16 vCPU + 60 GB RAM，定價是 $0.768/hr。如果看記憶體比較接近的 m5.2xlarge 則是 8 vCPU + 31 GB RAM，定價是 $0.384/hr。
對照 Compute Optimized 的 c5.4xlarge 是 16 vCPU + 68 GB RAM，定價是 $0.68/hr。
實際跑一些測試，包括 md5、sha256 與 aes (最後 aes 這個通常都有硬體加速)，都用 -mutli 16 跑。
ARM 的 a1.4xlarge：
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 1064103.21k 2484789.44k 4436178.60k 5521370.45k 5943380.65k 5963896.15k sha256 2059690.93k 5652827.82k 11792656.30k 16108863.15k 18086602.36k 18250851.29k
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 1593981.48k 1723960.38k 1752940.20k 1767321.94k 1770212.01k 1768281.43k aes-192 cbc 1400010.40k 1496414.83k 1516962.99k 1527643.82k 1529834.15k 1527563.26k aes-256 cbc 1222067.79k 1296972.50k 1313348.18k 1321350.83k 1322947.93k 1321850.20k blowfish cbc 1384982.01k 1500548.63k 1529793.02k 1540091.22k 1540937.05k 1540767.74k
Intel 的 m5.4xlarge：
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 1370869.17k 3276978.66k 5929591.13k 7441276.93k 8026330.45k 8071796.05k sha256 592719.47k 1325135.04k 2506009.09k 3184234.50k 3455729.66k 3480365.74k
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 1060996.96k 1121951.87k 1135376.21k 1141487.96k 1143270.06k 1143499.43k aes-192 cbc 890438.97k 934047.98k 943446.44k 947576.49k 948857.51k 949026.82k aes-256 cbc 768686.53k 800152.85k 806883.93k 809804.12k 810784.09k 810937.00k blowfish cbc 1735490.97k 1884059.78k 1923876.10k 1932711.94k 1934477.99k 1928680.79k
Intel 的 c5.4xlarge：
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes md5 1501870.92k 3593434.20k 6503591.25k 8162811.90k 8804605.95k 8855147.86k sha256 650179.22k 1453635.18k 2749318.83k 3492912.13k 3791164.76k 3818105.51k
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 1163898.98k 1230539.07k 1244414.63k 1252080.98k 1254110.55k 1254206.12k aes-192 cbc 976610.23k 1024570.03k 1034886.66k 1039442.26k 1040872.79k 1041143.13k aes-256 cbc 843184.42k 877695.30k 885125.46k 888408.06k 889503.74k 889766.83k blowfish cbc 1877162.34k 2056925.74k 2107008.26k 2119893.67k 2121979.22k 2115720.53k
這些數字頗有趣的... 看起來 ARM 上面應該有對某些演算法加速，使得常見的情境會快很多。不過如果是其他應用的話看起來就會比較辛苦了... 目前就價錢來看未必有絕對的優勢，還是得看應用來決定。
看到「Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower」這篇測試了目前還在 RC 的 4.20.0，可以看到 AMD 的效能沒有太大影響，但 Intel i9 的效能掉了很嚴重：
從說明可以看到有測出 30%～50%：
This ranged from Rodinia scientific OpenMP tests taking 30% longer to Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.
另外在其他 Intel CPU 上測試也發現不是只有 i9 有影響，低階的機器也是：
Those affected systems weren't high-end HEDT boxes but included a low-end Core i3 7100 as well as a Xeon E5 v3 and Core i7 systems.
透過 bisect 有找到是哪個 commit 造成的：
That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.
但這又是屬於 security patch，不太能關... 加上自從 Meltdown 與 Spectre 後，讓安全研究人員發現了全新的天地，之後應該只會愈來愈慘 :o
看到拿 ESP8266 模擬 PC-XT，是個懷古時間：「IBM PC-XT Emulator on an ESP8266」。
現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了，直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑：
然後也可以跑 Windows 3.0：
純粹 hacking 的專案 XD
在 Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇，講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景：「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。
Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。
這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」)，回報後先是回應他們在處理中，然後被發現 VirtualBox 在 5.2.18 修掉了，但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了，找到就 full disclosure 出來。
作者給的 workaround 有兩個，優先建議暫時先用 PCnet 系列的界面，如果不行的話，至少不要用 NAT。
作者發表後沒多久馬上就有 5.2.22 推出，不過看 changelog 應該是沒有修正這個問題？(或是修掉又沒提...)