Perdita di pacchetti UDP estrema a 300 Mbit (14%), ma TCP> 800 Mbit senza ritrasmissione

11

Ho una scatola Linux che uso come iperf3client, testando 2 scatole server Windows 2012 R2 identicamente equipaggiate con Broadcom BCM5721, adattatori da 1 GB (2 porte, ma solo 1 usato per il test). Tutte le macchine sono collegate tramite un singolo interruttore da 1 Gb.

Test di UDP ad es. 300Mbit

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

provoca la perdita del 14% di tutti i pacchetti inviati (per l'altro server box con lo stesso hardware esatto, ma driver NIC meno recenti, la perdita è di circa il 2%), ma la perdita si verifica anche a 50Mbit, anche se in modo meno grave. Prestazioni TCP utilizzando impostazioni equivalenti:

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

produce velocità di trasmissione a nord di 800 Mbit, senza ritrasmissioni segnalate.

Il server viene sempre avviato utilizzando le seguenti opzioni:

iperf3 -sB192.168.30.161

Di chi è la colpa?

  1. La casella client linux (hardware? Driver? Impostazioni?)? Modifica: ho appena eseguito il test da una casella del server Windows all'altra e la perdita di pacchetti UDP a 300Mbit era ancora maggiore, al 22%
  2. Le finestre del server Windows (hardware? Driver? Impostazioni?)?
  3. L'interruttore (singolo) che collega tutte le macchine di prova?
  4. Cavi?

Modificare:

Ora ho provato nella direzione opposta: Windows -> Linux. Risultato: la perdita di pacchetti è sempre pari a 0 , mentre il throughput raggiunge il limite massimo

  • 840 Mbit per -l8192, cioè pacchetti IP frammentati
  • 250Mbit per -l1472pacchetti IP non frammentati

Immagino che il throughput dei limiti di controllo del flusso prevenga la perdita di pacchetti. Soprattutto quest'ultima cifra non frammentata non si avvicina affatto al throughput TCP (TCP non frammentato produce cifre simili al TCP frammentato), ma è un miglioramento infinitamente enorme rispetto a Linux -> Windows in termini di perdita di pacchetti.

E come scoprirlo?

Ho seguito i consueti consigli per le impostazioni del driver sul server per massimizzare le prestazioni e ho cercato di abilitare / disabilitare / massimizzare / minimizzare / cambiare

  • Interrompere la moderazione
  • Controllo del flusso
  • Buffer di ricezione
  • RSS
  • Wake-on-LAN

Tutte le funzionalità di offload sono abilitate.

Modifica Ho anche provato ad abilitare / disabilitare

  • Ethernet @ Wirespeed
  • Le varie funzionalità di offload
  • Priorità e VLAN

Con tassi di perdita simili.

L'output completo di un'esecuzione UDP:

$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522639.098587.3451f174
[  4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  33.3 MBytes   279 Mbits/sec  4262
[  4]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  4577
[  4]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec   176 MBytes   296 Mbits/sec  0.053 ms  3216/22571 (14%)
[  4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  27.2 MBytes   226 Mbits/sec  0.043 ms  781/4261 (18%)
[  5]   1.01-2.01   sec  30.0 MBytes   252 Mbits/sec  0.058 ms  734/4577 (16%)
[  5]   2.01-3.01   sec  29.0 MBytes   243 Mbits/sec  0.045 ms  870/4578 (19%)
[  5]   3.01-4.01   sec  32.1 MBytes   269 Mbits/sec  0.037 ms  469/4579 (10%)
[  5]   4.01-5.01   sec  32.9 MBytes   276 Mbits/sec  0.053 ms  362/4576 (7.9%)

Esecuzione TCP:

$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522833.505583.4078fcc1
      TCP MSS: 1448 (default)
[  4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   910 Mbits/sec    0   91.9 KBytes       
[  4]   1.00-2.00   sec  97.3 MBytes   816 Mbits/sec    0   91.9 KBytes       
[  4]   2.00-3.00   sec  97.5 MBytes   818 Mbits/sec    0   91.9 KBytes       
[  4]   3.00-4.00   sec  98.0 MBytes   822 Mbits/sec    0   91.9 KBytes       
[  4]   4.00-5.00   sec  97.6 MBytes   819 Mbits/sec    0   91.9 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   499 MBytes   837 Mbits/sec    0             sender
[  4]   0.00-5.00   sec   498 MBytes   836 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec  97.5 MBytes   818 Mbits/sec                  
[  5]   2.00-3.00   sec  97.6 MBytes   819 Mbits/sec                  
[  5]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec                  
[  5]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec
performance  tcp  udp  packetloss  iperf 
— Eugene Beresovsky
fonte

Risposte:

8

Non c'è problema. Questo è un comportamento normale e previsto.

Il motivo della perdita di pacchetti è che UDP non ha alcun controllo della congestione. In tcp quando gli algoritmi di controllo della congestione entrano in azione, dirà alla fine della trasmissione di rallentare l'invio al fine di massimizzare la produttività e minimizzare le perdite.

Quindi questo è un comportamento del tutto normale per UDP in realtà. UDP non garantisce la consegna se la coda di ricezione è sovraccarica e eliminerà i pacchetti. Se si desidera velocità di trasmissione più elevate per UDP, è necessario aumentare il buffer di ricezione.

L'opzione -l o --len iperf dovrebbe fare il trucco. E possibilmente l'impostazione di larghezza di banda di destinazione -b sul client.

-l, --len n [KM] imposta il buffer di lettura / scrittura della lunghezza su n (predefinito 8 KB)

8KB ?? questo è un po 'piccolo quando non c'è controllo della congestione.

ad es. sul lato server.

~$ iperf -l 1M -U -s

Questo è ciò che ottengo da Linux a Linux

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Ma per UDP usando le impostazioni predefinite ottengo solo

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT?

Dopo un po 'di sperimentazione ho scoperto che dovevo impostare sia la lunghezza che il target della larghezza di banda.

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

Lato server:

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

Per dimostrare la perdita di pacchetti con buffer di piccole dimensioni. Che a dire il vero non è così estremo come mi aspettavo. Dov'è una fonte affidabile per iperf3 che posso testare tra Linux / Windows?

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Lato server:

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Hai anche letto il readme della pagina github di iperf3 ?

Problemi noti

Prestazioni UDP: sono stati rilevati alcuni problemi con iperf3 sul banco di prova ESnet 100G a velocità UDP elevate (superiori a 10 Gbps). Il sintomo è che su ogni particolare corsa di iperf3 il ricevitore segnala un tasso di perdita di circa il 20%, indipendentemente dall'opzione -b utilizzata sul lato client. Questo problema sembra non essere specifico di iperf3 e potrebbe essere dovuto al posizionamento del processo iperf3 su una CPU e alla sua relazione con la scheda NIC in ingresso. In alcuni casi questo problema può essere mitigato da un uso appropriato dell'opzione affinità CPU (-A). (Numero 55)

Stai utilizzando una scheda di rete più lenta ma mi chiedo se sia correlata.

— opaco
fonte
Sì e per quanto riguarda la perdita di pacchetti, ti mostrerò come questo può accadere. risposta di aggiornamento.
— Matt,
Grazie Matt, ho appena visto il tuo aggiornamento. Il mio iperf (sia sul server Windows che sul client Linux) è la versione 2.0.5. Qual è il tuo?
— Eugene Beresovsky,
Lo stesso. E infatti quando imposto la larghezza di banda target su 1G ottengo un tasso di larghezza di banda bonkas di 14756449370562973696 byte / sec e altri output corrotti. Quindi penso che probabilmente sia rotto. Continuo a pensare che i problemi siano buffer ... So che Windows fa alcune cose insolite con il buffering TCP e UDP.
— Matt,
Strano. Più tardi oggi probabilmente avrò accesso a un buon ambiente di produzione 10G e lascerò perdere iperf3 su quello. Vediamo come va.
— Eugene Beresovsky
1
Penso che tu fraintenda cosa fa l' -linterruttore. Non imposta la dimensione del buffer; imposta la dimensione del pacchetto. Questa è la quantità di dati che iperf3 scriverà sul socket in una volta e letto dal socket in una volta. È possibile impostare la dimensione del buffer socket utilizzando -w. Se guardi l'origine, vedrai che chiama setsockopt()per impostare la dimensione del buffer socket su qualunque cosa tu abbia specificato in seguito -w.
— András Korn,
0

Ti sei completamente perso il colpevole più ovvio: gli adattatori e quindi i driver (affermi che l'utilizzo di una versione diversa dei driver produce risultati diversi).

Prova a disattivare tutte le funzionalità di offload.

— Dani_l
fonte
Ciò non ha aiutato - domanda aggiornata di conseguenza.
— Eugene Beresovsky,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.