Imported from previous forum
Hi,
Is there someone can tell me how to calculate the latency of FIX engine？ In other words,what’s the definition of latency exactly?
The website(http://www.b2bits.com/performance_lab.html) calculates latency as time betwween the message requested to be sent and the message appearing in the network. However,what does the message appearing in the network means by?
Thanks in advance.
Lswallow
Hi Jun,
In general latency is the time elapsed between two events. For example the elapse time between sending a new order to exchange until receiving acknowledgement for this order.
There is no unique or standard method to measure latency.
One way is to capture messages on the wire (i.e. using wireshark/pcap applications) and calculate the difference time between two messages
In our example: New Order -> Acknowledgement (e.g. Execution Report having 39=0 150=0) will measure the elapsed time when the message exit the box where the order was generated until the acknowledgement enters the box where it should be processed.
When measuring latencies and moreover when comparing latencies, it is important to measure ‘apples to apples’ and to well define the start and end events.
Yuval
Hi Jun,
The challenge you have is measuring time lapse between the point of “ready to send” and the message sent.
As noted, possible the easier measurement is the on-the-wire on. I would suggest a tap on the line from your server to the first switch in the system and using a sniffer (with a suitable capture card) to capture the message into a pcap file with a high quality time stamp.
The challenge is getting a similarly accurate measurement upstream of the FIX engine since this is in application space. One way would be to build/buy some form of “application tap” where you can place a trap just before sending and in the trap apply a high resolution timestamp to a record and publish it (to a log file, or onto the network - there are products for this latter).
The clocks between the two capture points will need to be very well synchronised.
In fact, I suspect that in practice, it would be almost impossible to achieve meaningful readings without resorting to additional hardware (even assuming you have a sniffer).
I would change the measurement to a wire-to-wire measurement looking at the roundtrip of an order going to your FIX engine and a very simple application generating an ER response. The response could be prepared inadvance so that all that happens is that receipt of an order triggers the ER. The sniffer sees ithe inbound and outbound messages, timestamping them. You can then pair them and calculate the roundtrip latency - and the same clock is used for both messages, so the measurement should be accurate (although I suggest you do it a lot of times to make sure).
This is not the one-way latency, but it is a useful indication of performance.
Also, don’t forget that you are including a lot of time for things that are nothing to do with your FIX Engine - the latency from leaving your FIX Engine to reaching the wire can be substantially reduced with right set of optimisations.
Regards, Mark
Hi Jun,
In general latency is the time elapsed between two events. For example the elapse time between sending a new order to exchange until receiving acknowledgement for this order.
There is no unique or standard method to measure latency.
One way is to capture messages on the wire (i.e. using wireshark/pcap applications) and calculate the difference time between two messages
In our example: New Order → Acknowledgement (e.g. Execution Report having 39=0 150=0) will measure the elapsed time when the message exit the box where the order was generated until the acknowledgement enters the box where it should be processed.When measuring latencies and moreover when comparing latencies, it is important to measure ‘apples to apples’ and to well define the start and end events.
Yuval
Lswallow,
The latency of the FIX library is the time delay between two points - the moment your application decides to send and message, and the moment the message (as a binary stream of data) is transferred to the network stack.
This absolutely must include the time that FIX library takes to transform a native data structure used by your trading engine into a stream of bytes representing a FIX message, time it takes to send a message to the TCP/IP stack (usually it is done using “write” or “writer” system calls).
The test described by B2BITS is nice, but is technically useless and doesn’t tell you anything about latency. See, if you had that message that they are using in that test in the first place, then you’d not need a FIX library and could just call “write” and send those bytes into the socket. In real life, you will suffer from unnecessary data transformations, thread synchronization etc. Not to mention that Boost.ASIO that they use… well, it sucks for this tasks. However, to tell you the truth, their implementation is probably one of the fastest on the market, even though is it waaay too far from what it could be.
If you care about the latency, you should not use a FIX protocol in the first place unless exchange does not provide any API but FIX. See also - http://fix-engine.org/what-is-fix/the-need-for-better-fix-protocol