At a client-site I was privy to an impressive IBM presentation on their
Websphere MQ Low Latency Messaging platform (LLM), with some pretty exorbitant claims: 8-million messages per second on gig-ethernet, and 21-million per second on infiniband(!).
I’ll be interested to see if it stands up to scrutiny.
Following on from my previous post on Not-So-Hidden Latency, another topic Tom Groenfeldt and I had started discussing earlier this week was something we at the lab have been thinking about for some time: trader latency or comprehension latency. I’ll explain below.
As the search for low latency has continued, it has focused on two things: (a) reducing the latency in receiving and processing market data and (b) reducing the latency in executing a transaction. Now, insofar as algorithmic trading is concerned, the search has also focused on reducing the time it takes for algorithms to make execution decisions based upon that incoming market data, i.e., the time it takes them to get from (a) to (b).
But what about the scenario where the task of making that execution decision lies not with an automated system, but rather with a human trader? At that point, you have to start considering the latency from when the data first reaches the trader’s eyes to when the trader finally enters the keystrokes to execute a trade. That is what we call ‘trader latency’ or ‘comprehension latency’, i.e., the time between when a trader sees information and then is able act on that information.
The challenge is to reduce that time period while, at the same time, allowing traders to deal with ever greater volumes of data updating at ever greater frequencies. This not-so-hidden latency has, to date, been sorely overlooked. The solution is to come up with innovative ways to display that information to users. That thesis is the very basis behind our Advanced Data Visualization practice (see the paragraph titled “Monitor More Volume with Richer Context” on our Services page). The market liquidity visualizations, the fixed income pricing visualizations, and all of the winners from our WPF in Finance challenge are excellent examples of means to that end.
In all the years that the industry has been developing trading systems, user experience has rarely been a significant concern. Thankfully, the industry is finally realizing that reducing latency won’t help if the only result is that the cells on a trader’s workstation blink faster. You actually have to come up with innovative ways to allow traders to quickly and intuitively deal with that data.
From where we stand now, we certainly see that changing as more and more banks bring on companies like Lab49 to help them focus on things like user experience. To the extent that that is happening, we’re obviously all for it.
I had a meeting this morning with Al Moore, one of the founders of Fixnetix, a provider of ultra low latency market data and connectivity. It immediately brought to mind a conversation I had with Tom Groenfeldt earlier this week about hidden latency. It continues to baffle me when financial institutions will spend millions shaving microseconds off of their data handling processes by optimizing their code and implementing CEP solutions, and then, after all is said and done, they’ll take this newly optimized codebase and hook it up to something like Reuters to receive their data, which itself has a latency that is milliseconds more than a low-latency data provider. Why not pocket that money, save those man hours and just switch data providers? Or better yet, do both?
It’s a classic case of not seeing the forest for the trees. Optimizing a system requires looking at the entire system - not just diving into a piece of it. You might very well shave more latency off of your architecture by changing data providers or removing that one extra switch from your network architecture than spending man-years optimizing your event processing software. Financial institutions need to remember to focus on the not-so-hidden latency before diving into a search for hidden latency.
