By XTRD’s Co-Founder and CTO Serg Gulko
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. By the way, we replicated all this in the XTRD eco-system, which is why our NY4 location is equipped with Aristas and Exablaze servers!
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. By the way, we replicated all this in the XTRD eco-system, which is why our NY4 location is equipped with Aristas and Exablaze servers!
But, of course, all these optimizations should be made only after your code is tuned to perfection. There is no economic sense in burning thousands of dollars on expensive hardware toys when you might have a bigger problem and one that's closer than you think.
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 (by the way, we also use Avelacom for certain destinations) 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. Don’t get me wrong, CCXT is a great library and I personally do respect the Open Source community but CCXT is not about HFT! So the fund guys win 7 ms by using high-end hardware and private networks but lose sometimes up to 200 ms by using the wrong software.
Why do I think XTRD can do any better? One of our main focuses was – and still is – lowering latency in all possible ways. We analyze exchanges’ APIs, measure execution times, and build our connectors in order to notify clients as soon as possible when something happens.
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 (at least from our standpoint) but sometimes it comes with a 300 (!) ms delay after similar, but less granular, updates in “orders”. What is really funny is that initial responses over the REST API come (sometimes, not always, which makes it even more interesting) faster than confirmations through SignalR. We know all these nuances and our connectors are capable of dealing with such situations. Of course, it creates certain complexity and non-linear logic but this is what we do for a living.
Another example: When you cancel an order on Binance, you can rely on WebSocket notifications (which is very convenient) 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.
Each exchange has such “Easter eggs” and we know many of them. XTRD combines powerful hardware with a software layer, optimized to “shave” 10 ms here and 45 ms there. If you are committed to winning, everything matters – your algo, the way it is coded, servers to run it, the right network to communicate, and a reliable partner to execute. Cut these latencies with XTRD.
Join the club!
Also published here.