Stai usando un browser molto obsoleto. Puoi incorrere in problemi di visualizzazione di questo e altri siti oltre che in problemi di sicurezza. . Dovresti aggiornarlo oppure usarne uno alternativo, moderno e sicuro.
Linux OSLa borsa di Londra e' passata da Microzozz a Linux
NEWS A Linux-based trading platform at the London Stock Exchange was knocked offline for two hours on Tuesday due to human error, in what may have been suspicious circumstances, the stock exchange said on Tuesday.
The trading platform — named Turquoise — has been running on a new Linux-based system for the past two weeks. It was rendered inaccessible to market members for two hours on Tuesday, between 8:23am and 10:30am, the London Stock Exchange Group (LSEG) said in a statement.
Turquoise is a pan-European trading platform based in London. It has a 'dark pool' trading component that allows members to "place large orders for trades which are not made known to the market until after the trade has been executed", a spokesman for the London Stock Exchange told ZDNet UK on Wednesday.
"The problem occurred on the network, so members could not access the [Turquoise] technology," the spokesman said, though he stressed that "the [Turquoise] technology itself is fine and continued to function correctly".
In its statement, the LSEG said that "preliminary investigations indicate that this human error may have occurred in suspicious circumstances".
At the time of writing, the LSEG could not deny that the downtime had occurred because of a hack on its IT systems. "I think it's too early to be specific about what the cause was... whether it actually is suspicious or not, we are investigating that at the moment," the spokesman told ZDNet UK.
"If the investigating authorities do find that the Turquoise trading platform was hit by sabotage, that would raise some very serious and fundamental questions about the state of internet security at the London Stock Exchange," said Mark Darvill, vice president at security firm AEP Networks, on Wednesday.
Due in part to the Turquoise crash, the LSEG has postponed the migration of the main London Stock Exchange equities market to the Linux-based system used by Turquoise until 2011. The main market migration will be rescheduled for "a date as early and practicably as possible in 2011", the group said in its statement.
Turquoise runs on a system called Millennium Exchange, which is built by MillenniumIT, the spokesman said. Millennium Exchange is a scalable trading system that can process over 500,000 orders per second for multi-CPU, multi-server systems that use Infiniband high-speed interconnects, according to the system's website.
The service was down for all customers, whether or not they had IT hardware in the LSEG low-latency market-linked datacentre.
Funziona cosi' bene che ormai e' da febbraio che uso esclusivamente Ubuntu, e sono cosi' soddisfatto che pagherei per Linux
Invece devo pagare la tangente a Microsoft quando compro un notebook, per il Windows preinstallato, anche se non lo usero' perche ci installo Linux Vergogna
Altro articolo interessante:
Linux at NASDAQ OMX
By Jonathan Corbet
October 21, 2010
One tends to think of "the NASDAQ" as a single exchange based in the US, but, in fact, NASDAQ OMX operates exchanges all over the world - and they run on Linux. In the US for instance, that includes markets like the NASDAQ Stock Market, The NASDAQ Options Market, and NASDAQ OMX PSX, its newest market that launched on October 8. At a brief presentation at the Linux Foundation's invitation-only End User Summit in Jersey City, NASDAQ OMX vice president Bob Evans talked about the ups and downs of using Linux in a seriously mission-critical environment.
NASDAQ OMX's exchanges run on thousands of Linux-based servers. These servers handle realtime transaction processing, monitoring, and development as well. The big challenge in this environment, of course, is performance; real money depends on whether the exchange can keep up with the order stream. Latency matters as much as throughput, though; orders must be responded to (and executed) within bounded period of time. Needless to say, reliability is also crucially important; down time is not well received, to say the least.
To meet these requirements, NASDAQ OMX runs large clusters of thousands of machines. These clusters can process hundreds of millions of orders per day - up to one million orders per second - with 250µs latency.
According to Bob, Linux has incorporated some useful technologies in recent years. The NAPI interrupt mitigation technique for network drivers has, on its own, freed up about 1/3 of the available CPU time for other work. The epoll system call cuts out much of the per-call overhead, taking 33µs off of the latency in one benchmark. Handling clock_gettime() in user space via the VDSO page cuts almost another 60ns. Bob was also quite pleased with how the Linux page cache works; it is effective enough, he says, to eliminate the need to use asynchronous I/O, simplifying the code considerably.
On the other hand, there are some things which have not worked out as well for them. These include I/O signals; they are complex to program with and, if things get busy, the signal queue can overflow. The user-space libaio asynchronous I/O (AIO) implementation is thread-based; it scales poorly, he says, and does not integrate well with epoll. Kernel-based asynchronous I/O, instead, lacks proper socket support. He also mentioned the recvmsg() system call, which requires a call into the kernel for every incoming packet.
There is some new stuff coming along which shows some promise. The new recvmmsg() system call can receive multiple packets with a single call. For now, though, it is just a wrapper around the internal recvmsg() implementation and does not hold the socket lock across the entire operation. But, he said, recvmmsg() is a good example of how the ability to add new APIs to Linux is a good thing. He also likes the combination of kernel-based AIO and the eventfd() system call; that makes it possible to integrate file-based AIO into an applications normal event-processing loop. There is also some potential in syslets, which he sees as a way of delivering cheap notifications to user space; it's not clear whether syslets will scale usefully, though.
What NASDAQ OMX would really like to see in Linux now is good socket-based AIO. That would make it possible to replace epoll/recvmsg/sendmsg sequences with fewer system calls. Even better would be if the kernel could provide notifications for multiple events at a time. Best would be if the interface to this functionality were completely based on sockets. He described a vision of an "epoll-like kernel object" which would handle in-kernel network traffic processing. The application could post asynchronous send and receive requests to the queue, and receive notifications when they have been executed. He would like to see multiple sockets attached to a single object, and a file descriptor suitable for passing to poll() for notifications. With a setup like that, it should be possible to push more network traffic through the kernel with lower latencies.
In summary, NASDAQ OMX seems to be happy with its use of Linux. They also seem to like to go with current software - the exchange is currently rolling out 2.6.35.3 kernels. "Emerging APIs" are helping operations like NASDAQ OMX realize real-world performance gains in areas that matter. Linux, Bob says, is one of the few systems that are willing to introduce new APIs just for performance reasons. That is an interesting point of view to contrast with Linus Torvalds's often-stated claim that nobody uses Linux-specific APIs; it seems that there are users, they just tend to be relatively well hidden.
An IT contractor has reportedly been suspended by the London Stock Exchange following a huge network hit between Monday night and Tuesday morning.
The network was floored, knocking a key Linux trading platform out of action and bringing a halt to the largest technology transformation at the exchange in 25 years.
The police and the Financial Services Authority are aware the incident. The City AM newspaper said it had been informed of the suspension of the LSE IT worker, but the exchange today declined to comment on staff matters.
The stock exchange’s Turquoise dark pool, or anonymous trading venue, was taken offline for two hours on Tuesday morning, and later that day the LSE said it was delaying a key migration to open source systems until next year.
The LSE is conducting its own internal investigation, but has refused to state whether the outage was an accident, or whether it suspects a disgruntled employee. The FSA declined to comment.
One large shareholder in the exchange told the Financial Times that he suspected sabotage by an employee, because the LSE had cut staff numbers by more than 10 percent. “There are still probably a few disgruntled individuals who are in the departure lounge at the moment,” he said.
An unnamed city source told City AM that when the problem happened “there was an announcement about the platform change planned later the same day". The source speculated: “It looks like someone may have been trying to undermine this.”
While the LSE declined to comment, in a statement rushed out to the markets on Tuesday night it referred to both an "error" and "suspicious circumstances".
Some onlookers suspected the problem was an accident resulting from poor management of a contractor. A senior trader that had spoken to the LSE told the Financial Times : “It seems someone, a contractor, had access to the data centre and did something they shouldn’t have done.”
But last month, the LSE made the important step of allowing more IT personnel into its datacentre, expanding co-location beyond trading firms and to software firms – to install hosted systems and their own market data distribution platforms. It is not known if any of this raft of new companies entering the datacentre played a part in the outage. The exchange is grappling with a major technology change and is also changing its IT skills base.
It is moving away from its existing TradElect platform, based on Microsoft .Net, and requires C++ and Linux skills instead. It is also thought to be moving increasingly towards blade servers and away from traditional stacks and Unix mainframes, changing expertise again.
Although the system is live on Turquoise, the cash markets migration that would have happened this month is considered a far bigger move. LSE chief executive Xavier Rolet has staked much of his leadership success on making the platform the fastest in the world, following a series of embarrassing outages on TradElect that took place before his tenure.
Until the Linux switchover is made, TradElect will continue to run. The system delivers trading speeds of just under two milliseconds (2,000 microseconds), around sixteen times the latency of the new Linux platform. It is also around five times slower than the LSE’s largest rival in Britain, Chi-X, and at least eight times slower than NASDAQ in New York.
The LSE has vowed to make the system run as soon as it is ready. It is understood to be increasing server and networking hardware capacity rapidly in order to cope with the high volumes of trading expected. While this means delays, market participants told Computerworld UK they welcomed the fact the LSE was not launching the platform before it was confident the datacentres were ready.
The new system will handle 50,000 messages per second, though market observers said traders increasingly expect up to 300,000 to be manageable. Some newer technology in development can reportedly manage a million messages per second, though this measurement is in testing, and live environments are more challenging.
In spite of the outages, in a monthly report the LSE today said it “sits at the heart of the world's financial community, offering international business unrivalled access to Europe's capital markets”.
The London Stock Exchange has formally acknowledged it needs to do more to scale its IT infrastructure before launching a new Linux platform on its cash markets.
Additionally, sources close to the exchange said significant network and server enhancements are taking place within the exchange, alongside major improvements to client connectivity.
The LSE this week delayed its migration to the Millennium Exchange platform following a massive network hit that took the smaller Turquoise venue, which uses the system, offline for two hours during peak trading. The exchange declined to comment on reports that a contractor was suspended over a “suspicious” network incident.
Millennium Exchange can process a capacity of 50,000 messages per second in a live usage. While this is a significant volume, market participants told Computerworld UK that 300,000 was a better target given the capacity of rival systems.
One source, from a trading technology firm, said: “There are even systems out there that can process a million messages a second.” However, that technology was measured in laboratory tests and not live usage, which creates many more challenges on capacity.
The stock exchange, in a statement to the markets, said customer tests of the Linux system – developed in a C++ environment – had gone well in recent weeks. They had proved that trading messages worked fast and the failover datacentre worked successfully.
But it added that customers “have advised that more time is required to ensure the existing market infrastructure can process the high volume of traffic clients expect due to the increased performance of Millennium Exchange”.
The decision to delay such a significant migration, until the technology is ready, is likely to be viewed as sensible from the perspective of resilience and stability. However other exchanges are fast developing systems that can rival the LSE’s speed and capacity. Last week, NASDAQ in New York said it had a scalable Linux system delivering trades at under 100 microseconds, 25 microseconds faster than the LSE.
The London Stock Exchange will not migrate to Linux until 2011, after more development and customer tests are conducted. It said it “remains committed to ensuring that the migration to the new platform is completed with the minimum of risk”.
Vergogna 