各高頻業者在系統延遲的競爭已經到了10微秒以下等級的競爭、更甚者對於訊息封包所能節省的時間追求也到了奈秒等級的競賽。撰寫/設計系統的你,完成了一個令人振奮的巨作,準備上戰場大展身手的時刻,是否曾有那麼一時半刻疑惑自己設計的武器是否真的經得起市場上的淬鍊? 抑或,在正式戰場見真章、不成功便成仁? 沒有十足十的把握上戰場,所看到的大部分結果是上場即退場,這可不是一位受過訓練的程式設計者所樂見的。
如何可以上戰場前,九成九的確認自己手上的武器是可信賴的,不難,你所需要的就是一套精準測試架構或者測試方法,而對latency要求錙銖必較的HFT業者在測試上常常面臨幾個問題:
在程式碼中安插log紀錄Timestamp以統計時間差,這個方法在開發初期粗略抓的時耗是可行的,可輔助開發者近期初階段的效果評估,但要做到精準量測這可不是一個好辦法;一方面OS所能記錄的Timestamp精準度有待商榷;二者,硬將時間搓記的訊息安插在軟體程式,那勢必必須和軟體共用資源影響程式主體效能,比如CPU caches。
在OS層級記錄時間搓記容易因種種因素導致不夠精準,如系統jitter 或程式問題或OS本身精準度,想要達到一個準確且精準度夠小的測試結果,有幾個要點要掌握:
如何架構一個量測latency的環境呢?
環境一:量測主機內封包IN/OUT的所耗時間
如圖1,利用分光器將進出封包打給受測者與TS分析主機,分光器的物理特性並不會造成延遲,所以TS主機所收到的封包即為受測者本身的IN/OUT封包,藉此計算時間差。
TS主機必須安裝具備紀錄時間搓記的網卡,一般程式設計者慣用程式紀錄Timestamp,在此不建議這麼做,一來失真,二來單位精準度不夠。此架構亦可免於干擾受測者。
環境二:衍生應用量測NIC Performance.
類似的架構,可以再衍生成網卡的效能測試,此架構受測者OS幾乎不做任何事,至多是將收到的封包在送出到目的端。受測網卡裝置於受測主機中。
環境三:HFT業者一般會使用那些品牌設備呢?
NIC[2] : Solarflare, Exablaze ExaNIC, Mellanox
Switch : Cisco N3K、ExaLINK Fusion、Arista7130 L1 Switch
[1] Exablaze已於2019合併Cisco,系列產品名為: Nexus X10,Nexus X25, Nexus X40, Nexus X100
[2] 有HFT業者更甚者會採用更精準的FPGA計算latency,但畢竟FPGA入手門檻較高,此篇以網卡應用為主。
Copyright © 2020 HyperShark Technologies Corp. All Rights Reserved.