Taux de perte de paquets avec iperf et tcpdump

J'ai testé une ligne pour sa qualité de lien avec iperf. La vitesse mesurée (port UDP 9005) était de 96 Mbps, ce qui est bien, car les deux serveurs sont connectés à 100 Mbps à Internet. D'un autre côté, le taux de perte de datagramme était de 3,3 à 3,7%, ce que j'ai trouvé un peu trop. En utilisant un protocole de transfert à haute vitesse, j'ai enregistré les paquets des deux côtés avec tcpdump. Que j'ai calculé la perte de paquets - 0,25% en moyenne. Quelqu'un a-t-il une explication sur l'origine de cette grande différence? Qu'est-ce qu'une perte de paquets acceptable à votre avis?

J'ai connu d'importantes pertes de données avec iPerf en mode UDP car le processeur ne pouvait pas suivre. Pour une raison quelconque, iPerf avec UDP semble être beaucoup plus gourmand en CPU que iPerf avec TCP. Connaissez-vous les mêmes pourcentages de perte lorsque vous réglez iPerf à la moitié du taux?

Pour répondre à votre deuxième question sur la quantité de perte de paquets acceptable, cela dépend vraiment de l'application que vous exécutez, du trafic dont vous disposez. Vraiment, il ne devrait y avoir aucune perte si vous êtes sous votre limite de bande passante. Pour la plupart des choses, je ne me plaindrais probablement pas trop de 0,25%, mais c'est toujours beaucoup de pertes si vous courez à des taux très élevés.

[EDIT 1] Quelques autres réflexions que j'ai eues sur le sujet:

1. Essayez d'augmenter les taux d'iPerf. S'il y a un problème systémique quelque part, il est probable que vous subirez le même pourcentage de perte quel que soit le taux. Si vous êtes aux limites de votre matériel ou si votre fournisseur fait une sorte de ROUGE , il n'y aura probablement aucune perte jusqu'à un certain taux, puis une perte incrémentielle pire au-dessus de ce que vous allez.
2. Faites votre mesure tcpdump de la session iPerf, juste pour vérifier que vos tests sont précis.
3. Essayez iPerf avec TCP. Cela ne signalera pas de perte, mais si vous obtenez une perte, la connexion ne pourra pas évoluer très haut. Étant donné que la latence affectera également cela, assurez-vous de tester un point final avec le moins de latence possible.
4. En fonction de l'équipement dont vous disposez à l'intérieur de votre connexion, assurez-vous de le rapprocher le plus possible. Par exemple, si vous avez plusieurs commutateurs entre votre système de test et le routeur périphérique, passez à un commutateur directement connecté.
5. Si vous avez un commutateur géré, vérifiez les statistiques dessus pour vous assurer que la perte ne s'y produit pas. J'ai rencontré des commutateurs moins chers qui commencent à tomber lorsque vous obtenez près de 100 Mbps de trafic UDP (surtout des commutateurs non gérés anciens et bon marché).
6. Essayez les iPerfs simultanés de deux clients différents vers deux hôtes différents, de sorte que vous puissiez être sûr que la limite n'est pas le résultat du processeur ou d'une carte NIC locale bon marché.

Eh bien, avec TCP, il existe des mécanismes pour maximiser l'utilisation d'un flux, avec UDP il n'y en a pas. Ainsi, chaque application doit créer ses propres mécanismes, donc probablement chaque application utilise une approche différente pour ce faire. Iperf autorisera probablement plus de paquets perdus car il essaie d'atteindre la bande passante disponible maximale sans se soucier de savoir si les informations sont reçues ou non. L'autre application essaiera probablement de ne pas perdre beaucoup de paquets et réduira le débit des paquets au débit disponible dans la connexion.

Avez-vous utilisé tcpdump pour vérifier la perte de paquets lorsque vous utilisez iPerf pour vous assurer que la perte de paquets que vous calculez avec tcpdump correspond à iperf?

Vous découvrirez peut-être que vos méthodes de mesure ne sont pas comparables.

iperf élimine-t-il automatiquement les paquets qui sortent de la séquence avec UDP? Vous regardez peut-être un peu de gigue sur la connexion.