tl; dr
Per dare una risposta definitiva, sembrano necessari più test. Ma prove circostanziali suggeriscono che Linux è il sistema operativo utilizzato praticamente esclusivamente nella comunità a latenza ultra bassa, che elabora anche i carichi di lavoro di Mpps. Ciò non significa che sia impossibile con Windows, ma Windows probabilmente rimarrà un po 'indietro, anche se potrebbe essere possibile ottenere numeri Mpps. Ma questo ha bisogno di essere testato, ad esempio per capire a quale costo (CPU) è possibile raggiungere quei numeri.
NB Questa non è una risposta che intendo accettare. Ha lo scopo di dare a chiunque sia interessato a una risposta alla domanda alcuni suggerimenti su dove ci troviamo e dove indagare ulteriormente.
Len Holgate, che secondo Google sembra essere l'unico che ha testato RIO per ottenere maggiori prestazioni dalla rete di Windows (e ha pubblicato i risultati), ha appena chiarito in un commento sul suo blog che stava usando una singola combinazione IP / Port per l'invio dei pacchetti UDP.
In altre parole, i suoi risultati dovrebbero essere in qualche modo paragonabili alle singole figure principali nei test su Linux (anche se sta usando 8 thread - che, senza aver ancora verificato il suo codice, sembra dannoso per le prestazioni quando si gestisce solo un singolo flusso di pacchetti UDP e non facendo una pesante elaborazione dei pacchetti, e menziona solo pochi thread effettivamente utilizzati, il che avrebbe senso). Ciò nonostante lui stia dicendo:
Non mi stavo sforzando tanto per ottenere le massime prestazioni solo per confrontare le prestazioni relative tra vecchie e nuove API e quindi non ero così completo nei miei test.
Ma cosa sta rinunciando alla (relativa) zona di comfort dello IOCP standard per il mondo RIO più ruvido oltre a "provare duro"? Almeno per quanto riguarda un singolo flusso di pacchetti UDP.
Immagino che cosa significhi - mentre ha provato vari approcci di progettazione in diversi test di RIO - è che non ha ad esempio perfezionato le impostazioni della NIC per ridurre le prestazioni. Il che, ad esempio nel caso della dimensione del buffer di ricezione, potrebbe potenzialmente avere un impatto positivo enorme sulle cifre relative alle prestazioni e alla perdita di pacchetti di UDP.
Il problema, tuttavia, quando si tenta di confrontare direttamente i suoi risultati con quelli di altri test Linux / Unix / BSD è questo: la maggior parte dei test, quando si tenta di spingere il limite dei "pacchetti al secondo", utilizza la dimensione del pacchetto / frame più piccola possibile, ovvero una Ethernet frame di 64 byte. Len ha testato pacchetti da 1024 byte (-> un frame da 1070 byte), che (specialmente per No-Nagle UDP) può farti ottenere cifre di "bit al secondo" molto più elevate, ma potrebbe non superare il limite di pps per quanto riguarda i pacchetti più piccoli . Quindi non sarebbe giusto confrontare queste cifre così come sono.
Riassumendo i risultati della mia ricerca in Windows UDP ricevo prestazioni finora:
- Nessuno sta davvero usando Windows quando tenta di sviluppare applicazioni a bassissima latenza e / o ad alta velocità, in questi giorni usano Linux
- Praticamente tutti i test delle prestazioni e le relazioni con risultati reali (cioè non semplici pubblicità di prodotti) in questi giorni sono su Linux o BSD (grazie Len per essere stato un pioniere e averci fornito almeno un punto di riferimento!)
- UDP (socket standard) su Windows è più veloce / più lento che su Linux? Non posso ancora dirlo, dovrei fare i miei test
- UDP ad alte prestazioni (RIO vs netmap) su Windows è più veloce / più lento che su Linux? Linux gestisce facilmente la piena velocità della linea da 10 Gb con un singolo core a 900 MHz, Windows, nel migliore dei casi pubblicato è in grado di salire fino al 43% o 492kpps per un pacchetto UDP di grandi dimensioni di 1024, vale a dire che le cifre in bps per dimensioni più piccole saranno probabilmente significativamente peggio, anche se le cifre dei pps probabilmente aumenteranno (a meno che il fattore limitante non sia la gestione degli interrupt o qualche altro sovraccarico dello spazio del kernel).
Per quanto riguarda il motivo per cui usano Linux, ciò è dovuto al fatto che lo sviluppo di soluzioni che comportano cambiamenti del kernel come netmap o RIO - necessario quando si spingono le prestazioni al limite - è quasi impossibile con un sistema chiuso come Windows, a meno che i vostri stipendi non escano da Redmond, o hai un contratto speciale con Microsoft. Ecco perché RIO è un prodotto MS.
Infine, solo per dare alcuni esempi estremi di ciò che ho scoperto era e sta succedendo in terra Linux:
Già 15 anni fa, alcuni stavano ricevendo 680kpps usando una CPU Pentium III a 800 mHz, bus frontale da 133 mHz su una scheda NIC da 1 GbE. Modifica : Stavano usando Click , un router in modalità kernel che bypassa gran parte dello stack di rete standard, cioè ha "imbrogliato".
Nel 2013, Argon Design è riuscito a ottenere
spunta per scambiare latenze a partire da 35 ns [nano secondi]
Tra l'altro lo affermano anche
La stragrande maggioranza del codice di elaborazione esistente per il trading di oggi è scritto per Linux su architetture di processori x86.
e Argon usano lo switch Arista 7124FX , che (oltre a un FPGA) ha un sistema operativo
costruito sopra un kernel Linux standard.
