Message Arrival Rates and Latency

There is a common debate when people are discussing code optimisation that relates to how fast code needs to be. A recent Twitter post about parsing binance BBA messages stated processing times of around 200ns. This is, in my admission, is very fast. To put it into perspective, Serde is a common rust deserialization library and is incredibly easy to use. It is however, a lot slower than the optimised alternative taking around 2-3 micro seconds to do the same work. But who cares if your code takes 2 micro seconds longer to process a message? Is this going to make a huge difference to your pnl give that network jitter can be measured in milliseconds? The answer is yes, and maybe not for the reason you think.

Tick to trade (t2t) is measured as the time taken to receive a message and to generate some form of exchange api call (place/cancel/amend). This processing time can be measured either in software or at the network interface card. Most trading systems are event/message engines and at their core, the strategy is single threaded. If you are running a latency sensitive strategy, having a low tick to trade means an order get to the exchange sooner and has a higher chance of being filled.

For strategies like market making it is still really important to be fast, just for different reasons. The simplest reason is that if there is a signal that requires cancelling orders, we would like to do this as quickly as possible.

Leave a Comment