Pete’s Blog: So What Does Low Latency Mean To You?
You’d have thought that several months after we started this website that we’d know what we’re about. I guess we kinda thought the world out there had already decided what is low latency, and what is not. But I guess life isn’t that straightforward.
Low latency is now a much used term. A much abused term. Just about every realtime vendor is attaching the low latency tag to their offering in some vague attempt to be a part of a club where money is still being spent, post sub prime meltdown. It’s like the old days when vendors needed a mobile message, a Java message, an XML message. It’s all hype. As is the term “realtime reference data” which has been cropping up of late. Give me a break.
What is low to one person is slow to another. Is a consolidated datafeed that’s had its latency stripped back to just tens of milliseconds, and which drives algo trading apps, a low latency feed? It is as far as the data vendor and the trading firm are concerned. And coverage of it has made it onto this site, for better or for worse.
For myself? I’m not so sure. I think I live in a world where greater than a millisecond is amateur night. Or maybe I’m thinking ultra-low latency - another term that’s making its way into common use.
So for this month’s poll (it’s over in the right margin) we’re asking all of you what you think low latency means. It just takes a moment - however long that is - to take part, and we’re keen to hear what you’re thinking.
Until next time … here’s some great music!
Technorati Tags: low latency, ultra low latency, realtime reference data, bollocks
November 19th, 2007 at 11:49 pm
Low latency is turning a order around in under 50 microseconds
(inbound packet to outbound packet as seen from a wireline
sniffer). 1 millisecond is definitely amateur night
November 21st, 2007 at 12:46 pm
Hi Josh
How many, which, liquidity venues do you know of that can do that?
Most venues that I have seen figures from are quoting 10-20
milliseconds for the entire roundtrip.
Pete
November 27th, 2007 at 10:44 pm
[…] [6] http://www.low-latency.com/2007/10/31/intel-bringer-fasterfs-event-to-nyc/ [7] http://www.low-latency.com/2007/11/19/petes-blog-so-what-does-low-latency-mean-to-you/#more-279 […]
November 28th, 2007 at 9:19 am
Well from what I overheard in a bar last night - sounded like a salesman talking about a request from a client…
“they were adament, adament, that they needed a low latency feed so that
they could generate PDF’s to email to their clients”
to which I suspect the saleman thought “bless” with a smile when originally asked
December 1st, 2007 at 6:09 pm
> Low latency is turning a order around in under 50 microseconds
Good luck with that…
> ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.012
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.008
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.007
…
Those times are in milleseconds from a high end
linux server (connected to a top-of-the-range CISCO 6509,
not that its being used here).
With regular ethernet it takes at least ~65 microseconds to
reflect a packet or tcp segment. Usually you’ll see about
double that with gigE and two network trips. If you can break
120usecs for that you’re among the best there is.
Of course thats based on commodity software+hardware, but its a
leap (and would be quite wrong) to say that all the non-amateurs
must be using custom hardware, Infiniband or squirrelly real-time
kernels.
Persistence is the key issue that results in poor order routing
latency and (somewhat meaningless) statistics like ack times.
Disks only write so fast even with SSD/RAID and custom
checkpointing algos - in the end you’ll only get the fastest
times if you avoid persistence and accept the risk of data loss
during failures.
December 1st, 2007 at 8:20 pm
Typical good gigE latency:
> ping 10.10.1.3
PING 10.10.1.3 (10.10.1.3) 56(84) bytes of data
64 bytes from 10.10.1.3: icmp_seq=1 ttl=64 time=0.127
64 bytes from 10.10.1.3: icmp_seq=2 ttl=64 time=0.159
64 bytes from 10.10.1.3: icmp_seq=3 ttl=64 time=0.121
64 bytes from 10.10.1.3: icmp_seq=4 ttl=64 time=0.171
…
So, minimum real (application->server->application) turn
around time for gigE is ~125usecs + processing time.
Most execution systems will have at least:
app–(wan)–>FixFarm–>MatchingEngine–>FixFarm–(wan)–>app
WAN link using ATM will have an average of 62.5usecs plus
transmission times plus routing/switching latency because
ATM operates at 8000 frames/sec (1 every 125usecs).
so, minimum turn around latency for an order processing
venue using ATM wan links and gigE internally would be:
app–(wan)–>FixFarm: 63usecs + transmission/switching
FixFarm–>MatchingEngine: 63usecs gigE latency
MatchingEngine–>FixFarm: processing time + 63usecs gigE latency
FixFarm–(wan)–>app: 63usecs + transmission/switching
So, lets assume 20usecs for processing(though I cant imagine
why it would take that long), 100usecs for switching, and
50 usecs for transmission (building next door).
venue latency: 63+100+50+63+20+50+100+63 = 509usecs (0.5msecs)
Given these are absolutely best case scenarios and the
transmission latency is unrealistic and there is no extranet
or firewall stupidity included, it should be no surprise that
the major venues usually take a handfull of milliseconds
just to ack.
December 7th, 2007 at 7:43 am
Hi All,
I read thru lot of posting on Low Latency and also had been various
websites talking about low latency, now I am really not sure what is
desired out of it?
Other thing is how low can you go? Now we are able to help few
financial companies in reducing their response time without overloading
CPU and saving power. This is all done thru hardware accelerators.
We have expertise in FPGA based design and so I think it can be
achieved, but again not below a certain limits.
We need to live with it.
Sameer
February 12th, 2008 at 9:59 pm
With the risk of being called an ignorant, i feel rather confused “low latency”.
Every product/talk i have seen/heared sofar talks about minusculus time spaces, but never, not once do they explain on which part of the process. What do I mean
1. two orders are matched in the venue matching engine
2. the matching engine generats a quote going into the market data engine
3. the data engine sends the quote to feed distributor.
4. depending on the data vendor or direct feed receivers location and network capability and traffic it reaches the institutions/traders system/environment.
5. once passed the through the internal data distribution system it ends up on either the traders screen or the black box.
6. trader or program make order decision
MIFID 6. traders looking for best execution venue
7. trader or program hit the order button
8. Off it goes to the exchange (through systems, networks, etc)
9. And…damn’ the order end’s up in the order que of the execution venue matching engine.
So to which part are of point 1 to 9 do we apply the Low Latency term?
Or would that be an entier univers of new products.
Please unconfuse me
Stephan