Tasso di perdita di pacchetti con iperf e tcpdump

Ho testato una linea per la sua qualità di collegamento con iperf. La velocità misurata (porta UDP 9005) era di 96 Mbps, il che va bene, perché entrambi i server sono collegati a 100 Mbps a Internet. D'altra parte, il tasso di perdita del datagramma è stato mostrato essere del 3,3-3,7%, che ho trovato un po 'troppo. Usando un protocollo di trasferimento ad alta velocità ho registrato i pacchetti su entrambi i lati con tcpdump. Di quanto ho calcolato la perdita di pacchetti - media 0,25%. Qualcuno ha una spiegazione, da dove potrebbe venire questa grande differenza? Qual è una perdita accettabile di pacchetti secondo te?

Ho riscontrato una significativa perdita di dati con iPerf in modalità UDP a causa della mancata capacità della CPU di tenere il passo. Per qualche motivo, iPerf con UDP sembra richiedere molta più CPU rispetto a iPerf con TCP. Si verificano le stesse percentuali di perdita impostando iPerf a metà della tariffa?

Per rispondere alla tua seconda domanda su quanta perdita di pacchetti è accettabile, dipende davvero da quale applicazione stai eseguendo, da quanto traffico hai. Davvero, non ci dovrebbero essere perdite se si è sotto il limite di larghezza di banda. Per la maggior parte delle cose, probabilmente non mi lamenterei troppo del 0,25%, ma è comunque una grande perdita se corri a tassi molto alti.

[EDIT 1] Alcuni altri pensieri che ho avuto sull'argomento:

1. Prova ad aumentare le tariffe di iPerf. Se si verifica un problema sistemico da qualche parte, è probabile che si verifichi la stessa percentuale di perdita, indipendentemente dalla frequenza. Se sei ai limiti del tuo hardware, o il tuo provider fa una sorta di ROSSO , allora probabilmente non ci sarà alcuna perdita fino a un certo tasso, e quindi una perdita incrementale peggiore più in alto che vai.
2. Esegui la misurazione tcpdump della sessione iPerf, solo per verificare che i test siano accurati.
3. Prova iPerf con TCP. Questo non segnalerà la perdita, ma se si sta ottenendo una perdita, la connessione non sarà in grado di aumentare molto. Poiché anche la latenza influirà su questo, assicurarsi di eseguire il test su un endpoint con la minor latenza possibile.
4. A seconda dell'ingranaggio che hai all'interno della connessione, assicurati di essere il più vicino possibile. Ad esempio, se si dispone di più switch tra il sistema di test e il router perimetrale, passare a uno switch collegato direttamente.
5. Se hai un interruttore gestito, controlla le statistiche su di esso per assicurarti che la perdita non si verifichi lì. Ho riscontrato alcuni switch più economici che iniziano a cadere quando ci si avvicina a 100 Mbps di traffico UDP su di essi (principalmente switch non gestiti vecchi ed economici).
6. Prova simultaneamente iPerfs da due client diversi a due host diversi, in modo da essere sicuro che il limite non sia il risultato della CPU o di una scheda NIC locale economica.

Bene, con TCP ci sono meccanismi per massimizzare l'utilizzo di un flusso, con UDP no. Quindi ogni applicazione deve creare i propri meccanismi, quindi probabilmente ogni applicazione usa un approccio diverso per farlo. Probabilmente, Iperf consentirà di perdere più pacchetti perché sta cercando di raggiungere la massima larghezza di banda disponibile senza preoccuparsi se le informazioni vengono ricevute o meno. L'altra applicazione probabilmente proverà a non perdere molti pacchetti e ridurrà la velocità dei pacchetti alla velocità effettiva disponibile nella connessione.

Hai usato tcpdump per controllare la perdita di pacchetti quando usi iPerf per assicurarti che la perdita di pacchetti calcolata con tcpdump corrisponda a iperf?

Potresti scoprire che i tuoi metodi di misurazione non sono comparabili.

iperf scarta automaticamente i pacchetti che arrivano fuori sequenza con UDP? Potresti guardare un po 'di jitter sulla connessione.