Innovations in Trading and Technology (In my last blog entry I discussed the prevalence of 'microbursts' in market data feeds – short, occasional bursts of activity in the feed during which data rates reach levels much higher than average. We saw that during busy periods the LatencyStats.com feeds can send many high-rate microbursts in succession, each burst lasting much less than one second. If the data rate during a microburst exceeds the capacity of a network link or a feed handler, the excess data will be forced to queue. This adds latency to the feed messages, and in the worst case messages may be discarded if a system runs out of buffer space to hold waiting data.
How should network and computing systems be engineered to handle microbursts? A simple but rather conservative approach is to ensure that the available capacity always exceeds the highest microburst data rate measured at some short timescale. For example, if the speed of a network link carrying a market data feed exceeds the feed’s highest 1-millisecond data rate, then the link will never be continuously busy for more than 1 millisecond at a time. Therefore no data will be delayed on the link for more than 1 millisecond.
In practice the capacity needed to keep latency below 1 millisecond is normally much less than the peak 1-millisecond data rate. This is because the microbursts in the feed tend not to be sustained over time. A 1-millisecond microburst exceeding link capacity will build up a queue of data waiting to be processed. But provided the system can buffer the queue and clear it quickly when the burst ends, it can still prevent any data from being delayed more than a millisecond. For example, on LatencyStats.com we display both the peak 1-millisecond rate and the network bandwidth required to avoid 1-millisecond latency for each feed – the latter value is computed using an algorithm based on queuing theory. At the time of writing (28 September 2010) the values displayed for ArcaBook for the last seven days are:
Comments | Post a Comment
4 Comments to "Microbursting at the Seams":
kmcpartland
14 October 2010
Your model suggests using past data to estimate future data needs. Reasonable, but doesn't that ignore extreme market conditions? We've had a lot of those in the past 3 years. My question then becomes how do the most latency sensitive firms calculate their needed bandwidth? Do they use a method similar to the one you discuss here and then double or triple it?
Comments (80)
lberke
18 October 2010
It would be interesting to take a look at the relationship between intraday price volatility and microbursts. Other than the obvious expectation that they would be highly correlated, I wonder if there's some short-term predictive value there in the volatility metrics.
Comments (129)
fergal
21 October 2010
Thanks for your comments. I agree that allowance must be made for trends and extreme events when deciding what resources you will need in the future. Having accurate information about events in the past is a starting point for this analysis. If you can determine how much headroom you currently have and how it is trending, that can give you an picture of when you will likely need to upgrade. The question of how much headroom you are comfortable with is very subjective - I haven't seen a one-size-fits-all approach. Looking at price volatility versus microbursts (and indeed versus latency) would indeed be an interesting study. Understanding the structure of short-timescale changes in the market is important not just for infrastructure decisions, but for trading as well.
Comments (1)
russt
22 October 2010
The only reasonable thing to do is to publish both the quote and the latency, and let the recipients decide what to do with the data. It's not viable to keep increasing the connection speeds arbitrarily, since traders will take advantage of the increased bandwidth and raise the bar yet again. And there's no harm in distributing delayed data so long as everyone knows that it is delayed. The real sin is distributing delayed data and pretending that it is current (ahem, NYSE!).
Comments (2)