Interrogazione ultraveloce tramite pacchetti UDP

10

Sto implementando un sistema in cui un dispositivo su una rete esegue una query a una frequenza molto elevata (centinaia o migliaia di query al secondo) inviando un piccolo pacchetto UDP con circa 8 byte di dati. Questo viene ricevuto da un'altra applicazione, forse su un altro dispositivo, che esegue un'elaborazione molto semplice e invia il risultato di pochi byte racchiuso in un altro pacchetto UDP.

Vorrei sapere che tipo di tempi di andata e ritorno sono fattibili con l'hardware tipico, dove i sistemi di comunicazione sono forse collegati via Ethernet cablata a pochi metri di distanza, tenendo conto dei ritardi di propagazione e trasmissione, ecc.

Altri pensieri e suggerimenti sono i benvenuti.

ethernet latency speed

— John Smith
fonte

2

potresti vedere latenze in decine o centinaia di microsecondi ... sicuramente una latenza inferiore al millisecondo ... in base alla tua descrizione, sembra che stia considerando un sistema di trading finanziario ... le latenze che chiedi dipendono molto dal tuo hw specifico e sei molto più bravo a condurre test che a chiedere consigli gratuiti

— Mike Pennington,

Mille grazie per la tua risposta. In realtà non è per un sistema di trading finanziario in questo caso. Volevo solo una vaga idea di cosa fosse possibile prima di iniziare l'implementazione, più come uno studio di fattibilità che altro.

— John Smith,

11

Un esempio Juniper MX80 ha ritardo di ingresso e uscita> di circa 8us, su switch cut-through a bassa latenza può essere <1us (forse 0.7us). (Ricorda che lo switch cut-through non può eseguire il cut-through al 100% del tempo, solo quando la porta di uscita risulta inattiva!)

1 km di fibra è circa 5us di latenza (di nuovo, singola direzione).

Il ritardo di serializzazione @ 10G per payload di dimensioni minime (46B) è di circa 67ns (0,067us), aumentando la velocità del collegamento, si riduce il ritardo di serializzazione.

L'intestazione IP è 20B, l'intestazione UDP è 8B, i dati sono 8B, quindi hai solo 36B di dati, il che significa che il tuo payload Ethernet includerà 10B di cestino che DEVI inviare, cioè se hai qualcosa da aggiungere al tuo payload aggiungilo, ha 0 costi di latenza.

Spero che tu possa estrapolare RTT da questi, moltiplicando il ritardo del dispositivo per il conteggio dei dispositivi e aggiungendo 5us per ogni chilometro di fibra e quindi moltiplicandolo per 2.

Non posso resistere all'aggiunta di alcuni pensieri su HFT.

Secondo questo volume HFT dimezzato tra il 2009 e il 2012. Suggerendo che le vittorie facili sono sparite. Mi piacerebbe vedere alcuni articoli scientifici o solo dati reali sulla latenza di HFT e sui suoi effetti sul profitto. Ho il sospetto che la latenza che influisce sui profitti commerciali sia di un altro livello rispetto alla latenza di cui stiamo parlando in questo momento. Il mio amico che costruisce una rete per uno dei maggiori scambi sembra pensare che siano solo i clienti a "abbassare == meglio" senza capire le scale.
Capisco perfettamente come l'HFT sia stato utile quando poche persone lo facevano, quando si poteva osservare il mercato A non vedere il cambiamento B vedere e capitalizzare su di esso. Alcuni stanno parlando dell'uso della regolamentazione per fermare l'HFT tassando ogni operazione, rendendola costosa per tutti, non penso che sarà necessario, penso che la finestra di opportunità si stia già chiudendo.

— ytti
fonte

Risposta eccellente e molto istruttiva, grazie. Anche alcuni pensieri personali su HFT!

— John Smith,

1

@JohnSmith, non trascurare di considerare il ritardo introdotto nei tuoi endpoint (come lo scheduler del sistema operativo o l'elaborazione del kernel) ... questo può contribuire in modo significativo al ritardo che ho menzionato in un commento precedente.

— Mike Pennington,

Ottimo punto sull'uso della dimensione minima del pacchetto a costo di latenza 0.

— generalnetworkerror

1

Penso che sull'hardware semi-accordato convenzionale dovresti essere in grado di:

Esci dal tuo stack di rete host
Il tuo prossimo stack di rete
Esci dallo stack di rete con il tuo "nuovo" pacchetto

In ~ 10 us a 10gig. Se blocchi davvero le cose, quel numero può essere significativamente più basso.

Quasi TUTTA la latenza che vedrai non proviene dall'hardware / cavi di rete, ma dai tuoi sistemi host. Un passaggio ragionevole (Arista, Gnodal, New Cisco, ecc.) Sarà inferiore a 1us.

Inizia assicurandoti che i processi che consumano i pacchetti UDP siano bloccati sullo stesso core degli interrupt della tua NIC. Da lì, assicurati che la coalescenza sulla tua scheda di rete sia disabilitata e da lì assicurati di avere MSI-X e DCA attivi.

Se sei più serio ... dai un'occhiata a OpenOnload di SolarFlare. Hanno una grande suite di strumenti per testare / verificare anche le prestazioni.

— radikalus
fonte