Intel 與 AMD 在 RSQRTSS 的不同

看到「rr Trace Portability: Diverging Behavior of RSQRTSS in AMD vs Intel」這個,作者因為在 rr 上發現 replay 不正確,發現是 SSE 裡面的 RSQRTSS 這個指令在 IntelAMD 平台上會有不同的值出現導致的。

RSQRTSS 是計算平方根倒數,也就是計算 1 / \sqrt{x},另外比較特別的是,這個指令不保證正確性,是允許有誤差產生的。

提到平方根倒數,這個演算法更有名的應該是「反平方根快速演算法」這個用到 0x5f3759df 這個魔術數字的奇技淫巧,不過這不是這次的重點...

作者發現 RSQRTSS 在 Intel 與 AMD 平台的值不一定一樣,像是 256 的平方根導數是 1/16 (0.0625),但兩個平台跑出來不同:

On Intel Skylake I get
out = 3d7ff000, float = 0.062485

On AMD Rome I get
out = 3d7ff800, float = 0.062492

在這邊的 case 可以看出來 AMD 算的比較正確 (誤差值比較低),但都還是在 spec 允許的誤差範圍。

後來作者還發現有其他不同的指令也有類似的問題,為了解決在 rr 上可以正確 replay 的問題,他生了對應的 mapping table 來解:「Emulating AMD Approximate Arithmetic Instructions On Intel」。

苦啊... 不過這個主題還蠻有趣的。

Firefox 支援 HTTPS RR

在「Firefox 92.0, See All New Features, Updates and Fixes」這邊看到支援 HTTPS RR:

More secure connections: Firefox can now automatically upgrade to HTTPS using HTTPS RR as Alt-Svc headers.

在「Enabling HTTPS RR on release」這邊決定啟用的,使用的標準是「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」這個,可以看到目前還是 draft (draft-ietf-dnsop-svcb-https-07)。

HSTS 是 Trust on first use,也就是在第一次連線時 server side 會送出 HSTS header,之後瀏覽器遇到同一個網站時就會都強制使用 HTTPS。

如果要確保第一次也是強制使用 HTTPS,在這之前必須靠瀏覽器內建的清單 HSTS Preload List 才能確保安全性,這次的 HTTPS RR 算是補上這個缺口。

在使用者環境有 DNS over HTTPS (DoH) 或是 DNS over TLS (DoT),再加上 DNS resolver 會檢查 DNSSEC 的前提下,整條環境就接起來了。

不過實際讀了 spec 會發現 SVCB RR 與 HTTPS RR 想做的事情太多了,話說愈複雜的東西愈容易出包,先放著觀望看看好了...

又再次看到了 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 方式來說,這個猜測應該是對的...

AWS 的 ALB 可以用最少未處理連線數分配了

AWSALB 總算提供「最少連線數」的功能了:「Application Load Balancer now supports Least Outstanding Requests algorithm for load balancing requests」。

先前只有 Round robin (RR),現在支援 Least outstanding requests (LOR) 後可以往比較少的塞了,這個方法在大多數的應用上比 RR 合理多了,現有的 ALB 應該都可以考慮換過去...

補功能不算快,但有種已知用火的感覺 XD

Cloudflare 的 DNS Resolver 也提供 Purge 功能了

Cloudflare 提供的 1.1.1.11.0.0.1 也提供 purge 功能了,在 https://cloudflare-dns.com/purge-cache/ 這邊:「Refresh Stale DNS Records on 1.1.1.1」。

Google 的類似:「Flush Cache | Public DNS | Google Developers」。不小心弄錯東西,有需要 purge 的時候還蠻方便的...

Microsoft 的 TTD 與 Mozilla 的 RR

也是個在瀏覽器 tab 上放了一陣子的連結... 先前看到 MicrosoftTime Travel Debugger (TTD),可以錄下程式執行的狀態,然後回放與搜尋:「Thoughts On Microsoft's Time-Travel Debugger」,另外有 CppCon 2017 上的影片,在 YouTube 上:

另外 Mozilla 也有類似的工具,叫做 rr (在影片開頭就有人問類似的問題 XD),程式碼在 GitHub 上:「mozilla/rr」。

而 TTD 與 rr 兩者最大的差異當然是平台支援的情況:

The most important and obvious difference between TTD and rr is that TTD is for Windows and rr is for Linux (though a few crazy people have had success debugging Windows applications in Wine under rr).

但另外一個也很重要的差異是 TTD 支援完整的 multi-threading,這對於現代的程式來說還蠻常見的:

TTD supports recording of multiple threads in parallel, while rr is limited to a single core.

當然,更完整的錄影也是要付出效能代價的:

On the other hand, per-thread recording overhead seems to be much higher in TTD than in rr. It's hard to make a direct comparison, but a simple "start Firefox, display mozilla.org, shut down" test run on similar hardware takes about 250 seconds under TTD and 26 seconds under rr.

不過有需要的時候應該會很方便?工具總是愈多愈好...

PChome 修正了問題,以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題:「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」,這邊除了整理一下以外,也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時,DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法,當只有 A RR 沒有 AAAA RR 的時候,應該要傳回 NOERROR,而 answer section 裡面不要放東西:

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到,如果傳回 NXDOMAIN (3),表示查詢的這個名稱完全沒有 RR,而不僅僅限於 AAAA record,這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN):

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN):

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考,像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath),這些文件描述了蠻多常見的問題以及正確的處理方法,讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。

MySQL 上不同 Isolation Level 對效能的影響

目前看到的結論都是:MySQL (InnoDB) 上因為高度對 RR (REPEATABLE-READ) 最佳化,使得 RR 的效能反而比 RC (READ-COMMITTED) 以及 RU (READ-UNCOMMITTED) 都好。

不清楚 RR/RC/RU 差異的可以參考維基百科上「Isolation (database systems)」的解釋...

從 2010 年在測 5.0 的「Repeatable read versus read committed for InnoDB」到 2015 年測 5.7 的「MySQL Performance : Impact of InnoDB Transaction Isolation Modes in MySQL 5.7」都測出 RR 的效能比 RC/RU 好... 三段分別是 RR/RC/RU:

所以在 MySQL 上沒有使用 RC/RU 的必要... (抱頭)