Latency गणित: futures execution के लिए exchange-proximity क्यों मायने रखता है
2026-05-06 · ~6 मिनट पढ़ना
"Low-latency" retail crypto trading में सबसे अधिक दावा किया गया phrase है। अधिकांश consumer-grade bots हर order को गलत continent के server के माध्यम से भेजते हैं और इसे तेज़ कहते हैं क्योंकि UI snappy लगता है। यह post वह गणित है जिसे हम चाहते हैं कि किसी ने पाँच साल पहले हमारे लिए लिखा होता।
Round-trip time वास्तव में क्या कर रहा है
Round-trip time (RTT) "हमारे order process को छोड़ते हैं" और "exchange की acknowledgement हमारे process तक पहुँचती है" के बीच का wall-clock interval है। इसमें outbound network leg, exchange match-engine queueing, और inbound network leg शामिल है। इसमें वह समय शामिल नहीं है जो हमने order भेजने का निर्णय लेने में बिताया। (यह एक अलग budget है; हम दोनों measure करते हैं।)
Passive limit order के लिए जो book पर रेस्ट कर रहा है, RTT वास्तव में महत्वपूर्ण नहीं है — एक बार order queued हो जाने के बाद, सिर्फ exchange का clock ही मायने रखता है। Aggressive order के लिए जो quote निकालता है जिसे आपने एक क्षण पहले देखा था, RTT सब कुछ है: flight में बिताया गया हर millisecond एक और millisecond है जिसमें कोई और अपना quote निकाल सकता है।
Region-of-deployment आपको कहाँ कुछ खरीद देता है
Major crypto venues के लिए exchange match engines एक handful physical regions में रहते हैं — आमतौर पर Singapore, Tokyo, और एक US-East zone। एक server में same region से आप sub-50 ms round trips की उम्मीद कर सकते हैं। गलत region के server से, यही call आमतौर पर 150 से 250 ms लेगा, dominated by speed of light through fiber से।
व्यावहारिक परिणाम: यदि आपका bot US data center से Singapore match engine को ping कर रहा है, तो आपने हर order पर roughly 200 ms दे दिया है। Aggressive order पर, यह displayed price पर fill करने और अगले tick पर fill करने — या बिल्कुल न fill करने के बीच का अंतर है।
कहाँ यह आपको कुछ भी खरीद देना बंद कर देता है
30 से 50 ms के आसपास किसी स्थान के बाद, retail-style strategies के लिए further latency reduction का marginal value collapse हो जाता है। Real high-frequency shops micro-second co-located cross-connects पर compete कर रही हैं — एक budget जो retail size पर pay back नहीं करता, और हम ईमानदारी से इस game को न खेलने के बारे में स्पष्ट हैं (देखें post on what high-frequency actually means in retail crypto)।
Retail-grade execution bot के लिए realistic target है: सही region में हो, low-jitter network path पर हो, well-tuned client के साथ हो। वह आपको उस floor तक ले जाता है जहाँ bottleneck आप होना बंद कर देता है और market structure होना शुरू कर देता है।
हम कैसे measure करते हैं (और हम इसे publish क्यों करेंगे)
हम RTT को continuously हर region से measure करते हैं जहाँ हम deploy करते हैं, हर exchange के विरुद्ध जहाँ हम trade करते हैं। Proof page पर आप जो number देखते हैं, वह "best ever recorded" नहीं है — यह rolling measurement है, जो एकमात्र honest version है। Marketing teams floor print करना पसंद करते हैं; traders median, 95th percentile, और day के worst minute की परवाह करते हैं।
जब live data feed Phase 5 में light up करता है, तब proof page पर latency table continuously refresh होगा और उस region को label करेगा जो वर्तमान में router द्वारा live order flow के लिए चुना गया है।