Why Latency Changes?
Why Latency Changes?
By Donal Byrne, CEO of Corvil
One of the most frequent questions I have received since we launched latencystats.com is “why is the latency changing all the time?” When people click on the 1 minute, 1 hour, 1 day and 7 day view they will often observe significant differences in the peak latency and 99.9% latency reported. So, why does it change?
Latency is not a constant. It is a lot like the weather, always changing. If you don't like a particular latency number, then wait a second. It will change. Latency is not simply dependent on geographical distance alone. It is also dependent on factors like traffic load, network bandwidth, and processing capacity. If any of these factors change, then latency will change. The load on electronic trading systems is highly variable. We know that intraday patterns often show higher volumes at market open and close. We also see large variations in load at micro timescales. These are known as microbursts. Active components that process trading messages like trading engines, line handlers, gateways, firewalls, switches and routers can often be temporarily congested by these sudden microbursts which adds even further to the latency. Therefore a single number quoted for the latency of such a dynamic system is inadequate to describe its performance.
In choosing the parameters for latencystats.com, we asked ourselves the question; “what is the minimum subset of information that must be presented to provide good insight into the performance of the underlying system?” Our starting point was to make sure the information covered the following three essential elements:
1. LATENCY – at a minimum we need the average latency, peak latency and some high percentile (e.g. 99% or 99.9%) of latency so that we can determine the performance at high levels of confidence but not necessarily worst case, i.e. peak. In our experience, most people do not design for the worst case as it is cost prohibitive. The ideal information would be the full distribution of the latency during the measurement period. This allows determination of any percentile of interest.
2. LOAD – it is very important to understand the load conditions corresponding to the latency measurements presented. Again, we present the average rate and the peak rate for 1 second and 1 millisecond. The difference between the average rate, the 1 second peak rate and the 1 millisecond peak rate provides a good indicator for how bursty and sporadic the underlying traffic is. The ideal information would be full distribution of traffic rates during a user selected measurement interval. In future releases of the web site we hope to provide full time series of the underlying parameters.
3. MEASUREMENT INTERVAL – in our experience this is the least well-understood and most important piece of information that should accompany any quoted latency numbers. Unfortunately this information is often missing. It is critical to understand if the average, peak and 99.x% latency measurements were made over the trading week, or the trading day or during the opening / closing hour or minute. Having the full range of latency measurements for these different time periods are all equally valuable. For this reason we decided to present both latency and load information continuously over various measurement timescales (1 min, 1 hour, 1 day and 7 days) and to show the variation.
The phenomenon of latency variability as a function of measurement interval is very important to consider when reviewing published performance of underlying high speed execution and market data services. If the measurement interval is not known then it is very difficult to compare apples to apples. For example, let’s say you were comparing the latency performance of two execution venues based on the following published latency numbers:
Execution Venue 1 (measured during the trading day from market open to close):
Average Latency = 92 µs
Peak Latency = 1232 µs
99.9% Latency = 278 µs
Execution Venue 2 (measured during the busy 1 second of the trading day):
Average Latency = 432 µs
Peak Latency = 785 µs
99.9% Latency = 627 µs
Because of the very different measurement intervals it is challenging to assess which execution venue is actually the fastest. If I were forced to take a bet, I would probably go for execution venue #2. This might be surprising to you but we know from experience that the latency of venues change dramatically during their busy 1 second period. With execution venue #1, the warning signal is a higher peak latency during the trading day compared to execution venue #2. On the other hand, a clever (or not so clever) marketing person with execution venue #1 may choose to claim that 99.9% of the time they are at least twice as fast as execution venue #2. This of course would be a misleading and inaccurate claim.
Unfortunately, this is exactly what has been happening in our industry and explains in part why it is difficult to compare latency performance numbers. Efforts are underway to standardize the reporting of latency performance. However, most focus has been on the question of the appropriate latency statistics to publish e.g. min, max and percentile. Hopefully this has helped to illustrate why it is equally important to specify the measurement interval.