migliori prestazioni TCP su una "rete ad alto ritardo"

Sto cercando di migliorare il mio throughput TCP su una "rete ad alto ritardo" tra macchine Linux.

Ho impostato tcp_mem, tcp_wmemed tcp_rmema “8192 7.061.504 7.061.504”.
Ho impostato rmem_max, wmem_max, rmem_defaulte wmem_defaulta “7.061.504”.
Ho impostato netdev_max_backloge txqueuelensu 10000.
Ho impostato tcp_congestion_controlsu "scalabile".

Sto usando "nist" (cnistnet) per simulare un ritardo di 100 ms e il BW che raggiungo è di circa 200 Mbps (senza ritardo raggiungo circa 790 Mbps).

Sto usando iperf per eseguire i test e TCPTrace per analizzare i risultati, ed ecco cosa ho ottenuto:

Sul lato ricevitore:
max win adv: 5294720 byte
avg win adv: 5273959 byte
sacchi pkts inviati: 0

Sul lato mittente:
byte di dati effettivi: 3085179704
byte di dati rexmt: 9018144
max owin: 5294577 byte
avg owin: 3317125 byte
RTT min: 19.2 ms
RTT max: 218.2 ms
RTT avg: 98.0 ms

Perché raggiungo solo 200 Mbps? Ho il sospetto che "owin" abbia qualcosa a che fare con esso, ma non sono sicuro (questi risultati sono di un test di 2 minuti. Un test di 1 minuto aveva un "avg owin" di 1552900) ...

Sbaglio se mi aspetto che il throughput sia quasi 790 Mbps anche se il ritardo è di 100 ms?

(Ho provato a usare numeri più grandi nelle configurazioni della finestra ma non sembrava avere effetto)

Questo è un problema TCP comune chiamato "Long Fat Pipe". Se cerchi quella frase e TCP su Google troverai molte informazioni su questo problema e sulle possibili soluzioni.

Questo thread ha un sacco di calcoli e suggerimenti sull'ottimizzazione dello stack TCP Linux per questo genere di cose.

Il sito

http://www.psc.edu/networking/projects/tcptune/

menziona il fatto che, al giorno d'oggi, Linux esegue l'autotuning delle impostazioni TCP, probabilmente fare confusione con i valori non migliorerà le cose.

Detto questo, forse 100 ms insieme a una grande larghezza di banda (almeno 790 mbps) potrebbero portare a un BDP enorme, quindi forse l'autotuning decide che qualcosa non va e non va abbastanza lontano ..

Prova a impostare la dimensione della finestra iperf per manipolare davvero il prodotto di ritardo di larghezza di banda di quel link. Quindi avg. RTT * 1Gbps dovrebbe darti circa 10 MB. Vedi se questo migliora le cose.

L'unico modo in cui puoi davvero iniziare a capire cosa sta succedendo è ottenere più dati, altrimenti stai solo indovinando o chiedendo ad altre persone di indovinare. Consiglio di ottenere una vista a livello di sistema (CPU, memoria, interrupt, ecc.) sarDal iostatpacchetto. Inoltre, dovresti ottenere un dump di pacchetti con Wireshark o tcpdump. È quindi possibile utilizzare Wireshark per analizzarlo in quanto ha molti strumenti per questo. È possibile rappresentare graficamente le dimensioni della finestra nel tempo, la perdita di pacchetti, ecc.

Anche una piccola perdita di pacchetti su un collegamento ad alta latenza tende a danneggiare un po 'la larghezza di banda. Anche se simulato - questo è un po 'strano. Molti piccoli pacchetti potrebbero anche causare interruzioni elevate (anche se potrebbero essere simulate anche?).

Quindi in breve, chiedi a TCPDump e Sar di vedere cosa sta succedendo a livello di pacchetto e con le risorse del tuo sistema.

Quanta memoria ha questa macchina? Le tcp_memimpostazioni sembrano folli, ha configurato 28 GB (7061504 * 4 KB) per i dati TCP a livello globale. (Ma questo non è il tuo problema perfetto poiché molto probabilmente non raggiungi quel limite durante l'esecuzione di un test con pochi socket. Volevo solo menzionarlo poiché l'impostazione di tcp_mem su tcp_xmem mostra un errore molto comune).

Il 7mb che hai configurato per impostazione predefinita sembra ok. Il massimo tuttavia può salire molto più in alto su grandi tubi di ritardo. Per i test userei 64 MB come numero massimo per tcp_wmeme tcp_rmem, quindi puoi escludere che questo è il tuo fattore limitante. (Questo gonfia i tuoi buffer, quindi funziona solo se hai una concorrenza limitata e la connessione ha jitter e drop bassi).