Category Archives: Hardware

修正 Mac 外接螢幕的 Underscan 問題

公司的 MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) 透過 HDMI 接 Dell P2419H 一直都有 Underscan 的問題:


出自「About overscan and underscan on your Mac, Apple TV, or other display

本來想透過 Underscan slide 修改 (像是下面這張圖),但發現系統內沒有 Underscan slide。


出自「About overscan and underscan on your Mac, Apple TV, or other display

找了不少文章後後來是在「Fixing Issues with Overscan/Underscan(Black Borders) on macOS」這篇的 comment 看到解法:

Ran into this same underscan problem with black borders showing up on my new Dell 24-inch Ultrasharp U2415 connected to a 2013 Macbook Air running High Sierra, and after hours of looking into the problem the fix turned out to be super simple:

Just restart in Safe Mode.

That’s it. Restart your Mac in Safe Mode (restart, hold down the Shift key after the Apple BONG sounds, then restart normally once again for good measure. I don’t know what this clears or resets but it worked for me. No more letterboxing or black borders with the native 1920×1200 resolution selected.

So maybe something to try first for anyone coming across this post.

照著重開進 Safe mode 後再開回一般模式就正常了 (what???),先記錄起來,讓我之後遇到時可以搜尋到自己的文章...

F5 買下 NGINX Inc.

F5 宣佈併購 NGINX Inc.,雙方的新聞稿都出來了:「F5 Acquires NGINX to Bridge NetOps & DevOps, Providing Customers with Consistent Application Services Across Every Environment」、「NGINX to Join F5: Proud to Finish One Chapter and Excited to Start the Next」。

SEATTLE and SAN FRANCISCO – F5 Networks, Inc. (NASDAQ: FFIV) and NGINX today announced a definitive agreement under which F5 will acquire all issued and outstanding shares of privately held NGINX for a total enterprise value of approximately $670 million, subject to certain adjustments.

印象中 NGINX Inc. 的文章常常在批評 F5 這類 load balancer 太貴,現在是在演哪齣戲... 然後這不知道對 open source community 來說是不是好下場,也許如果真的發現風頭不對的話就會有人 fork?(AWS?他們最近好像對這個議題頗敏感 XDDD)

Percona 對於 PostgreSQL 使用 HugePages 的評論

開頭我先說一下我的想法,我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度,因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果,但卻給不出合理的原因,甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋:

Hi,

A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇,也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響,同樣馬上又看到奇怪的東西...

首先是標示與圖片不合:

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB),當做是標錯就好。

但這樣又跑出一個奇怪的結果,48GB 的資料量比較小,TPS 大約是 35K/33K/41K,但 112GB 資料量比較大,卻可以達到 39K/43K/41K~42K,反而比較快?我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch,先不管),其中 pgbench 跑了 10 mins 與 60 mins 的版本,但是 sysbench 只跑了 10 mins 的版本?這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients),如果以直覺來說的話,我反而還是會打開 HugePages (yeah 純粹是直覺),我現在比較想知道他會在 Percona 裡面待多久...

所以蘋果開始放鬆 iPhone 的第三方電池保固問題了?

MacRumors 上看到的,先前只要透過第三方更換電池,蘋果就會拒絕後續所有保固,現在內部文件改成不保固電池的部分,其他的元件還是會提供保固:「Apple Says iPhones With Third-Party Batteries Now Eligible for Repairs」。

iPhones with aftermarket batteries installed by third-party repair shops are now eligible for service at Genius Bars and Apple Authorized Service Providers, according to an internal Apple document obtained by MacRumors from three reliable sources.

不確定是不是全球性的,但至少法國已經是了?

突然想到『FTC 警告 Nintendo 與 Sony「拆封喪失保固」違反聯邦法』這篇,雖然兩者討論的主題不太一樣...

「歡樂」的 USB cable...

在這邊看到的,把整個惡意晶片藏在 USB cable 裡面,讓攻擊者可以透過 Wi-Fi 控制主機的 O.MG Cable:「WiFi Hides Inside a USB Cable」。

是個大家都有想過的情境,不算是特別的技術,困難點在於空間有限 (要藏在接頭裡面),現在有人做出 prototype 了... 在 demo 影片內可以看到可以透過 Wi-Fi 開啟主機本身的 browser 並且連線,不知道是模擬鍵盤還是其他方式做的?

AWS 推出新的 Bare Metal Instances

AWS 針對各個 family type 都推出 Bare Metal 版本:「Now Available – Five New Amazon EC2 Bare Metal Instances: M5, M5d, R5, R5d, and z1d」。

AWS 第一次推出 Bare Metal 版本是在 2017 年年末推出的 i3.metal:「Amazon EC2 推出第一款 Bare Metal 的 Instance」,這樣算一算也一年多了,這次算是補產品線...

要注意的是,這次推出依照區域有不同的機種,像是 Ohio 沒有 z1d.metal 但有其他四種,N. California 則是沒有 m5d.metal 但有其他四種... 要先看一下表格才能確認每一區的情況 @_@

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...

組一台 RISC-V 的 PC

RISC-V 是目前最有名的 open source 指令集,但似乎不太好找對應的硬體... 在「Building a RISC-V PC」這篇則是介紹了怎麼弄一台 RISC-V 的 PC:

採用的硬體是 HiFive Unleashed (USD$999),硬體架構包括了:

  • SiFive Freedom U540 SoC
  • 8 GB DDR4 with ECC
  • Gigabit Ethernet port
  • 32 MB quad SPI flash from ISSI
  • microSD card for removable storage
  • FMC connector for future expansion

沒有 USB 與 HDMI,作者是透過 HiFive Unleashed Expansion Board (USD$1999) 接出來的,不過這張還包括了 FPGA,這好像有點超過,兩個套件再加上 M.2 或是 SATA 的 disk 應該是超過台幣十萬...

不過畢竟算是早期的產品,之後有規模後應該會開始有中低價位的產品出現...

Linode 推出 Dedicated CPU Instances

Linode 決定要推出 Dedicated CPU Instances,看起來相當於 AWSEC2 裡一般性的 EC2 instance (指非 t 系列的),跟之前 CPU 共用而導致 CPU 可能時快時慢不同,這個方案讓 CPU resource 穩定輸出:「Introducing: Linode Dedicated CPU Instances」。

Dedicated instances are optimized for workloads where consistent performance is required or where full-duty work (100% CPU all day, every day) needs doing.

拿 EC2 裡的 c5.large (2vCPU + 4GB) 比較差不多是一半的價錢,但實際不知道差多少... 回台灣的時候測試看看好了。看起來如果真的要在 Linode 上跑 Kubernetes 的話反而要用這種機器?