Aandelenhandel in microseconden

[computable.nl]

De handel in aandelen en opties gebeurt niet meer op de beursvloer, maar in het zoemend hart van een rekencentrum. “Daarom is het zo belangrijk om onze servers in een geavanceerd datacenter te hebben staan. We praten hier over micro-, zelfs nanoseconden”, zegt Willem Meijer, CEO van TOM (The Order Machine)

Source: computable.nl

[Domenico]

Dit artikel gaat helemaal nergens over dus dat kun je skippen. Wat wel interessant is om te weten of/hoe de server/netwerk setup van bijvoorbeeld de Amsterdamse effectenbeurs en alle bedrijven die daar op zijn aangesloten verschillend is met een 'standaard' server/netwerk setup. Het gaat echt om milliseconden dus ben eigenlijk wel benieuwd hoe ze dat technisch allemaal voor elkaar krijgen.

Is hier meer (publieke) info over?

[jura]

Echt heel verschillend is het allemaal niet denk ik, maar de setup is natuurlijk wel complex. Naast het garanderen van een hoge beschikbaarheid, moet de werking van de markt natuurlijk ook 100% accuraat zijn. Als daar geen vertrouwen in zou zijn, dan kun je als beurs wel sluiten. De laaste jaren zie je daarnaast dat de transactie snelheid enorm is toegenomen en dat beurzen op alle vlakken (netwerk, server & software) continue optimalisaties aan het doorvoeren zijn. Never a dull moment wat dat betreft..

Ik denk dat je in a nutshell kan zeggen dat producten (aandelen/opties/etc) alleen of in groepen op geclusterede nodes draaien (veelal x86/Linux, voorheen vaak alpha/vms), mocht een cluster uitvallen dan draait in ieder geval de rest van de markt nog door. Beurspartijen verbinden naar een of meerdere gateways en deze gateways staan weer in verbinding met de nodes. Op de nodes draait dus de daadwerkelijke markt voor een product. De nodes geven zelf weer de markt data (aandelen prijzen) af aan tickerplants en deze wordt veelal middels multicast afgeleverd bij beurspartijen, marktdata leveranciers, etc. Gateways, nodes en tickerplants maken (vzv ik weet) gebruik van infiniband voor communicatie.

Vwb de beurs handelspartijen zelf.. Het hangt er maar net vanaf hoe groot deze is en wat z'n strategie is. Er zijn er (niet veel) die met een simpele pc en een vpn verbinding al handelen, anderen hebben een of een paar servers in een colo staan dicht bij de beurs met een redundante netwerk verbinding/cross connect en weer anderen nemen de snelste verbinding die de beurs aanbiedt (10 Gig) en verbindt deze direct op een fpga om maar zo snel mogelijk te kunnen reageren op een verandering in de markt. Overclocken van cpu's, inzetten van gpu's, real-time linux, etc, kan ook allemaal voorbij komen.

Handelspartijen kunnen trouwens niet ongelimiteerd opdrachten insturen. Op Eurex (Duitse optiebeurs) bijv kan je niet meer dan 150 transacties/berichten per seconde sturen per sessie die je naar de beurs open hebt. Het doel is om overbelasting van gateways (waar meerdere partijen opzitten) en nodes tegen te gaan.

[visser]

Dit artikel gaat helemaal nergens over dus dat kun je skippen. Wat wel interessant is om te weten of/hoe de server/netwerk setup van bijvoorbeeld de Amsterdamse effectenbeurs en alle bedrijven die daar op zijn aangesloten verschillend is met een 'standaard' server/netwerk setup. Het gaat echt om milliseconden dus ben eigenlijk wel benieuwd hoe ze dat technisch allemaal voor elkaar krijgen.

Is hier meer (publieke) info over?

Naast IP-televisie zijn 'financials' en dan trading zo'n beetje de enige andere plek waar multicast serieus gebruikt wordt.
Naar ik opmaak worden zo koersen verspreid 'naar iedereen tegelijk'.

Ook claimt bv Cisco dat (de terugkeer van) cut-through switching in de Nexus lijn (vs store-and-forward) onder andere om switch latency voor trading doeleinden nog lager te krijgen.
cut-through wil zeggen dat de switch al begint om het frame uit te sturen zodra het destination mac gelezen is, en niet wacht tot het hele frame binnen is.
Dat kan natuurlijk alleen als de destination poort langzamer of even snel is als de source poort.
Een nadeel is dat een corrupt frame dus niet afgevangen wordt in de switch. Voor heel lange tijd zijn etherswitches altijd store-and-forward geweest, maar daarmee introduceer je een (minimale) latency van snelheid*framesize .
(bij een maxframe van 1518 bytes op 100 Mbit/sec is dat 0.1 milliseconde of 100 microseconden)
http://www.cisco.com/en/US/prod/coll...11-661939.html
http://www.cisco.com/en/US/prod/coll...11-465436.html

Ook infiniband wordt genoemd als technologie om met heel weinig latency een applicatie te bereiken.

Ik heb niet direct zicht op of de latencies in de applicaties en server dan ook zo laag zijn dat dat uitmaakt, of dat switch latency wegvalt in de ruis; Maar in een gebied waar geld voor hardware echt niks uitmaakt en mensen 'het beste' willen kun je het in elk geval verkopen.

Verder worden er wat rechtere glasvezelpaden gelegd (een milliseconde round trip per 100 kilometer pad), dus op afstanden als Chicago-New York, of transatlantisch zijn er wel milliseconden te winnen als je de vezel wat strakker trekt.
Dat wordt ook geclaimed voor het (weer) gebruiken van straalverbindingen :
http://www.itworld.com/mobile-wirele...ance-transport

De lichtsnelheid in glas is ongeveer 2/3 van die in lucht, dus dat scheelt een behoorlijke factor. Als in het modulatiepad niet al te veel vertraging zit, en de behoorlijk slechtere BER (bit error rate) van straalverbindingen (vs glas) blijkbaar geen probleem is is dit ook voorstelbaar.