5 ms·
London Stock Exchange smashes world record trade speed with Linux
- whatajoke 16y agoIs this the same system that replaced the failed Microsoft platform? http://blogs.computerworld.com/london_stock_exchange_to_abandon_failed_windows_platform http://blogs.computerworld.com/london_stock_exchange_to_aban... Microsoft had run huge ads on how LSE was using .NET and Windows in critical financial applications. Within a year LSE had suffered crashes in the same critical areas.
- JoachimSchipper 16y agoI 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...
- nodata 16y agoIf I remember correctly, the LSE brought in Microsoft themselves to fix the problems. And Microsoft couldn't.
- dhyasama 16y agoSource?
- recoiledsnake 16y agoI doubt they could fix architectural issues that permeated from the very beginning after the fact.
- gaius 16y agoAgreed, Accenture code can make any OS slow.
- anarcticpuffin 16y agoI agree. At these speeds it has less to with OS and/or language and has more to do with smart programming decisions. PS - Singapore Stock Exchange quotes a faster latency than Nasdaq and LSE: http://www.a-teamgroup.com/article/voltaire-powering-fastest-stock-trading-engine-sgx-reach-for-the-singapore-exchange-sgx/ http://www.a-teamgroup.com/article/voltaire-powering-fastest...
- known 16y agoYes. The Linux version is developed at http://www.milleniumit.com/media_room/gui-press_releases.php http://www.milleniumit.com/media_room/gui-press_releases.php
- munchhausen 16y ago> Yes. The Linux version is developed at http://www.milleniumit.com/media_room/gui-press_releases.php http://www.milleniumit.com/media_room/gui-press_releases.php Can you elaborate on this? Are they developing a fork of the Linux kernel? A new Linux distro? Or could it be that they are developing the trading "platform", using a commodity Linux distro?
- konad 16y agoRTFA it says all that in the second paragraph.
- nervechannel 16y agoNormally I'd thoroughly welcome any news of large Linux-based systems replacing slower MS-based ones, but in this case... ... these days I can't help thinking "is faster really a good idea?"
- lrm242 16y agoWorld record? Not quite. Let's see full details on the numbers. NASDAQ publishes their latency numbers weekly, including average, 99th percentile, and 99.9th percentile: http://www.nasdaqtrader.com/trader.aspx?id=inet http://www.nasdaqtrader.com/trader.aspx?id=inet. Their average latency on order entry is 98 microseconds and their average latency on market data is 92 microseconds. Perhaps by "world record" they mean "european record".
- danielnicollet 16y agoTrue 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 ;-)
- deleted 16y ago[deleted]
- lrm242 16y agoGo read the website I linked to. NASDAQ publishes their methodology. I'll quote it for you here: OUCH Measurements of Order Latency * The time it takes to accept, process, and acknowledge or fill an order. * Measured as the complete round trip for an order or cancel transaction leaving a customer network port, through the co-lo network and application firewalls to the matching engine and back. * Measured in the production environment during a full trading day including opening and close. As you can see, they are including the time it takes to acknowledge and fill the order. It is the complete round trip time, and does include transit latency through the co-located network (which I thought was excluded).
- deleted 16y ago[deleted]
- Rimpinths 16y agoThey are clustered together because it takes roughly the same amount of time to determine that an order can be matched (filled) or that it can't be matched (acknowledged, on the book.) Either way, it has to be processed by the matching engine.
- nozepas 16y agoI'm sure they will notice much more benefits than just improved trading times. For example: improved infraestructure management, overall performance increase, fast patches for security bugs, and a long etcetera. Of course, as JoachimSchipper says, if the applications on top of the OS ar crap, a different OS won't solve the problem, but to have a good underlying OS is a good start.
- ilitirit 16y agoThis information is relatively useless to me. Was the old system slower because of the OS, .NET, or some other factor(s)?
- alphabeat 16y agoI believe it was the OS from memory. This was around the time Accenture lead development wasn't working out a few years ago.
- DrJokepu 16y agoI would be really surprised if it was the fault of the OS. I mean, Windows can be really fast, in the right hands, especially since they've introduced HTTP.SYS (parts of the HTTP server now run in kernel level). However, .NET being a garbage-collected, managed and JITted environemnt, it is maybe not the best tool for achieving these kind of response times reliably. Any serious and competent .NET developer would admit that. In general, I would blame the incompetence of Accenture for the failure: bad decisions, bad architecture, bad management, using the wrong tools, crappy code.
- _stephan 16y agoAre they actually using HTTP for anything?
- DrJokepu 16y agoI have absolutely no idea.
- rbanffy 16y ago> especially since they've introduced HTTP.SYS (parts of the HTTP server now run in kernel level). Isn't it something Red Hat did a long time ago that was widely regarded as a Very Bad Idea? And why would you use HTTP in this scenario anyway?
- 16y ago
- highlander 16y agoIt's fascinating that these latencies are an order of magnitude faster than most 'web services'. Can anyone provide more insight into what is specifically involved in executing a single trade? Are they just enqueueing a trade message in this latency or actually executing the trade? Are they including network latency in these numbers? Also, does anyone have any insights into the hardware and customizations?
- lrm242 16y agoThe 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.
- wglb 16y agoI agree, but with one exception. I think it is measured from the point of view of a co-located trading firm. So from the time that a trading engine that is a customer of the exchange fires an order to the time it receives either an order acknowledgement (this would result in a resting order) or a fill (completion of a by sell) at the co-located machine is how this would be measured.
- Rimpinths 16y agoI'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.
- siculars 16y agoIf I were a critical systems operator like say, a stock exchange, I would have to have my head examined by a team of head examiners for even considering Windows as an acceptable OS platform. Honestly, is the reason Microsoft can even get consideration for these projects because there are so many tech executives at major corporations who used to be Microsofties?
- recoiledsnake 16y agoThat 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
- wglb 16y agoHave 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.
- AdamTReineke 16y agoWhat industry has higher performance requirements than exchanges?
- endtime 16y agoThe only ones I can think of are space, military, and maybe medical robotics.
- ashish01 16y agoThis makes me wonder how, in mission critical and real time systems like LSE, they maintain a balance between being ACID and fast. Does any of these transactions ever touch the disk ? If not, how do they handle machine failures ?
- SpikeGronim 16y agoI 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.
- wglb 16y agoIf 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.)
- gxti 16y agoNo, 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.
- ergo98 16y agoThey replaced one software package (a custom solution by Accenture) with another (a company they bought, as an aside, for a solution that they now sell: Ergo, take their claims with a grain of salt). Drawing assumptions about underlying systems is speculative and somewhat ignorant.
- anthonys 16y agoOf note is that it cost less to acquire MilleniumIT then it did to run their Accenture provided solution for 1 year.
- deleted 16y ago[deleted]
- skbohra123 16y agoThey meant GNU/Linux of course.
- deleted 16y ago[deleted]
- motters 16y agoEncouraging ever faster trading times might be unwise, leading to instability and "hunting". There needs to be some damping in the system to guard against large uncontrolled fluctuations.
- eru 16y agoIf damping is profitable, someone will do it.
- parallax7d 16y agoThe profit motive should drive the use, not the implementation of a trading system that effects the world economy so directly. I've maintained that the standard increment for trades should be hours or days, not microseconds. This way liquidity is maintained on a macro scale, and parasitic orders based on micro manipulations of the system are eliminated.
- motters 16y agoWell it's a complicated system. Whilst individual traders might benefit from faster trading if you consider the health of the system as a whole, which favours steady predictable controlled growth, faster trading may introduce instabilities which result in reduced profitability.
- eru 16y agoFor a different perspective, there was a huge opportunity to make a killing with damping during the recent flash-crash.
- joeycfan 16y agoThis is nothing to be proud of. The American disaster with dirivitives can be traced to ultra fast automated trading.