Andrew’s Blog: It’s The Network, Stupid
As prime suspects in the worldwide conspiracy that is low latency, you’d think we might be protagonists too. But while whatever low latency is helps those who’ve achieved it to beat the competition that haven’t (yet), I’m still sceptical that any advantage derived from ‘low latency’ will be short-lived. How can it not be? After all, as vendor after vendor and firm after firm heralds the arrival of yet faster access to electronic trading systems or delivery of real-time market data, at some point the “Scottie” factor surely will kick in.
‘Ye cannae defy the laws o’ physics, Jim’ he used to tell Kirk and quite rightly so (although, this analogy is about to fall flat on its face given the fact that Kirk usually was able to – defy the laws of physics, that is). But anyway, as Scottie rightly points out, as technology costs drift lower – as they do – a greater and greater proportion of the marketplace will acquire the latency low enough to suit their needs vis-à-vis the competition. This inevitably nullifies any competitive advantage afforded by low-latency solutions, doesn’t it? And the ultimate restriction is the purely physical capability of delivering one data element or trade message from one point to another.
Until we reach that point, feed handler companies, in-memory database providers and direct feed suppliers will all vie to be fastest, according to a bewildering set of comparative metrics that inevitably are pitched to suit the sponsor (lies, damned lies and statistics, and all that).
But isn’t it true that the bulk of the latency in any given network-delivered service is due to the efficacy of the network itself. And while we, through our various publications, hear from software vendors daily on the low latency of their solutions, little attention is paid to the fact that the number (and location) of the network hops your message ultimately makes before it reaches you is a major determinant of the end-to-end latency of the system. Why is that?
May 2nd, 2007 at 6:08 pm
Actually, the latency contributor is not the network at all. The latency of concern here is the IO latency of the JVM not the network latency.
In fact, most of the latency in any network services is not really in the network at all. It is in the end nodes or the compute elements. This applies even to the most basic network services like FTP and Telnet.
May 7th, 2007 at 6:10 am
But what if there was a software solution that reduces the number of necessary network hops?
There is.
See this:
http://www.gigaspacesblog.com/2007/05/04/network-latency-vs-end-to-end-latency/
Geva Perry
GigaSpaces
http://www.gigaspaces.com
June 4th, 2007 at 9:24 pm
That’s an interesting proposition Andrew, that the competitive advantage is at best temporary — perhaps a 2-3 year period while competitors refresh their infrastructure.
Still, what happens to the competitors in the meantime, while they’re being traded against by Stat/Arbs with vastly higher performing trading systems? I wonder how much those 2-3 years could shift the balance of power…
January 17th, 2008 at 9:56 am
Where Latency is concerned you need to look at various factors
end-to-end since it is a combination of several components which
need to be tuned or optimized to achieve the low latency.
The network can be a contributing factor if incorrect hardware is
used but within most investment banks latency would typically be
about 10 microseconds within a single switch although the
reduction of network hops can reduce the overall latency. There
are several delays within the network and server hardware which
needs to be analyzed to provide optimal low latency forwarding:
1. Propogation Delay
2. Serialization Delay
3. Queuing Delay
4. Processing Delay
5. Forwarding Delay
The main contributer to latency are WAN links to exchanges and ECNs etc which
which are dependant upon distance from these locations. Even if
banks use proxity or co-location hosting only portion of there
infrastructure will be moved into these centers and there main
compliance and risk management systems will still be located
within the banks Datacenters.
When talking about latency we need to look at all the various
components within the chain and then optimize accordingly.