Millennium bugs hit stock exchange

The London Stock Exchange suffered a second day of problems yesterday as its new trading platform struggled to function again. On Tuesday the market failed to close correctly, causing confusion over closing prices for brokers and traders. Yesterday the MillenniumIT system displayed zeroes against some bid and ask prices, …

[Anonymous Coward]

"legacy" = "stuff that works"

And therefore isn't written about very much, it just sits and hums quietly and invisibly.

[Ocular Sinister]

Hmm...

Looks like the data from a third party is not in the expected format. Far from ideal, but not a sign that the world is about to collapse. You have to wonder what integration testing they did though.

[88mm a.k.a. Minister for Misbehaviour]

Linux is balls

I understand the ball that goes up at the start of trading is controlled by Ubuntu. I guess that's a form of real-time system if it has knack all else to do but at least once it failed due to a full log partition/poor build. Funny how often that happens. Frankly for my money any financial trading system should be on Solaris with ZFS but what do I know, I never worked at any exchange and was too stupid to bother learning mainframe when I had the chance.

- Paris... because she knows where the money is.

[Radelix]

man made systems

Last I checked human-made systems go titsup every now and again. Naturally we don't want them to but it happens.

[John Smith 19]

*lots* of terminology.

Let's try unscrambling some of it

*Millennium bug". Failure cased by incorrect processing of change from 1999 to 2000. The article shows *no* evidence for this class of bugs being the cause of the problem.

Business critical. System fails company goes down pan. That *would* have described any major *offline* accounts app EG LEO (Lyons electronic Office). More recently would be the code that did calculations for a medical radiation source to decide, given various factors how much to dose them with. Not real time at all (except in the loosest sense) but *absolutely* critical to delivering the machines function. The code had bugs and several patients got 10x the dose they should have had.

Latency tolerant soft real time. Describes lots of stuff on *any* GUI. You clicked on "My Documents" and it showed you the folder. It opened fast *enough* that you're not bothered. If it takes a *bit* more (or less) time to act you're *still* not bothered. The cursor followed you mouse *well* enough to keep you feeling in control.

Latency intolerant soft real time. Here the *consistency* of the response is the important thing but I can't think of a situation where this applies.

After this things get *tough*. Typically the computer system is connected to "stuff" and if the computer can't work out the *right* response in a *guaranteed* amount of time *every* time *very* bad things happen. The "stuff" might be another computer on the network (Skype's latency and *consistency* of that latency are both pretty important for it to work well). If the system is an airliner, jet engine or Uranium enrichment centrifuge things can go badly wrong very quickly.

*nix's were never designed to support *hard* real time constraints but various upgrades to standard functions and the *long* background in building architectures that run such tasks have built up a *lot* of expertise in what to do and how to do it.

Armadillo Aerospace runs such a box to to fly the lunar lander which won the NASA challenge prize.

Some of the usual features for the work include a high resolution clock for the scheduler, software modules locked in main memory (no writing to disk) and either locking module scheduling priorities *permanently* or only allowing them to be changed under *very* carefully controlled criteria.

The developer and admin mindset is important here. While it looks to the apps and the dev tools like a normal *nix box it is not *run* like one.

Of course while the knowledge is out there and developers *with* the knowledge are out there as well it's not clear if *these* developers have it.

BTW Be *very* careful of the phrase "real time." Real time relative to *what*? A human can't control an unstable aircraft without computer assistance (watch the control surfaces of an F16 if you ever see one but *can* respond fast enough to simulate an ABS (c5 brake presses a second IIRC). OTOH a chemical plant with a time constant of 1 hour can be controlled by a human with a chemistry set, some graph paper and a calculator in "real time."

That's my pedantry done.

[Anonymous Coward]

these guys should get you to write a column

"Latency intolerant soft real time. Here the *consistency* of the response is the important thing but I can't think of a situation where this applies."

Flight simulator or similar? It's not necessarily a disaster if you miss a deadline slightly occasionally, it is useless if things are sufficiently unpredictable as to make them unrepresentative.

"*nix's were never designed to support *hard* real time constraints"

In general true, but (if you'll pardon the expression) there were exceptions of various kinds. DEC OSF/1 was one I was familiar with, though again it rather depends on what is meant by "hard". You wouldn't fly an aircraft, you might run an air traffic management system (and indeed Eurocontrol did).

[Anonymous Coward]

crippled rubbish

I gave suse version anything a wide berth long ago, just after the time they sold out to those Novel scum. SDE was the most miserable pile of crud I ever had the misfortune to install on my machine, possibly even including Corel linux. Trying to run a business with SUSE you need to have your head slapped and to have your servers go titsup. Well, look what just happened! And this is me, the biggest linux fanboi since 1991. Serve them glad.

How do I make this FAIL icon bigger?

[Wile E. Veteran]

'nix in Real Time

Don't use it. Period. Instead, use something like QNX Neutrino or RTEMS which layers a POSIX API over a hard real-time core to allow normal 'nix functions to run when desired (such as during development) but also provides the hard real-time API's necessary for time-critical tasks.

Use Ada, too, so somebody can maintain the bloody code 10 years after you've departed the project.

Mine's the one with the QNX demo floppy in the pocket.

[Nameless Faceless Computer User]

Y3K?

Y3K?