Controllo della congestione TCP per rete 10GbE a bassa latenza -> 1GbE?

Ho un server con una connessione 10GbE a uno switch e 10 client ciascuno con una connessione 1GbE allo stesso switch.

Eseguendo nuttcp in parallelo su ciascuno dei client, posso inviare simultaneamente 10 flussi di dati TCP al server alla velocità del filo (ovvero appena 100 megabyte al secondo da tutti e 10 i client contemporaneamente).

Tuttavia, quando invertisco la direzione e invio i dati dal server ai client, ovvero 10 flussi TCP, uno diretto a ciascun client, le ritrasmissioni TCP salgono alle stelle e le prestazioni scendono a 30, 20 o addirittura 10 megabyte al secondo per cliente. Voglio aumentare questi numeri, perché questo schema di traffico è rappresentativo di alcune applicazioni a cui tengo.

Ho verificato che il mio server è in grado di saturare un collegamento 10GbE eseguendo lo stesso esperimento su una connessione 10GbE a un server simile. Ho verificato che non ci sono errori su nessuna delle mie porte.

Alla fine, quando forzo (limito) forzatamente le dimensioni della finestra TCP del ricevitore, posso aumentare leggermente la larghezza di banda (30-40 megabyte / sec); e se lo stringo estremamente in basso, posso portare a zero le ritrasmissioni (con la larghezza di banda ridicolmente bassa).

Quindi sono ragionevolmente fiducioso di superare i buffer nel mio switch, con conseguente perdita di pacchetti dovuta alla congestione. Tuttavia, ho pensato che il controllo della congestione di TCP avrebbe dovuto affrontare questo problema, alla fine stabilizzandosi a qualcosa di oltre il 50% della velocità del filo.

Quindi la mia prima domanda è molto semplice: quale algoritmo di controllo della congestione TCP sarebbe la migliore per la mia situazione? Ce ne sono molti disponibili, ma per lo più sembrano mirati a reti con perdita di dati o reti ad alta latenza ad alta larghezza di banda o reti wireless ... Nessuna delle quali si applica alla mia situazione.

Seconda domanda: c'è qualcos'altro che posso provare?

linux networking tcp

— Nemo
fonte

Sarebbe utile sapere quale modello di switch. Diversi switch gestiscono l'accodamento in diversi modi e contribuirebbero a restringere una soluzione.

— scottm32768

Inoltre, switch diversi hanno dimensioni del buffer diverse, quindi conoscere il modello di switch contribuirebbe ad eliminare i problemi hardware dal problema.

— cpt_fink

Inoltre, i modelli NIC, i driver, la versione Linux, il kernel, la distribuzione, ecc. Le mie risposte per una scheda NIC Myricom o Solarflare con un Cisco 4900M sarebbero diverse da uno switch Dell Powerconnect e da una scheda NIC Intel.

— ewwhite,

Si vorrebbe un algoritmo in cui le dimensioni della finestra non si riducono drasticamente in caso di caduta di pacchetti. È il drastico calo delle dimensioni della finestra che si traduce in un improvviso calo della velocità effettiva con il traffico TCP.
Se lo switch e il server supportano il controllo del flusso, provare ad abilitare il controllo del flusso. Il modo in cui funziona dipende quasi interamente dal silicio e dal firmware dello Switch. Fondamentalmente, lo switch rileverà la congestione dell'uscita sulla porta che è connessa a un client, determinerà da dove provengono i pacchetti e invierà i frame di controllo del flusso fuori dalla porta di ingresso (cioè di nuovo al server). Se il server comprende i frame di controllo del flusso, ridurrà la velocità di trasmissione. Se tutto funziona bene, otterrai un throughput ottimale con praticamente zero pacchetti che si verificano sul buffer di uscita dello switch.

— wookie919
fonte