Hacker News new | past | comments | ask | show | jobs | submit login
London Stock Exchange in historic Linux go-live (computerworlduk.com)
79 points by DMPenfold2008 on Feb 14, 2011 | hide | past | favorite | 13 comments



This is a big win for Linux. The London stock exchange was one of Microsoft's big clients that it touted in marketing materials. The with the high profile problems (outage / slow), it quickly became a headache for Microsoft. If I remember correctly, Accenture blamed them and they blamed Accenture.

If their Linux system does well, with no major problems, it will be a nice high-profile case study for Linux.


It is sad that the underlying system gets blamed in these cases. While it is easiest to simplify and the blame gets passed around, there's no reason why you can't build a fault-tolerant system on-top of Windows. In fact, there's nothing particular about Linux that makes it immune from failure or bottlenecks (hardware, infrastructure, etc) that a high availability, high throughput system would need to overcome, nullifying any increases in stability or performance innate to the OS.

While I would professionally recommend Linux over Windows, it wouldn't be for reasons of "stability" or "performance" but that it was simpler and more straight-forward to sanely manage large farms of interdependent Linux boxes and that Linux provides a better development platform for these types of distributed applications.

I agree though, it would be a nice anecdotal win for Linux.


From what I read, Accenture built the system using SQL Server 2000... but this was a system that had been upgraded in 2007. Why didn't they use SQL Server 2005? I tried looking around also but couldn't find anymore technical details on what exactly caused the system to fail.

I should mention that despite being a .Net guy by trade I too would recommend a Linux system for something like this, especially for performance reasons where microseconds matter. Still I can't help but feel a little frustrated that no one ever said what exactly occurred beyond "one or two unforseen events happened that brought down the London exchange for several hours". In fact, one article even attributed the outage to human error! Aside from poor UI design or confusing procedures, sometimes it's a matter of PEBKAC.

(or maybe I just didn't get lucky in my searches)


From what I remember reading at the time, Accenture was the consultant that implemented the system, but that Redmond itself was heavily involved in the design / coding for the system.


If I remember correctly, Accenture blamed them and they blamed Accenture.

There's a good chance there's worthy blame on both sides.


Too bad their success case page needs Silverlight. I can't see it.

http://www.microsoft.com/business/success/Stories.aspx?Story...

Isn't it a bit odd that Microsoft makes no effort to show their victories to people who aren't already clients (and, thus, have Silverlight installed)?


The article says, "...Millennium Exchange was processing messages at a round trip latency of only 126 microseconds..."

Is this right, or did the author mean milliseconds?


microseconds.

internal messaging latency is measured in microseconds

order acknowledgement/cancel/fulfillment is measured in microseconds to low milliseconds.


Let me be the first to say that this is pretty damn fast.

For reference, try to ping a remote host in your LAN. You'll see about the same roundtrip time (~150 microseconds) and that's without a payload to speak of and without any processing going on.


Round-trip latencies for small MPI messages are typically a couple microseconds over InfiniBand, under 10 microseconds for 10G Ethernet without TCP, and a bit more when going through TCP.


my code to interface with this for a major financial exchange went live today too. So far its been working perfectly!


Same here.

Thanks LSE for providing us with one of the simplest protocols to code against!

For those wondering what kind of protocol I'm talking about: http://goo.gl/ld9aj (MIT203 and MIT303).





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: