Why? There will always be spikes. If your application is ready to receive the next message just as it arrives, then that message can be processed with the lowest-possible latency. However, if your application is still processing the previous message when the next one arrives, then there will be some latency before the arriving message can be processed.
It only takes two messages to make a spike--the second just has to arrive before the first has been completely processed. If anything, the trend in market data is toward ever larger and more frequent spikes. Hence we recommend accepting spikes as a fact of life and planning to deal with them in the best possible way rather than designing systems as though spikes don't exist.
How will your market data applications behave in response to a spike in market data rates? Broadly speaking, there are three possibilities.
No increase in latency: Your application and the underlying infrastructure have enough reserve capacity to handle the spike without adding latency. This is the desired outcome, but it requires that unused capacity be held in reserve anticipating the spike's arrival. That may be prohibitively expensive. This is the case mentioned above where all previous messages have been completely processed before the next one arrives.
Graceful operation with increasing latency: There is insufficient capacity to handle the spike in real time, so latency must be added to some messages by queuing them until they can be processed.
Unstable operation or crashing: Once arriving messages are queued, there's the question of how many should be queued and/or how long they should be held. Queues are often fixed size requiring that a message be dropped when a message arrives for a full queue. A dropped message may lead to a request for retransmission of the lost message. Worse, it may trigger a "refresh," requiring retransmission of all state held by the receiver. These are the mechanisms that can lead to unstable operation or crashing as a consequence of spikes.
If you measure application message latency as suggested above in Section 2 and plot that with data rates, you'll be able to see if there's a correlation. Increasing latency with increasing rates is a sure sign of latency as a consequence of queuing. Quantifying the amount of latency due to queuing may help in justifying technology investments toward a goal of reducing latency.
Our LBM and UME products have extensive features for measuring and monitoring latency.
| Prev | Home | Next |
| Focus More on Measuring Application Message Latency and Less on Measuring Data Rates | Establish a Latency Boundary for Each Receiver |
Copyright 2004 - 2007 29West, Inc.