London Stock Exchange smashes world record trade speed with Linux

I believe so, yes.

In fairness, though, it may not have been MS' fault - crappy programming is crappy, no matter the underlying OS. And Linux fanboys should wait to see if the new system has roll-out issues...

Yes. The Linux version is developed at http://www.milleniumit.com/media_room/gui-press_releases.php

RTFA it says all that in the second paragraph.

True but this is like the "World Series" for stock trading latency. Who really plays baseball other than the US and small group of other countries like Cuba ;-)

My first thought after reading the title was: "Oh great, now they can trade faster than they can think". And then…

That makes as much sense as blaming US developers for Accenture failing at the LSE and claiming that Asian programmers are the best because they made the LSE work.

Accenture developed .NET software for the LSE and a company in Sri Lanka made the new LSE software for Linux

Have you experience with Windows Server in a properly set up production environment? I know of at least one high-performance shop that has used Windows servers (we are not talking onesies or twosies here--more than hundreds) and has higher performance requirements than exchanges.

The latencies are typically quoted as round trip through the matching engine. This does not include transit latency to the matching engine but will include any internal transit latency once the matching engine has the order. So you can assume it is from when the order message reaches the network interface on the order processor to when the response leaves the network interface towards the market participant.

The amount of work the matching engine has to do is non-trivial but straightforward. Take order, look at type, if market order look for a match on the limit order book, if not handle appropriately (this bit is not included in the latency as it might involve routing to other venues, etc). If it is a limit order it must find the right place to position that order within the order book. Building an order book data structure that is cache friendly and thus very fast is not rocket science but it certainly isn't easy.

I'm a software developer at an exchange in the US. The LSE has not released details of how it is measuring "latency", but FWIW, we measure latency as the time it takes to submit an order and receive an order acknowledgment or fill, with both the sending and receiving outside our firewall. The two biggest SW components involved are the FIX handler (the component used to process orders; FIX is an industry standard protocol) and the matching engine (the component used to match buy and sell orders). I could of course spend hours talking about our hardware and software customizations, but it's a very competitive industry. Our software is C++ running on Linux, and that's about as much detail as I'm willing to go into.

I believe it was the OS from memory. This was around the time Accenture lead development wasn't working out a few years ago.

That is certainly hard to say. It was, as I understand it, built by avanade, the joint venture between Microsoft and Accenture.

The speed of a system as complex as an exchange is influenced by many factors--network infrastructure, language of choice, software architecture, OS tuning.

In fact, garbage collected languages are known to perform well in serious low-latency systems.

Some firms have been known to rewrite the network stack for performance.

So presuming that it is an OS issue, or a language issue, or a vendor issue alone is not likely to arrive at a useful answer.

Also complete control over your own future without being beholden to a 3rd party.

And, due the the lower latency, they become a more attractive source of liquidity generating more incoming orders and more revenue.

I think systems like this use a lot of RAM. You can afford it when you're a stock exchange. You can get high availability from a RAM store if you replicate it over multiple machines and react quickly to machine failures. Then you keep a commit log on disk that's append only and avoids seeking.

If there is a database, it would be far down the chain. Imagine machines with 72g of memory whose only function is a buffer.

(I would love to get my hands on one of those suckers and outfit it with Redis.)

No, the core of a stock exchange resides entirely in RAM. Everything is reset once a day (overnight for stocks, immediately after regular hours for futures), and brokerages are responsible for resubmitting long-lived "good 'til cancelled" orders each day before the session begins.

Despite being RAM bound it's easy to parallelize because each stock is its own isolated exchange, so they can be distributed across hardware in proportion to the average volume in each stock. In other words, it's localized but embarrassingly parallel.

The only traditional databases are for reporting purposes e.g. who traded with whom and are append-only as far as the core exchange code is concerned. The reporting database is coupled through the same firehose feed that you can get as an exchange member, albeit with more redundancy. There are also access control systems that only come into play when you first open a session, and lots of other moving parts each with their own task. For example, if you lose your connection to the exchange you can ask a certain (non-core) server to replay all the events that happened from a given point in time in order to catch up. These, too, would be listening to the main event stream and spooling to disk, but the central exchange processes are RAM-only.

How do they handle machine failures? That's harder to speculate on from the outside, but if I were them I'd be running the same exchange in parallel on 2-3 machines. I don't know how it could be done without serializing the incoming order flow to make sure that each machine sees the same order of events, but it's not impossible.

If damping is profitable, someone will do it.

Of note is that it cost less to acquire MilleniumIT then it did to run their Accenture provided solution for 1 year.