跨交易所的延遲和延遲
我最近看到了 Battlio 等人的這篇論文。“經紀人可以擁有一切嗎？關於收取費用與限價單執行質量之間的關係”，並意識到我對連接交易所的“管道”知之甚少（我正在研究美國股票。）
閱讀本文後，我一直在思考在多個交易所同時交易時會有什麼樣的延遲/延遲。假設我已經決定了限價單的大小和我想要發送它們的目標地點，並且假設我同時將限價單發送到各個交易所，我可以在時間戳中期待什麼樣的延遲各個交易所的數據饋送中報告的“限價訂單送出”消息？我認為這取決於我與交易所的聯繫方式、一天中的時間、股票的類型等等，但我仍然對一系列可能的值感到好奇。
從 A 點到 B 點匹配引擎的往返延遲可以認為由兩個部分組成：
$ RTT_{total,A \rightarrow B} = RTT_{network_transit,A \rightarrow B} + MPL_{matching_engine,B} $
在哪裡 $ RTT $ 是往返時間和 $ MPL $ 是消息處理延遲（接收消息並產生事件所需的時間）。總往返時間， $ RTT_{total} $ 將從它離開您的網路介面的那一刻起（即，不包括您的軟體可能有的任何內部處理日期）到您的網路介面收到指示該操作已處理的消息的那一刻起進行測量。您可能會發現我關於延遲資訊的其他答案：HFT - 如何定義和測量延遲？.
現在，關於 $ RTT_{total} $ ：當與不同數據中心中的交易所通信時，傳輸延遲幾乎總是占主導地位。匹配引擎非常快，但相比之下，移動數據包可能相對較慢。例如，從 Carteret（納斯達克託管他們的匹配引擎）到 Mahwah（紐約證券交易所託管他們的引擎）大約有 45 英里（來自Google地圖的粗略測量）。最佳情況往返傳輸延遲約為 500 $ us $ （約 250 $ us $ 一種方式），但由於與網路傳輸相關的摩擦，這是無法實現的：（1）光纖不會像烏鴉飛一樣執行；(2) 交換機和路由器沿途增加延遲；並且，（3）數據包不會以光速通過光纖（我相信它是大約 70% $ c $ ).
現在，Mahwah 和 Carteret 是兩個極端案例，因為它們是彼此相距最遠的兩個數據中心。BATS 數據中心位於 NY5 的 Weehawken。該數據中心大約位於 Mahwah 和 Carteret 之間的中點，因此您將看到大約 250 的最佳情況（無法實現）往返延遲 $ us $ .
傳輸延遲也是唯一直接受參與者控制的組件。 $ MPL_{matching_engine} $ 對於所有參與者來說，它在很大程度上是一個常數（儘管並不總是由於匹配引擎架構和訂單輸入網關的載入）。 $ RTT_{network_transit} $ 另一方面，可以通過減少上述 3 個摩擦中的 2 個來進行操作。“Flash Boys”中的啟示在整條街上都廣為人知（Brad 和 IEX 的傢伙似乎有點遲到了）：在最大限度地減少第一次摩擦的影響方面有很多唾手可得的成果：路徑纖維所需要的。通過這樣做，精明的參與者可以在相對基礎上更接近其他匹配引擎，即使他們在現實空間中直接位於他們的競爭對手旁邊。
請記住，此討論幾乎完全限於跨數據中心消息傳遞。幾乎沒有能力將影響最小化 $ RTT_{network_transit} $ 在單個數據中心內，因為：(1) 對於所有交叉連接的參與者，光纖互連的長度在很大程度上是標準化的；(2) 參與者和匹配引擎之間的網路元素很少。這意味著對特定參與者的內部延遲是最重要的（換句話說，更快的軟體）。
話雖如此，具體回答您的問題並不是很多人會做的事情，因為延遲數字接近背心。但是，以上所有的原因是向您證明，您可以通過簡單的估計來輕鬆估計它 $ RTT_{network_transit} $ . 我想你會發現，例如， $ RTT_{total,NASDAQ \rightarrow ARCA} $ 將在 600 之間 $ us $ 和 1.5 $ ms $ 假設數據包通過光纖傳輸 $ 0.7c $ 然後取決於您要為光纖路徑添加的懲罰。