Hardware & Networking of Automated Systems

Share on Facebook0Tweet about this on Twitter0Share on LinkedIn1Share on Google+0

Automated Trading makes use of electronic platforms to send orders, receive executions. It is essentially the process of taking active human involvement out of the picture. That sounds fancy and with all the attention that algorithmic trading seems to be attracting off late, both good and bad, this term has reached more minds in the last one year than it did in the decade before. So what exactly does it take to build an automated system? Can anyone with a strategy write a program and start trading in an automated fashion? We will try to address few of these questions in this post.

First things first, in order to receive data or send orders; the platform/program needs to be able to communicate with the exchange. This connectivity can be established in a number of ways. Usually it is done through a lease line between the exchange and the server (which is trading). In India, this is done through dedicated lease lines, while some exchanges globally allow connectivity over internet lease lines. The only practical difference between the two, from a trader’s perspective, is the network latency. Some destinations (exchanges, liquidity providers) also allow connecting over the internet. The bottom line is establishing the connectivity between the two ends, namely, the trader and the destination. The destination on its end typically provides a host IP and a port number for the trading system to connect to. This connection to the host IP and port number is often referred to as the session and the parameters that configure a session (IP and port number, username, etc) are called session parameters.

Once a session has been established, both ends need to communicate. Just like how two people need to know a common language to talk to each other, two servers need a common protocol to communicate. FIX is a standard protocol designed for communication with exchanges and trading destinations. Any destination that designs its own protocol is said to be using a native protocol. Depending on the protocol, the series of messages and their sequencing might vary but by and large, they achieve, order management and data propagation. On the trader’s side, the layer that communicates with the exchange is called the Adaptor. The two main jobs of the adaptor are to receive data and manage order routing messages. Once a data packet reaches the adaptor on the trader’s side, the trading system/platform/program needs to take a decision based on this data point and consequently generates a corresponding order message.

That sounds simple enough. What exactly is the complex part? Typically, the complexity arises from the need to reduce the network latency between the destination and the trader. For e.g. Lotus Capital claimed to have done a rigorous analysis of its trading systems and concluded that a latency of 3 microseconds was causing it to lose a $1000 every day. If one thinks about it, light (or any other form of electromagnetic wave) takes about 1 ns to cover a distance of 1 m. That is about 100 ns to cover 100 m. However, in reality, the time taken by the network packet is orders of magnitude longer. To reduce this time gap, some destinations even allow trading systems to be stationed within the premises of the destination. This is often referred to as Co-location, meaning, your trading system is co-located with those of the exchange. Even in cases such as this, the latency can be as much as 0.5ms, i.e. 5000 times more than our estimate of 100ns. So where is this delay coming from?

The delay comes in because, there is a lot more happening during this communication than just the physical travel of the packet on the wire. The following diagram illustrates broadly the different layers that exist before the packet sent by the exchange reaches the memory of the application/trading platform. As can be seen, the easiest way to reduce the latency is to be physically closer to the destination. However that may not always be possible since:

  • the co-location space is always limited and is often quite heavily contested,
  • if the strategy involves working with multiple destinations, the server can’t be close to all the destinations at once.

Even after the packet reaches the trading system, it goes through a router, at least one switch and then reaches the server.  In the server it has to go up the network stack from the buffers of Network Interface Card (NIC), to the operating system (Kernel) to the application memory.  Here, the feed handling adaptor, then strips the packet for necessary information and then hands it over to the strategy. The strategy would then work out the trading logic and in the event of sending an order, the reverse takes place and the packet travels back to the exchange.

Working on an automated system, one must be extra careful about the possibility of something going wrong. And in the extraordinary situation where things do go wrong, chances are things will be bad UNLESS stringent risk management is in place.  Of course, that also means things becoming a bit slower.  The following diagram puts this in perspective.

It is easy to see how the 1 usec that the packet took to actually reach the router got magnified to 450 usec (0.45msec) by the time the strategy actually got it in its memory.

That sounds like quite a downer in our race to 0-latency. But there is a silver lining to this. There is a lot we could do to tune this. How, will form a part of another blog post. More importantly, Lotus capital was able to tune the router latency by 3 micro seconds and the application by 2 microseconds and thus made a comeback.

 

Share on Facebook0Tweet about this on Twitter0Share on LinkedIn1Share on Google+0

Leave a Reply

Your email address will not be published. Required fields are marked *