Among many technical questions we receive, the latency-related group definitely stands out. Having deep HFT roots, I fully share concerns about this topic. Back in the day, building strategies for FX markets, we were choosing one CPU family over the other, preferring to use switches and routers of certain non-mass-market brands, install and tune very specific network cards, and so on.
We’ve been consulting several so-called “crypto-first” prop trading shops who bought absolutely top-of-the-line/high-cost servers and rented private internet lines from Avelacom to shave 4-7 ms of network-added latency. But! And here comes the best part – they had plans to use the CCXT library to trade.
Let me give you an example. Bittrex has a REST API to submit orders and an event-driven notification channel built on top of the terrible Microsoft SignalR stack. SignalR, in its turn, provides information in “orders” and “executions” channels. Data from the “executions” channel is more informative and useful but sometimes it comes with a 300 ms delay after similar, but less granular, updates in “orders”.
Another example: When you cancel an order on Binance, you can rely on WebSocket notifications but in many cases, the REST API gets you a faster response. How fast? 10 ms! So you’ll know that your order has been canceled 10 ms faster and act on it accordingly. In the HFT world, 10 ms is almost an eternity.combines powerful hardware with a software layer, optimized to “shave” 10 ms here and 45 ms there.