Qwfix Trading System

QWFIX C Equities är den senaste utvecklingen av QWFIX-produktlinjen som riktar sig mot den amerikanska inhemska aktiehandeln. Vi kommer initialt att stödja fem börser NYSE, ARCA, NASDAQ, BATS och Direct Edge. Equities trading står inför några utmaningar jämfört med terminshandel. Först och främst, Algoritmen kan behöva hålla reda på alla marknadsdata, filtrera bort dem som det inte är intresserad av och spåra klockorna i klocklistan och köpositionen av sina egna beställningar hela tiden. Med tanke på hur mycket data som berörs 5- 10GB per utbyte per dag och handelsmönsterportföljen med tiotals eller till och med hundratals aktier, är nyckeln till att skapa en låg latentmatningsbehandlare som kan minska lösenkursen för handel. Feded handler måste också interagera med orderhanteringen System, eftersom det måste hålla koll på orderköpositioner också. Nyckeln är effektivitet Att bygga ett effektivt handelssystem kommer att förbättra effektiviteten i operativsystemet mindre maskiner och lägre kostnader för samlokalisering och anslutning och trad En vinst som ligger framför andra för att få tag i likviditeten Det krävs en effektiv hantering av design och implementation. I en toppoptionsmarknadsfirma använder de en maskin för att bara handla en symbol, i grund och botten försöker sitt bästa för att minska eventuell latens. vår forskning kan vi se ibland en möjlig missprisad likviditet tas inom mindre än 100 mikrosekunders rundresa, omedelbart efter det att den har lagts ut. Marknadsdata som vunnits, man kan inte dölja sin handel. Avyttring av ditt handelssystem är 200 nanosekunder Långsammare än konkurrentens system per aktie i takt med marknadsdatahantering Antag att din algoritm måste hålla reda på 100 lager Så ditt system är i genomsnitt 10 mikrosekunder långsammare än konkurrentens system vilket är tillräckligt för att göra skillnad när man konkurrerar på samma eller liknande signaler. Normalt använder ett högsta handelsföretag med höga frekvenser en maskin endast för att handla om 20-30 lager, med många utgående orderingångsförbindelser för att skicka order i round robin. The Prod Uct True Lock Free System. QWFIX C Equities-systemet är sant låstfritt Förutom att optimera vårt system för cacheplats och pipeline-vänlig gjorde vi det nästan helt låsfritt. Det enda stället vi använder lås är att låsa vakt som skickar orderportfölj från flera trådar, och vi använde ett spinnlås för att göra det förutom det enda låset är hela systemet helt låsfritt, även fritt från atominstruktioner. Resultatet är fantastiskt, systemet kan löpa genom en hel dags värde av historiska data om 10 GB, samtidigt som du håller reda på boken av de bästa 600 aktiva bestånden och simulerar orderköpositionen inom ungefär en minut. Vår design ger användaren möjlighet att utforska maximal parallellitet. Vanligtvis är en kärna dedikerad till en tråd för en algoritm Marknadsdata uppdatering och hämtning kan göras parallellt inom skillnadstrådar och systemet vunnit t sänks i vilket fall oavsett hur många trådar samtidigt hämtar marknadsdata. Det enda stället som kräver s pinlås är orderhanteringsdelen Men den effekten är minimal Först och främst är API utformat för att ta en portfölj av order i taget. För det andra är latensen som införs av det enda låset bara omkring 100-200 nanosekunder om det inte finns några invändningar . QWFIX C Equities-systemet delar samma förvaltningskonsol med vår terminsprodukt Fler UI-widgets läggs till för handel med aktiehandel. API: n är noggrant utformad för att förena forsknings - och produktionsmiljön. Samma algoritmimplementering kan användas direkt för att simulera handel med historiska Marknadsdata Den metod används som ett sista steg i strategin utveckling. I ett annat ord använder utvecklaren vårt API för att utveckla algoritmer Innan vi använder riktiga pengar för handel, kan vi köra algoritmen i simulatormodus med historiska data. Det kommer att simulera algoritmen exakt Det kommer att vara samma API och samma kod för både produktion och simulering. Kostnad och risk kommer att reduceras avsevärt på detta sätt. För utvecklingen i tidiga stadier använder vi HDF5 för att lagra marknadsdata med olika detaljer. Till exempel, bokens topp, bokens nivåer, etc. Datasättningen kommer att användas på språk som Python, C, Java eller liknande för forskningsändamål. QWFIX Equities förväntas vara i produktion inom två månader. Vi arbetar parallellt med utveckling, testning och forskning. Å ena sidan, om vi tävlar om fart, kommer det bara att finnas en vinnare på marknaden Å andra sidan är endast hastighet spelar roll om folk konkurrerar på samma eller liknande signal Det är därför även om folk inte ens vet när de behöver bli snabba, kan de inte ha råd att förlora hastighetsfördelen. Tekniskt sett är FIX-protokollet svårt att vara optimerad för hastighet Det är helt enkelt inte konstruerat för låg latent handel med avseende på både kodningsavkodningsprotokoll och sessionsprotokoll. Vi kan emellertid fortfarande klara av att optimera FIX-baserad orderhantering för att uppnå låg latens. Trots allt kommer utbytesmatchmotorn troligtvis att sätta de paket som den tar emot tidigare till orderbokens kö. En bra design bör inte bara uppnå högpresterande, men också användbarhet programmeringsvänlighet och lågt underhåll. Utformningen av QWFIX har uppnått alla dessa mål utan att offra någonting. Nyckeln är Ordern Management API OMS API Det döljer helt den låga meddelandekodningsavkodningen och sessionhanteringen. Programmet behöver bara hantera beställningar skapa, avbryta eller ändra medan de fortfarande njuter av submikrosekunder. Ramverket stöder inte bara FIX-protokollet, men praktiskt taget alla protokoll som används i någon utbyte i denna värld som OUCH eller ETS. En annan utmaning under designtiden är stödet till flera utbyten. Varje utbyte behöver speciella implementeringar mer eller mindre. Vi lyckades få utvecklare att känna sig så bekväm som möjligt som arbetar med QWFIX. I vår design finns det Endast en universell orderklass Det finns två typer OrderManager-klasser som fungerar tillsammans En typ är utbytesoberoende En annan typ är utbytesberoende som ger utbytesspecifika orderhanteringsfunktioner. OMS API är utformat för att passa in i hela QWFIX HFT-ramverket. Hela systemet är inte bara optimerat för latens utan också för genomströmning. Vi använde CME NewOrderSingle FIX-meddelande till Utföra referensvärdet. På vår 3 33 GHz Intel Xeon-server uppnådde vi 0 8707 oss 870 ns per meddelande för följande operationer combined. Create ett FIX NewOrderSingle Message. Set-fält i meddelandet. Booking håller med OMS API. Kod meddelande till FIX data stream. Release FIX message. Note 0 8707 oss är maximal latens Eftersom vi kan använda upp till två trådar per utgående FIX-session, blir den faktiska genomströmningen t begränsad av det latenta numret om nätverket inte är flaskhalsen. Jag kan ytterligare förbättra prestanda om systemets prestanda utmanas av något annat system. Efter att jag lagt upp bloggen om den snabbare FAST-dekodern gjorde jag ytterligare förbättringar. Här är det senaste resultatet med hjälp av samma CME-datafil. Total tid 11 797371 sekunder Paketinmatning maxEntries 34217764 165204011 116 0 344773 mikrosekund per paket 0 071411 mikrosekund per inmatning. Testad på samma 3 3 GHz Xeon. Jeff gjorde viss förbättring och nu kan han bearbeta samma fil inom 9 5 sekunder på en 3 GHz-kärna i7 Således är resultatet fortfarande cirka 20 bättre. Efter att ha pratat med honom insåg jag att våra dekoder har olika användarkrav. Jag försökte göra min avkodare mer generellt till kostnaden för lite prestanda. Alla Jag kan säga har samma användarbehov Jag kan göra en implementering så fort som hans Men jag skulle vilja stanna med mina nuvarande normaliserade klasser. Min implementering kommer att kunna fylla de avkodade fälten i en fördefinierad klass, utan något antagande om meddelande mall Varje fält har en bool typ närvaro flagga som upptar 8 byte i strukturen Meddelandet hanteras effektivt inom en objektpool och varje gång innan meddelandet returneras till poolen måste det återställas ed, dvs närvaroflaggarna måste vara memset till false. Below är definitionen av de två mest använda meddelandena i CME, MDIncRefresh och MDEntries Anmärkning skapades automatiskt av mitt system. I själva verket kan mitt system generera fin kod så här från en given FAST mall. Avkodaren vet hur man effektivt fyller i strukturen Det kan ta många statiskt genererade mallhanterare såväl som dynamiskt genererade hanterare under körning. Naturligtvis ger statiskt genererade hanterare bättre men dynamiskt genererad hanterare garanterar flexibilitet och robusthet. En unik signatur kommer att genereras tillsammans med varje annan version av FAST mall för att garantera att systemet kan dynamiskt detektera mallversionens förändring vid start. En annan trevlig funktion om denna design är att avkodaren kan ignorera några fält man inte är intresserad av, med lite prestandaförbättring Exempel, jag brydde mig aldrig om TradeDate-fältet för de instrument jag är intresserad av d i det är bara det aktuella sessionsdatumet. Tyvärr resulterar denna flexibilitet i en viss kostnad i form av prestanda. Om du har kommit överens om återställningen av Memset-meddelandet kommer du att ha 1 5 sekunders förbättring med samma CME-data. För att inte tala om kostnaden för att ställa in närvaro flaggor Under avkodningen kan vara lik eller till och med högre. Överallt är jag ganska nöjd med min FAST dekoder. Den kan avkoda vid hållbar genomströmning på över 200 MB s. Allt började från en länkad inlägg Ett inlägg om prestanda för en viss FAST-dekoder omvandlades till en serie av kommentarer med fordringar och frågor. En särskild kommentar tog mitt intresse från Jeffrey M Birnbaum. Han publicerade referensvärdet av hans avkodare med några exceptionella siffror. Även om det väckte mycket tvivel vet jag att det inte är omöjligt. Jag skrev faktiskt i en tidigare kommentar med några tankar om hur jag kan göra för att förbättra min dekoder Det är bara några tankar och jag störde aldrig att implementera det Jeffery s arbete inspirerade mig att börja implementera mina idéer. Så jag tillbringade en hel helg på förbättringen Resultatet är ganska viktigt Jag ser en tre gånger förbättrad prestanda med min nya implementering Så jag mailade Jeffrey med mitt resultat och tackade honom för hans inspiration Jeff vände tillbaka min e-post Och jag lärde mig två saker från hans email Först och främst verkar det som att hans metod är annorlunda än mina. För det andra är han extremt säker på överkroppen hos hans dekoder. Så bestämde jag mig för att ta hans utmaning och gå in i en vänskapsmatch mot honom. Precis som Jeff sa, Jag gillar en liten tävling och i slutändan kommer vi att göra varandra lite bättre Jag måste säga ytterligare förbättring är inte lätt Jag vet vad jag ska göra men det är allt tråkigt och det krävs ansträngningar för att komma dit För att göra lång historia kort, Jag lyckades göra lite tid för jobbet och just nu, efter en vecka, har jag något resultat. Innan vi går längre, låt mig först förklara CME-marknadsdata som jag använde CME sprider både citatförändringar och handelsinformation i snabbform Vid FAST-meddelandet eller - segmentet är inslaget i UDP-multicast-paket. För närvarande innehåller ett UDP-paket endast ett FAST-meddelande. FAST-kodningsmetoden kan komprimera information med mycket hög kompressionsförhållande. Strukturen för FAST-meddelandet är mycket flexibelt och ganska komplicerat. Det är i princip ett träd Struktur med fördefinierat schema FAST-mall i XML-format Det mest använda meddelandet heter IncrementalRefresh. The IncrementalRefresh kan innehålla flera poster med citat och handelsförändringar. Till exempel, om den nuvarande marknaden bäst bud och erbjudande är Erbjudande 129000 X 200 Bud 128975 X 50 Och det finns två beställningar som sitter i bästa bud med 25 kontrakt varje gång någon skickat en marknadsorder för att ta 50 kontrakt från budsidan. Det kan resultera i en IncrementalRefresh med 3 MDEntries Trade 25 128975 Handel 25 128975 Citat Ta bort budnivå 1. Det kan finnas vissa förvirring om FAST riktmärke resultat eftersom vissa referera meddelande som UDP paket och vissa referera meddelande som varje snabb segment i exemplet ovan , om meddelandet kallas varje snabbt segment, så är de totala meddelandena 3 annars är det 1.Jeff föreslår att MB sek är den enda rättvisa jämförelsen och jag håller med honom. Nu kommer mitt resultat, testat på min 3 33GHz Xeon server med GCC 4 4 0.Total tid 14 743588 sekunder Paketinmatningar MaxEntriesPerPacket 34217764 165204011 116 0 430875 mikrosekund per paket 0 089245 mikrosekund per inmatning. Markerad med en fil med storlek 2838.336.532 byte I referensresultatet som anges ovan refererar paketet till UDP paket från CME Entry hänvisar endast till MDEntry som ingår i paketet som inte inkluderar MDIncRefresh eller MDSnapshotFullRefresh body. We kan säga att för den dagen finns det i genomsnitt 0 43 0 089 4 83 MDEntries per UDP-paket Men det största meddelandet innehåller 116 poster i ett enda paket. Kan jag ytterligare förbättra det självklart Jag kan nu optimera heltalet, PMAP och strömhantering. Stringhantering är endast delvis optimerad Och ordboken är inte optimerad alls Använder fortfarande flera std vektorarrayer Jag kan enkelt klämma ut dussintals extra nanosekunder från varje inmatning s processing. The skönheten om FAST protokoll är att när implementeringen är klar behöver man bara få en mallfil från utbyten som stöder FAST baserade marknadsdata Arca bok, Eures, EBS etc, för att avkoda marknadsdata från utbytet. Så ja, mitt genomförande är universellt. Så vad betyder det. För vissa strategier, om man alltid måste konkurrera med andra om vissa aktier, Det kan innebära att svara på många mikrosekunder snabbare än konkurrenter under vissa marknadsförutsättningar. Vi har hört talas om prestationskrav från FPGA: er Men både Jeff och jag håller med om att det är lite överskattat Det kommer att bli svårt för FPGA att matcha prestanda för effektiv implementerad ren programvaruavkodare, om inte omöjligt Nu är den största flaskhalsen TCP UDP-nätverksprocessorn Det kan vara något FPGA kan göra för att göra betydande förbättringar Men tyvärr har jag inte sett någon FPGA-produkt gå Om du är intresserad av den vänliga matchen mellan Jeff och mig, kan jag bara säga att Jeffs ursprungliga nummer är ännu bättre än mina han använder en 2 99 GHz Core i7 och en annan dataset Även om jag fortfarande väntar på sitt uppdaterade resultat, skulle jag säga att det kommer bli svårt för någon av oss att blåsa dörrarna från den andra s. Update Från och med 8 feb 2011, vid midnatt, Jeff skickade mig sitt aktuella referensresultat med samma data på en 2 93 GHz Core I7 Det är 12 5 sekunder att bearbeta hela filen I det här fallet kommer jag att vara skyldig att ytterligare förbättra mitt genomförande Förhoppningsvis kan jag få det gjort av Imorgon Låt spelet fortsätta och håll dig stillad. QWFIX HFT CME är en hel svit av högfrekvent handelsplattform, fullt certifierad, körs i produktion för CME-handel. Huvudfunktionerna inkluderar. QWFIX C Pure C-algoritm-exekveringsmotor. Sera 5 mikrosekund - trade latency. Simple, flexibel orderhantering OMS API. Strategy motor API implementera och QA en ny algoritm inom 2 days. GUI-baserad konfiguration, realtidsövervakning och forskningsverktyg. Research tools. Realistic C-baserat online simulator test och QA din produktionskod med realtidsmarknadsdata. Realistisk baserad offline simulator API Test din algoritm med historiska marknadsdata. Post-trade analyzer API analysera din historiska handelslog. GUI-baserad historisk tick-by-tick-marknadsdataanalysator. Design och implementering av QWFIX fokuserar på enkelhet utan att påverka prestanda. QWFIX använder följande tekniker för att Uppnå prestanda under 5 mikrosekunder. Kraftfri trådmodell Alla prestandakritiska kod använder endast spärrlås. Anpassad minneshantering Alla prestandakritiska kod använder anpassad och låslös minneshantering med fördelad minnespool. Avancerad arkitektur Threading-modell, IO modell och minnehantering är utformade för att samarbeta för att uppnå bästa övergripande prestanda. OS Hårdvaruoptimering Designad t O arbetar med Linux RT Kernel och Solarflare nätverkskort med OpenOnLoad driver. Programmer Friendly API. QWFIX C API är extremt enkel och enkel att använda Det tar vanligtvis en dag att implementera en ny algoritm, test och QA det nästa dag och sätta Den är i produktion på tredje dagen. Order Management API. En orderhanterare skapas för varje instrument på varje handelsdag. API tillhandahålls för att skicka, avbryta och ändra order. Statisk information, t. ex. Symbol och SecurityDesc, initialiseras endast en gång när ordern Manager är skapad för att förbättra prestanda. Multiple strategier kan köras samtidigt Varje strategi identifieras med ett unikt tal heltal, jag brukar använda ett datumnummer som 20110101.Implementering av en ny strategi är extremt lätt Programmeraren behöver bara subklassera ett strategibjekt och implementera egna händelsehanterare. High Performance Logging. Logging är snabbt och enkelt. Det tar två rader av kod för att lägga till en post i systemloggen. Det tar ungefär 200 nanosekunder och kommer att skrivas n till disk asynkront Den loggade posten kan ses med GUI-realtidshanteringsverktyg eller hämtas med postanalysanalys API. Konfigurationshantering GUI. Enterprise Manager används för att konfigurera QWFIX-systemet. Det innehåller följande. Anpassning av FIX-schemaordbok CME kan ibland ändra kravet på FIX-meddelandet genom att lägga till eller ändra nödvändiga taggar i message. Customizing FIX-sessioner Ange initierings - och acceptorns CompID, IP-adresser, schemaläggare och andra parametrar. Anpassa FIX engine. QWTradeMonitor används för att hantera automatiserad handelsprocess i realtid. QWTradeMonitor kan också användas som ett felsökningsverktyg under algoritmimplementering. Den realtidsloggvarningar som genereras av fjärrprocessen kan övervakas med GUI-verktyget. Observera att samma loggar också kan hämtas via programmässigt post-trade API. Varje FIX-meddelandekommunikation kan Ses med fullständiga detaljer, inklusive 3 tidsstämplar Var snäll och hur snabbt det är innan meddelandet skapades timstamp1 Till det skickade samtalet returnerar timestamp3 för inloggningsmeddelandet Observera att det tar lite längre tid att bearbeta Inloggningsmeddelandet För orderrelaterade meddelanden tar det bara cirka 2-3 mikrosekunder. Direkttids fjärrmarknadsdata. Marknadsdata kan visas tillsammans med kort orderinformation totala order och totala kvantiteter på varje prisnivå. Real-time Orders, Execution, Position och P L. Every order, varje körning och alla fält i FIX-meddelandet kan övervakas i realtid tillsammans med realtidsposition och P L. Remote trading strategier kan kontrolleras fullt ut av QWTradeMonitor. QWFIX C online-simulator kan användas för att realistiskt testa och QA-produktionen automatiserat handelssystem. Offline Simulator offline simulator kan användas för att realistiskt undersöka handelsstrategier. Post Trade Analysis API posthandel API kan användas för att göra posthandel analys Det tar cirka 10 linjer kod att hämta alla detaljer i hela orderflödet Beställningar kan grupperas med olika strategier Varje order eller utförande kan matchas mot exakt marknadsdata just nu när den bearbetades. Varje statusändring kan analyseras ytterligare visuellt med det GUI-baserade forskningsverktyget QWTradeAnalyzer. GUI Based QWTradeAnalyzer. QWTradeAnalyzer kan användas för att analysera tick-by-tick historiska marknadsdata. Flera instrument kan synkroniseras med tidstämplar Att utforska spridning av överkurs-tillgångsklass handelsmöjligheter. Order och avrättningar kan synkroniseras med frikopplingsdata för handelsstrategisk forskning eller efterhandelsanalys. Sessionnivå eller affärsnivå Meddelande Avvisa. Sessionsnivå Avvisa och ansökningsnivå BusinessMessageReject-meddelanden gör orderhanteringen mer komplicerat. Till exempel skickade en köpsidans ansökan en ny order till säljsidan. Säljesidan sessionsmeddelande validato R eller anpassade Visual Lambda-regler kan skicka meddelandet på sessionen I det här fallet skickas ett Avvisa FIX-meddelande till köpsidan. Och säljsidans ansökan kommer aldrig att ha någon chans att se meddelandet eftersom det avvisades på sessionen utan att ha en chans att nå ansökningsnivån. För att kunna ta emot händelser relaterade till sessionsnivå avvisas, är ansökan nödvändig för att implementera ett FIXSessionOrderManagerSessionRejectListener interface. Listener kan läggas till eller tas bort från en FIXSessionOrderManager-förekomst genom att ringa och. Event Handlers. In QWFIX, Sessionsnivåavvisningar hanteras korrekt för följande FIX-meddelanden. FIX Meddelandetyp. Order Status Request-meddelandet avvisas Sälj sida vunnit se begäran. Notera att avvisningen inte ska hända i produktionsmiljö Det indikerar problematisk implementering av affärslogik I QWFIX vi gör vårt bästa för att minimera effekterna av problemet Under tiden kommer felmeddelanden att skrivas till loggen, whic H är tillgängligt via vårt GUI-baserade hanteringsverktyg, QWRTAnalyzer. Business Message Reject. Business Message Reject skapar endast en post i varningshändelseloggen. Vi rekommenderar att du använder Business Message Reject för att avvisa ogiltiga meddelanden relaterade till lista och överföringar. Det är dock upp till Våra kunder hur man implementerar logiken eftersom den inte ingår i standard FIX-specifikationen. Teraspace kommer att arbeta nära våra kunder för att lägga till sin anpassade affärshantering för felhantering i vår orderhanteringskomponent. Automatisk orderstatusuppdatering. QWFIX Order Manager runtime wil Automatiskt korrigera orderstatus när ett meddelande avvisas på sessionsnivån. Till exempel, om en order skickas och avvisas av motparten på sessionsnivån, kommer inte bara en sessionRejectedOrder-händelse att utlösas OrdStatus av ordningen kommer automatiskt att vara ändras till Avvisad Och en händelse kommer också att utlösas. Samma sak händer när en begäran om avbrytningsförfrågan eller ersättningsbyte avvisas På sessionen nivå Denna begäran kommer att avlägsnas från pågående förfrågningar Effekten är densamma som för en Avbryt Avvisningsprestanda - Latency, Genomströmning etc. Vi gjorde ett latentest av QWFIX Trading System i olika smaker. De vanliga vanliga Java-versionerna och RTSJ Version med realtid Java. Vi kör två processer på samma maskin En serverprocess och en klientprocess Det finns 5 FIX-sessioner mellan klient och server, som kör FIX-versioner från 4 1 till 5 0SP1 Båda processerna är byggda med QWFIX SDK med QWFIX-order Lednings-API. Notera i referensprovet mäter vi hela systrems latens, inte bara FIX-motorens latens. Latensen blir FIX-motorns latens plus orderhanteringssystemet. Eftersom det är svårt att synkronisera tidskällor kör vi både klientprocess och serverprocess på samma maskin och vi mäter omloppsfördröjningen på klientsidan. Med tanke på förlust av allmäntid kommer kunden varje gång att skicka en New Order Si Ngle FIX-meddelande till en slumpmässigt vald session bland alla 5 tillgängliga sessioner När servern mottar meddelandet New Order Single, utför det alla nödvändiga kontroller, t. ex. ClOrdID-kontroll, undvik duplikat ClOrdID och håller hela boken också. Då kommer servern att generera en bekräftelse Utföringsrapport till den specifika beställningen och skicka den tillbaka När klienten mottar utföringsrapporten registrerar den latensen för den enskilda ordern och upprepar processen genom att skicka en annan order. I testet skickas 1 miljoner nya beställningar med ett enkelt meddelande från klienten och I sin tur skickas 1 miljon Execution Report-meddelanden av servern. Klienten registrerar 1 miljoner latensnummer i mikro-sekunder. Hårdvara och OS. Hårdvaran är en arbetsstation med en Intel Core i7 920 processor, 2 GB minne och 1 5 TB seagate hårdvara. Den körs på 64 bitars Windows Vista Ultimate. QWFIXJ och QWFIXRTSJ-versionerna körs på 64 bitars OpenSuse 11 1 Linux med realtime-kernel. Latency Resultat för QWF IXRTSJ. As förväntad, QWFIXRTSJ som körs i en Sun-realtid Java VM erbjuder det bästa latentnumret. Enstaka enstaka tidsfördröjning 0 32ms.99 999 meddelanden har 1ms latens.0 001-meddelanden har 2ms latens.1 av 1 miljoner meddelanden har onormalt jitter på 10-400ms Vi tror att det är orsakat av filsystem och det finns inget vi kan göra åt det. Som visas i diagrammet nedan, erbjuder QWFIX RTSJ en genomsnittlig latens på 633 mikrosekund 0 633 millisekund av omgångstiden. Rundturens latens kommer att omfatta 2 FIX-meddelandekodning, två FIX-meddelandekodning och affärslogikhantering av orderhantering, plus nätverksöverföringen mellan två processer som körs på en enda maskin. De första 30 FIX-meddelandena för varje FIX-session kommer att ha något högre Latens första meddelande är ca 18 ms och resten 30 kommer att ha cirka 2ms-3ms runt-trip latens. Det orsakas av JIT just-in-time compiler för den virtuella maskinen. Detta beteende observeras på både och Java virtuella maskiner. Den JIT har Att dynamiskt sammanställa koden när koden exekveras Den görs dynamiskt eftersom det är opraktiskt att sammanställa hela runtime-miljön vid starttiden. RTSJ har ett sätt att förhandsregistrera några möjliga exekveringsbanor och förkompilera allt längs vägen under Starta upp. Vi har ett ganska roligt arbete för att skicka 30 dumy beställningar i början av dagen och avbryta dem omedelbart och det fungerade mycket bra. Jitters - 2ms - 4ms Round Trip Latency 1 i 100.000 meddelanden. Vi observerade regelbundet något Högre latens under testet För varje meddelande på cirka 100,0000 meddelanden kommer vi att ha en runda fördröjning på mellan 2ms och 4ms. Extreme Jitters - 4ms - 400ms 1 i en miljon chans. Det finns 4 av 4 miljoner FIX-meddelanden vi bearbetade inkurerade mycket högre latenser Dessa latenser sker långt ifrån varandra, allt från tiotals millisekunder till hundratals millisekunder. Lyckligtvis är chanserna för de extrema latensspikarna mycket sällsynta. Förvänta en sådan latens För varje 1 miljon FIX-meddelanden. Vi misstänker att 1 av en miljon chans latenspinnar utlöses av filsystemet, vilket är helt utan någon s kontroll. Vi tror att sådana latenser är resultatet av systemfelet och kan inte undvikas för Nu, oavsett vilket programmeringsspråk du använder. Som förväntat kan QWFIX verkligen inte ge någon latent garanti. För närvarande levereras bara med vanlig sopsamlare som regelbundet ska pausa världen för att göra skräpsamling. Omkring 2 av de totala meddelandena drabbas av en omgångsfördröjning om 2ms - 100 m. Men erbjuder erbjudandenna mycket högre genomströmning än Java På samma maskin observerade vi genomsnittlig latens på cirka 0 33 ms, 60 bättre än QWFIXJ och QWFIXRTSJ. Our och QWFIXJ följer exakt samma design Faktum är att vi till och med gjorde mer optimering i Java-version än version Men Netversionen kör fortfarande mycket snabbare än Java-versionen, på alla plattformar. QWFIXJ erbjuder inte bra latens, antingen under testet fick vi reda på perfekta ormance är bättre på Linux än på Windows Vista. Diskussion - QWFIXRTSJ vs QWFIXJ. Realtid Java RTSJ är fantastisk Det levererar prestanda exakt som Sun lovade. Det är mycket väl lämpat för extremt högfrekvent handel. Vår QWFIXRTSJ har exakt samma design som och QWFIXJ Källkoden för QWFIXRTSJ är nästan densamma som QWFIXJ Skillnaden är mindre än 50 linjer kod. Nu är frågan varför inte vi helt ersätter QWFIXJ med QWFIXRTSJ. Well, QWFIXRTSJ har en nackdel och endast en nackdel Från och med nu erbjuder Sun bara 32 bitarsversion av RTSJ I praktiken kan vi bara tilldela cirka 3 GB minne för RTSJ-aktiverade processer. Vi kan cache ca 6 miljoner FIX-meddelanden i ca 2 GB minne och lämna resten 1GB för annan användning. Och det är Ungefär den övre gränsen för QWFIXRTSJ-kapacitet per process, vilket betyder att den överstiger en miljon order. QWFIXJ är optimerad för både 32 bitar och 64 bitar av virtuell maskin På 64 bitars Java har Q-kapaciteten WFIXJ är praktiskt taget obegränsad. Diskussion - QWFIXRTSJ vs. First of all, använder de olika teknologier Net vs Java. Enligt vår observation är den virtuella maskinen generellt snabbare än Java VM, åtminstone för QWFIX-produkter. Men Net är endast tillgängligt för Windows Plattformen Även om Mono har utvecklats ganska mogen på andra plattformar är adoptionsgraden för handelsapplikationer på Mono fortfarande ganska liten. Det finns många faktorer som måste beaktas när det gäller vilken plattformsteknik som ska väljas. Vi är mycket väl förberedda att erbjuda alla Olika smaker till våra kunder. Varken Windows eller det är inte ett realtidssystem för nu. Först och främst är Windows-kärnan precis som vanliga Linux-kärnor, vilket inte är fullt preemptive. Kärnan kan inte garantera ett högt prioriterat jobb förutspår ett lågt prioriterat jobb vid när som helst Vi kan göra en Linux-kärna fullständigt förebyggande genom att tillämpa lämplig kärnplattform Men det finns inget sådant alternativ på Windows-plattformen. Windows och helt olyckligt f eller högfrekvent handel Tja, även om Windows inte är svårt i realtid OS Det är fortfarande mycket snabbt och kan fungera som ett mjukt realtid OS mycket bra Under det kommande året kommer Microsoft att släppa 4 0, vilket kommer att innehålla en ny typ av GC som heter Bakgrund GC, vilket är mycket lik den realtid GC som används i RTSJ Det blir intressant att se hur det går ut på 4 0.Remember med RTSJ har vi fortfarande jitters, även om det händer mycket sällan Vi har ett ganska komplicerat system och ingenting Kan garanteras Det är verkligheten Teoretiskt Även en nysning kan påverka vibrationen på din hårddisk och därmed påverka överföringshastigheten. Lyckligtvis har vi ett sätt att testa systemets prestanda och är ganska övertygade om hur det beter sig. i handelsvärlden hanterar vi mycket större osäkerhet Vi tillhandahåller tillräckligt med information till våra kunder och det är upp till dem att välja vilken teknik som är bäst av dem. QWFIX är ett allmänt ändamål, FIX-protokollbaserat handelssystem Med abou t 50 linjer av kod en kan hantera hela dagordningens orderflöde. För information om utformningen av QWFIX Trading System, läs vår design vitbok.