Iperf: Valeurs négatives dans le rapport de perte avec UDP
# Le contexte
- Version d'iperf3: 3.7+
- Matériel: Intel
- Système d'exploitation: serveur Ubuntu14.04.6 fonctionnant sur VM (virtualBox 5.2.28)
# Rapport d'erreur
Vous avez un rapport avec des valeurs négatives dans les compteurs lost_packets et losr_percent dans le fichier journal côté serveur.
- Comportement prévisible:
{ "streams": [{ "socket": 6, "start": 19.000102, "end": 20.000105, "seconds": 1.0000029802322388, "bytes": 166520, "bits_per_second": 1332156.0298656528, "jitter_ms": 2.8512847190910904, "lost_packets": 0, "packets": 115, "lost_percent": 0, "omitted": false, "sender": false }], "sum": { "start": 19.000102, "end": 20.000105, "seconds": 1.0000029802322388, "bytes": 166520, "bits_per_second": 1332156.0298656528, "jitter_ms": 2.8512847190910904, "lost_packets": 0, "packets": 115, "lost_percent": 0, "omitted": false, "sender": false }
Le rapport de flux ci-dessus apparaît comme prévu dans le même fichier journal que le rapport de flux suivant (celui avec des valeurs négatives) Comportement réel
{ "streams": [{ "socket": 6, "start": 21.000194, "end": 22.000068, "seconds": 0.99987399578094482, "bytes": 372136, "bits_per_second": 2977463.1729218694, "jitter_ms": 2110.7105786449633, "lost_packets": -111, "packets": 146, "lost_percent": -76.027397260273972, "omitted": false, "sender": false }], "sum": { "start": 21.000194, "end": 22.000068, "seconds": 0.99987399578094482, "bytes": 372136, "bits_per_second": 2977463.1729218694, "jitter_ms": 2110.7105786449633, "lost_packets": -111, "packets": 146, "lost_percent": -76.027397260273972, "omitted": false, "sender": false }Étapes à suivre pour reproduire
côté serveur de commande: iperf3 -s -p 11002 -1 -J --logfile serverOut_11_to_2.json
commande côté client: iperf3 -c 10.0.0.2 -p 11002 -u -b 1675.289k -t 40 -J --logfile clientOut_11_to_2.json
J'ai reproduit plusieurs de ces tests entre différents hôtes et cela se produit au hasard, il est donc difficile à reproduire.
J'utilise Mininet 2.2.1 dans la VM pour déployer un réseau avec 23 nœuds et 36 liens.
Je génère des quantités spécifiques de trafic à partir des hôtes de mon réseau par rapport à une matrice de trafic (c'est pourquoi j'ai défini une valeur -b côté client). Je viens de me rendre compte de ce problème lors de l'analyse de tous les fichiers journaux. Que pourrais-je faire de mal? J'apprécierai votre aide. Merci!
danielaCasasv
Tous les 4 commentaires
Je suis d'accord que ces valeurs ne devraient pas être négatives! Pour le moment, je n'ai aucune idée de la façon dont ils sont arrivés de cette façon ... il ne semble pas que vous fassiez quelque chose de particulièrement inhabituel qui pourrait causer ce problème.
bmah888
le 18 oct. 2019
Salut,
Je constate également un comportement similaire lorsque des paquets perdus négatifs sont signalés. Comme l'affiche originale, cela n'arrive que sporadiquement. Je l'ai vu se présenter de deux manières différentes.
Installer:
- Nous utilisons une version iperf3 légèrement modifiée (basée sur la v3.5) afin que les résultats d'intervalle soient également jetés dans une base de données Mongo (vous verrez ci-dessous quelques indicateurs de commande supplémentaires pour prendre en charge cela), mais aucun code de trafic réel a été touché. Notre test a 32 paires client / serveur iperf3 simultanées exécutant le trafic udp entre 2 périphériques Linux (un Ubuntu 18.04 et un yocto). Je n'ai vu qu'une seule paire affectée à la fois, bien que la personne qui me l'a signalé ait dit avoir vu plusieurs paires affectées.
Cas 1:
- C'est le cas le plus courant. Le premier intervalle montre d'énormes valeurs de gigue, de paquets et de paquets perdus, mais un débit normal. Ensuite, tous les intervalles suivants auront zéro paquet et des valeurs négatives de paquet perdu (le débit et la gigue semblent normaux). Curieusement, la transposition de la valeur absolue des valeurs lostPacket / paquet fournirait le résultat attendu.
- Une gigue initiale élevée est évoquée dans le numéro 842, où la synchronisation NTP est mentionnée. Nous avons nos deux appareils synchronisés NTP et les 31 autres paires (sur les deux mêmes appareils) qui fonctionnent simultanément ne présentent pas le même problème.
Il y a une ligne dans iperf_api.c (ligne 2745 dans le dernier master) qui correspond au calcul des paquets perdus (cnt_error) dans un intervalle:
temp.interval_cnt_error = sp->cnt_error - irp->cnt_error;Je ne suis pas un programmeur C, donc je rapidement s'est perdu, mais je suppose que si pour une raison quelconque le cnt_error pour le flux était 0 et la valeur dans iperf_interval_results ne l'était pas, alors une valeur négative pourrait se produire. C'est peut-être juste une coïncidence, mais il semble étrange que les valeurs des paquets perdus (par exemple -170) soient les valeurs négatives que j'attendrais pour les paquets (par exemple 170).client iperf3 (ligne de commande et sortie):
iperf3 --octoerror --bind=192.168.222.202 --bitrate=2m --client=192.168.222.4 --connect-timeout=500 --dscp=0 --forceflush --interval=1 --mongo --parallel=1 --port=24731 --reverse --set-mss=8000 --time=32 --udp --window=2M
46:24.1: time: Thu, 31 Oct 2019 17:46:23 GMT timesecs: 1572543983 Client mode: connecting_to host: 192.168.222.4 port : 24731
46:24.1: Connecting to host 192.168.222.4, port 24731
46:24.1: Reverse mode, remote host 192.168.222.4 is sending
46:24.9: [ 8] local 192.168.222.202 port 34524 connected to 192.168.222.4 port 24731
46:24.9: protocol: UDP num_streams: 1 blksize: 1448 omit: 0 duration: 32 bytes: 0 blocks: 0 reverse: 1
46:24.9: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
46:24.9: [ 8] 0.00-1.00 sec 246 KBytes 2.02 Mbits/sec 2567541.936 ms 393365/393539 (1e+02%)
46:26.0: [ 8] 1.00-2.00 sec 240 KBytes 1.97 Mbits/sec 49.376 ms -170/0 (0%)
46:26.4: [ 8] 2.00-3.00 sec 247 KBytes 2.03 Mbits/sec 4.897 ms -175/0 (0%)
46:27.4: [ 8] 3.00-4.00 sec 245 KBytes 2.00 Mbits/sec 4.799 ms -173/0 (0%)
46:28.4: [ 8] 4.00-5.00 sec 243 KBytes 1.99 Mbits/sec 5.500 ms -172/0 (0%)
46:29.4: [ 8] 5.00-6.00 sec 246 KBytes 2.02 Mbits/sec 4.971 ms -174/0 (0%)
46:30.4: [ 8] 6.00-7.00 sec 242 KBytes 1.98 Mbits/sec 5.427 ms -171/0 (0%)
46:31.4: [ 8] 7.00-8.00 sec 246 KBytes 2.02 Mbits/sec 5.356 ms -174/0 (0%)
46:32.4: [ 8] 8.00-9.00 sec 243 KBytes 1.99 Mbits/sec 5.389 ms -172/0 (0%)
46:33.4: [ 8] 9.00-10.00 sec 246 KBytes 2.02 Mbits/sec 5.580 ms -174/0 (0%)
46:34.4: [ 8] 10.00-11.00 sec 243 KBytes 1.99 Mbits/sec 5.046 ms -172/0 (0%)
46:35.4: [ 8] 11.00-12.00 sec 243 KBytes 1.99 Mbits/sec 5.526 ms -172/0 (0%)
46:36.4: [ 8] 12.00-13.00 sec 243 KBytes 1.99 Mbits/sec 4.986 ms -172/0 (0%)
46:37.4: [ 8] 13.00-14.00 sec 246 KBytes 2.02 Mbits/sec 4.939 ms -174/0 (0%)
46:38.4: [ 8] 14.00-15.00 sec 245 KBytes 2.00 Mbits/sec 6.100 ms -173/0 (0%)
46:39.4: [ 8] 15.00-16.00 sec 243 KBytes 1.99 Mbits/sec 5.215 ms -172/0 (0%)
46:40.4: [ 8] 16.00-17.00 sec 245 KBytes 2.00 Mbits/sec 5.513 ms -173/0 (0%)
46:41.4: [ 8] 17.00-18.00 sec 243 KBytes 1.99 Mbits/sec 5.874 ms -172/0 (0%)
46:42.4: [ 8] 18.00-19.00 sec 242 KBytes 1.98 Mbits/sec 5.172 ms -171/0 (0%)
46:43.4: [ 8] 19.00-20.00 sec 247 KBytes 2.03 Mbits/sec 5.680 ms -175/0 (0%)
46:44.4: [ 8] 20.00-21.00 sec 242 KBytes 1.98 Mbits/sec 5.185 ms -171/0 (0%)
46:45.4: [ 8] 21.00-22.00 sec 245 KBytes 2.00 Mbits/sec 4.800 ms -173/0 (0%)
46:46.4: [ 8] 22.00-23.00 sec 245 KBytes 2.00 Mbits/sec 4.909 ms -173/0 (0%)
46:47.4: [ 8] 23.00-24.00 sec 245 KBytes 2.00 Mbits/sec 4.643 ms -173/0 (0%)
46:48.4: [ 8] 24.00-25.00 sec 245 KBytes 2.00 Mbits/sec 5.953 ms -173/0 (0%)
46:49.4: [ 8] 25.00-26.00 sec 243 KBytes 1.99 Mbits/sec 5.300 ms -172/0 (0%)
46:50.4: [ 8] 26.00-27.00 sec 246 KBytes 2.02 Mbits/sec 5.048 ms -174/0 (0%)
46:51.4: [ 8] 27.00-28.00 sec 245 KBytes 2.00 Mbits/sec 5.019 ms -173/0 (0%)
46:52.4: [ 8] 28.00-29.00 sec 243 KBytes 1.99 Mbits/sec 5.198 ms -172/0 (0%)
46:53.4: [ 8] 29.00-30.00 sec 243 KBytes 1.99 Mbits/sec 5.016 ms -172/0 (0%)
46:54.4: [ 8] 30.00-31.00 sec 243 KBytes 1.99 Mbits/sec 5.106 ms -172/0 (0%)
46:55.7: [ 8] 31.00-32.00 sec 245 KBytes 2.00 Mbits/sec 3.244 ms -173/0 (0%)
46:55.7: - - - - - - - - - - - - - - - - - - - - - - - - -
46:55.7: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
46:55.7: [ 8] 0.00-32.02 sec 7.64 MBytes 2.00 Mbits/sec 0.000 ms 0/5529 (0%) sender
46:55.7: [SUM] 0.0-32.0 sec 5525 datagrams received out-of-order
46:55.7: [ 8] 0.00-32.00 sec 7.63 MBytes 2.00 Mbits/sec 3.244 ms 388013/393539 (99%) receiver
- serveur iperf3 (ligne de commande et sortie):
iperf3 --octoerror --bind=192.168.222.4 --forceflush --interval=1 --port=24731 --server
46:15.4: -----------------------------------------------------------
46:15.4: Server listening on 24731
46:15.4: -----------------------------------------------------------
46:23.3: time: Thu, 31 Oct 2019 17:46:23 GMT timesecs: 1572543983 Server mode: accepted_connection host: 192.168.222.202 port: 33344
46:23.3: Accepted connection from 192.168.222.202, port 33344
46:24.3: [ 7] local 192.168.222.4 port 24731 connected to 192.168.222.202 port 34524
46:24.3: protocol: UDP num_streams: 1 blksize: 1448 omit: 0 duration: 32 bytes: 0 blocks: 0 reverse: 1
46:24.3: [ ID] Interval Transfer Bitrate Total Datagrams
46:24.3: [ 7] 0.00-1.00 sec 245 KBytes 2.00 Mbits/sec 173
46:25.3: [ 7] 1.00-2.00 sec 245 KBytes 2.00 Mbits/sec 173
46:26.3: [ 7] 2.00-3.00 sec 243 KBytes 1.99 Mbits/sec 172
46:27.3: [ 7] 3.00-4.00 sec 245 KBytes 2.00 Mbits/sec 173
46:28.3: [ 7] 4.00-5.00 sec 245 KBytes 2.00 Mbits/sec 173
46:29.3: [ 7] 5.00-6.00 sec 243 KBytes 1.99 Mbits/sec 172
46:30.3: [ 7] 6.00-7.00 sec 245 KBytes 2.00 Mbits/sec 173
46:31.3: [ 7] 7.00-8.00 sec 245 KBytes 2.00 Mbits/sec 173
46:32.3: [ 7] 8.00-9.00 sec 243 KBytes 1.99 Mbits/sec 172
46:33.3: [ 7] 9.00-10.00 sec 245 KBytes 2.00 Mbits/sec 173
46:34.3: [ 7] 10.00-11.00 sec 245 KBytes 2.00 Mbits/sec 173
46:35.3: [ 7] 11.00-12.00 sec 243 KBytes 1.99 Mbits/sec 172
46:36.3: [ 7] 12.00-13.00 sec 245 KBytes 2.00 Mbits/sec 173
46:37.3: [ 7] 13.00-14.00 sec 243 KBytes 1.99 Mbits/sec 172
46:38.3: [ 7] 14.00-15.00 sec 245 KBytes 2.00 Mbits/sec 173
46:39.3: [ 7] 15.00-16.00 sec 245 KBytes 2.00 Mbits/sec 173
46:40.3: [ 7] 16.00-17.00 sec 243 KBytes 1.99 Mbits/sec 172
46:41.3: [ 7] 17.00-18.00 sec 245 KBytes 2.00 Mbits/sec 173
46:42.3: [ 7] 18.00-19.00 sec 245 KBytes 2.00 Mbits/sec 173
46:43.3: [ 7] 19.00-20.00 sec 243 KBytes 1.99 Mbits/sec 172
46:44.3: [ 7] 20.00-21.00 sec 245 KBytes 2.00 Mbits/sec 173
46:45.3: [ 7] 21.00-22.00 sec 245 KBytes 2.00 Mbits/sec 173
46:46.3: [ 7] 22.00-23.00 sec 243 KBytes 1.99 Mbits/sec 172
46:47.3: [ 7] 23.00-24.00 sec 245 KBytes 2.00 Mbits/sec 173
46:48.3: [ 7] 24.00-25.00 sec 245 KBytes 2.00 Mbits/sec 173
46:49.3: [ 7] 25.00-26.00 sec 243 KBytes 1.99 Mbits/sec 172
46:50.3: [ 7] 26.00-27.00 sec 245 KBytes 2.00 Mbits/sec 173
46:51.3: [ 7] 27.00-28.00 sec 245 KBytes 2.00 Mbits/sec 173
46:52.3: [ 7] 28.00-29.00 sec 243 KBytes 1.99 Mbits/sec 172
46:53.3: [ 7] 29.00-30.00 sec 245 KBytes 2.00 Mbits/sec 173
46:54.3: [ 7] 30.00-31.00 sec 245 KBytes 2.00 Mbits/sec 173
46:55.3: [ 7] 31.00-32.00 sec 243 KBytes 1.99 Mbits/sec 172
46:55.4: [ 7] 32.00-32.02 sec 5.66 KBytes 2.38 Mbits/sec 4
46:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
46:55.4: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
46:55.4: [ 7] 0.00-32.02 sec 7.64 MBytes 2.00 Mbits/sec 0.000 ms 0/5529 (0%) sender
Cas 2:
Je n'ai vu cela qu'une seule fois jusqu'à présent. Le test semble se dérouler normalement, mais le dernier intervalle a une valeur de paquet perdu négative (sinon tout le reste semble correct (c'est-à-dire pas de paquets zéro ou de valeurs enrichies)).
client iperf3 (ligne de commande et sortie):
iperf3 --octoerror --bind=192.168.222.202 --bitrate=2m --client=192.168.222.4 --connect-timeout=500 --dscp=0 --forceflush --interval=1 --mongo --parallel=1 --port=14069 --reverse --set-mss=8000 --time=32 --udp --window=2M
41:23.9: time: Thu, 31 Oct 2019 15:41:23 GMT timesecs: 1572536483 Client mode: connecting_to host: 192.168.222.4 port : 14069
41:23.9: Connecting to host 192.168.222.4, port 14069
41:23.9: Reverse mode, remote host 192.168.222.4 is sending
41:24.9: [ 8] local 192.168.222.202 port 49732 connected to 192.168.222.4 port 14069
41:24.9: protocol: UDP num_streams: 1 blksize: 1448 omit: 0 duration: 32 bytes: 0 blocks: 0 reverse: 1
41:24.9: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
41:24.9: [ 8] 0.00-1.00 sec 245 KBytes 2.00 Mbits/sec 5.052 ms 0/173 (0%)
41:25.7: [ 8] 1.00-2.00 sec 243 KBytes 1.99 Mbits/sec 4.923 ms 0/172 (0%)
41:26.8: [ 8] 2.00-3.00 sec 245 KBytes 2.00 Mbits/sec 5.997 ms 0/173 (0%)
41:27.4: [ 8] 3.00-4.00 sec 243 KBytes 1.99 Mbits/sec 6.019 ms 0/172 (0%)
41:28.4: [ 8] 4.00-5.00 sec 245 KBytes 2.00 Mbits/sec 4.799 ms 0/173 (0%)
41:29.4: [ 8] 5.00-6.00 sec 245 KBytes 2.00 Mbits/sec 6.097 ms 0/173 (0%)
41:30.4: [ 8] 6.00-7.00 sec 245 KBytes 2.00 Mbits/sec 5.287 ms 0/173 (0%)
41:31.4: [ 8] 7.00-8.00 sec 245 KBytes 2.00 Mbits/sec 5.652 ms 0/173 (0%)
41:32.4: [ 8] 8.00-9.00 sec 243 KBytes 1.99 Mbits/sec 4.803 ms 0/172 (0%)
41:33.4: [ 8] 9.00-10.00 sec 246 KBytes 2.02 Mbits/sec 5.248 ms 0/174 (0%)
41:34.4: [ 8] 10.00-11.00 sec 243 KBytes 1.99 Mbits/sec 5.175 ms 0/172 (0%)
41:35.4: [ 8] 11.00-12.00 sec 245 KBytes 2.00 Mbits/sec 4.627 ms 0/173 (0%)
41:36.4: [ 8] 12.00-13.00 sec 242 KBytes 1.98 Mbits/sec 5.089 ms 0/171 (0%)
41:37.4: [ 8] 13.00-14.00 sec 247 KBytes 2.03 Mbits/sec 5.438 ms 0/175 (0%)
41:38.4: [ 8] 14.00-15.00 sec 240 KBytes 1.97 Mbits/sec 5.313 ms 0/170 (0%)
41:39.4: [ 8] 15.00-16.00 sec 246 KBytes 2.02 Mbits/sec 5.015 ms 0/174 (0%)
41:40.4: [ 8] 16.00-17.00 sec 243 KBytes 1.99 Mbits/sec 5.195 ms 0/172 (0%)
41:41.4: [ 8] 17.00-18.00 sec 246 KBytes 2.02 Mbits/sec 5.085 ms 0/174 (0%)
41:42.4: [ 8] 18.00-19.00 sec 243 KBytes 1.99 Mbits/sec 7.104 ms 0/172 (0%)
41:43.4: [ 8] 19.00-20.00 sec 245 KBytes 2.00 Mbits/sec 5.546 ms 0/173 (0%)
41:44.4: [ 8] 20.00-21.00 sec 243 KBytes 1.99 Mbits/sec 5.211 ms 0/172 (0%)
41:45.4: [ 8] 21.00-22.00 sec 245 KBytes 2.00 Mbits/sec 4.971 ms 0/173 (0%)
41:46.4: [ 8] 22.00-23.00 sec 245 KBytes 2.00 Mbits/sec 4.990 ms 0/173 (0%)
41:47.4: [ 8] 23.00-24.00 sec 240 KBytes 1.97 Mbits/sec 5.803 ms 0/170 (0%)
41:48.4: [ 8] 24.00-25.00 sec 246 KBytes 2.02 Mbits/sec 6.120 ms 0/174 (0%)
41:49.4: [ 8] 25.00-26.00 sec 246 KBytes 2.02 Mbits/sec 5.042 ms 0/174 (0%)
41:50.4: [ 8] 26.00-27.00 sec 243 KBytes 1.99 Mbits/sec 5.061 ms 0/172 (0%)
41:51.4: [ 8] 27.00-28.00 sec 243 KBytes 1.99 Mbits/sec 5.063 ms 0/172 (0%)
41:52.4: [ 8] 28.00-29.00 sec 246 KBytes 2.02 Mbits/sec 4.918 ms 0/174 (0%)
41:53.4: [ 8] 29.00-30.00 sec 243 KBytes 1.99 Mbits/sec 5.847 ms 0/172 (0%)
41:54.4: [ 8] 30.00-31.00 sec 242 KBytes 1.98 Mbits/sec 4.966 ms 2/173 (1.2%)
41:55.4: [ 8] 31.00-32.00 sec 247 KBytes 2.03 Mbits/sec 5.648 ms -2/173 (-1.2%)
41:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
41:55.4: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
41:55.4: [ 8] 0.00-32.01 sec 7.63 MBytes 2.00 Mbits/sec 0.000 ms 0/5527 (0%) sender
41:55.4: [SUM] 0.0-32.0 sec 13 datagrams received out-of-order
41:55.4: [ 8] 0.00-32.00 sec 7.63 MBytes 2.00 Mbits/sec 5.648 ms 0/5526 (0%) receiver
- serveur iperf3 (ligne de commande et sortie):
iperf3 --octoerror --bind=192.168.222.4 --forceflush --interval=1 --port=14069 --server
41:23.4: time: Thu, 31 Oct 2019 15:41:23 GMT timesecs: 1572536483 Server mode: accepted_connection host: 192.168.222.202 port: 40600
41:23.4: Accepted connection from 192.168.222.202, port 40600
41:24.4: [ 7] local 192.168.222.4 port 14069 connected to 192.168.222.202 port 49732
41:24.4: protocol: UDP num_streams: 1 blksize: 1448 omit: 0 duration: 32 bytes: 0 blocks: 0 reverse: 1
41:24.4: [ ID] Interval Transfer Bitrate Total Datagrams
41:24.4: [ 7] 0.00-1.00 sec 245 KBytes 2.00 Mbits/sec 173
41:25.4: [ 7] 1.00-2.00 sec 245 KBytes 2.00 Mbits/sec 173
41:26.4: [ 7] 2.00-3.00 sec 243 KBytes 1.99 Mbits/sec 172
41:27.4: [ 7] 3.00-4.00 sec 245 KBytes 2.00 Mbits/sec 173
41:28.4: [ 7] 4.00-5.00 sec 245 KBytes 2.00 Mbits/sec 173
41:29.4: [ 7] 5.00-6.00 sec 243 KBytes 1.99 Mbits/sec 172
41:30.4: [ 7] 6.00-7.00 sec 245 KBytes 2.00 Mbits/sec 173
41:31.4: [ 7] 7.00-8.00 sec 245 KBytes 2.00 Mbits/sec 173
41:32.4: [ 7] 8.00-9.00 sec 243 KBytes 1.99 Mbits/sec 172
41:33.4: [ 7] 9.00-10.00 sec 245 KBytes 2.00 Mbits/sec 173
41:34.4: [ 7] 10.00-11.00 sec 245 KBytes 2.00 Mbits/sec 173
41:35.4: [ 7] 11.00-12.00 sec 243 KBytes 1.99 Mbits/sec 172
41:36.4: [ 7] 12.00-13.00 sec 245 KBytes 2.00 Mbits/sec 173
41:37.4: [ 7] 13.00-14.00 sec 243 KBytes 1.99 Mbits/sec 172
41:38.4: [ 7] 14.00-15.00 sec 245 KBytes 2.00 Mbits/sec 173
41:39.4: [ 7] 15.00-16.00 sec 245 KBytes 2.00 Mbits/sec 173
41:40.4: [ 7] 16.00-17.00 sec 243 KBytes 1.99 Mbits/sec 172
41:41.4: [ 7] 17.00-18.00 sec 245 KBytes 2.00 Mbits/sec 173
41:42.4: [ 7] 18.00-19.00 sec 245 KBytes 2.00 Mbits/sec 173
41:43.4: [ 7] 19.00-20.00 sec 243 KBytes 1.99 Mbits/sec 172
41:44.4: [ 7] 20.00-21.00 sec 245 KBytes 2.00 Mbits/sec 173
41:45.4: [ 7] 21.00-22.00 sec 245 KBytes 2.00 Mbits/sec 173
41:46.4: [ 7] 22.00-23.00 sec 243 KBytes 1.99 Mbits/sec 172
41:47.4: [ 7] 23.00-24.00 sec 245 KBytes 2.00 Mbits/sec 173
41:48.4: [ 7] 24.00-25.00 sec 245 KBytes 2.00 Mbits/sec 173
41:49.4: [ 7] 25.00-26.00 sec 243 KBytes 1.99 Mbits/sec 172
41:50.4: [ 7] 26.00-27.00 sec 245 KBytes 2.00 Mbits/sec 173
41:51.4: [ 7] 27.00-28.00 sec 245 KBytes 2.00 Mbits/sec 173
41:52.4: [ 7] 28.00-29.00 sec 243 KBytes 1.99 Mbits/sec 172
41:53.4: [ 7] 29.00-30.00 sec 245 KBytes 2.00 Mbits/sec 173
41:54.4: [ 7] 30.00-31.00 sec 245 KBytes 2.00 Mbits/sec 173
41:55.4: [ 7] 31.00-32.00 sec 243 KBytes 1.99 Mbits/sec 172
41:55.4: [ 7] 32.00-32.01 sec 2.83 KBytes 2.59 Mbits/sec 2
41:55.4: - - - - - - - - - - - - - - - - - - - - - - - - -
41:55.4: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
41:55.4: [ 7] 0.00-32.01 sec 7.63 MBytes 2.00 Mbits/sec 0.000 ms 0/5527 (0%) sender
41:55.4: iperf test finished.
41:55.4: -----------------------------------------------------------
41:55.4: Server listening on 14069
41:55.4: -----------------------------------------------------------
dmozzoni
le 1 nov. 2019
Salut les gars, avez-vous surmonté ce problème?
Je rencontre un problème similaire, je ne sais pas ce que cela signifie.
Accepted connection from 172.16.0.1, port 48634
[ 5] local 172.16.0.3 port 5201 connected to 172.16.0.1 port 42108
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 4.53 MBytes 38.0 Mbits/sec 0.060 ms -1931109556/-1931109555 (0%)
[ 5] 1.00-2.00 sec 4.77 MBytes 40.0 Mbits/sec 0.084 ms 0/0 (0%)
[ 5] 2.00-3.00 sec 4.77 MBytes 40.0 Mbits/sec 0.133 ms 0/0 (0%)
[ 5] 3.00-4.00 sec 4.76 MBytes 40.0 Mbits/sec 0.048 ms 0/0 (0%)
[ 5] 4.00-5.00 sec 4.56 MBytes 38.2 Mbits/sec 0.277 ms 0/0 (0%)
[ 5] 5.00-6.00 sec 4.80 MBytes 40.3 Mbits/sec 0.093 ms 0/0 (0%)
[ 5] 6.00-7.00 sec 4.54 MBytes 38.1 Mbits/sec 0.116 ms 0/0 (0%)
[ 5] 7.00-8.00 sec 4.77 MBytes 40.0 Mbits/sec 0.044 ms 0/0 (0%)
[ 5] 8.00-9.00 sec 4.77 MBytes 40.0 Mbits/sec 0.059 ms 0/0 (0%)
[ 5] 9.00-10.00 sec 4.38 MBytes 36.7 Mbits/sec 0.175 ms 0/0 (0%)
[ 5] 10.00-10.05 sec 119 KBytes 19.8 Mbits/sec 0.155 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[SUM] 0.0-10.0 sec 34730 datagrams received out-of-order
[ 5] 0.00-10.05 sec 46.8 MBytes 39.0 Mbits/sec 0.155 ms -1931109556/-1931109555 (0%) receiver
(reformaté pour plus de clarté)
Carlitops
le 6 févr. 2020
Salut,
La valeur négative des paquets perdus semble généralement correcte. Cela signifie que les paquets qui ont été considérés comme perdus dans les intervalles précédents ont été reçus. Par exemple, dans le cas suivant donné ci-dessus:
41:54.4: [ 8] 30.00-31.00 sec 242 KBytes 1.98 Mbits/sec 4.966 ms 2/173 (1.2%)
41:55.4: [ 8] 31.00-32.00 sec 247 KBytes 2.03 Mbits/sec 5.648 ms -2/173 (-1.2%)
Les -2 paquets perdus signifient que les deux paquets perdus dans l'intervalle 30,00-31,00 ont été reçus dans l'intervalle 31,00-32,00.
Le total réel des paquets reçus dans l'intervalle est donc "Total" - "Perdu" (par exemple 173 - (- 2) = 175 paquets ont été reçus dans l'intervalle 31.00-32.00)
Pour le cas d'origine publié, il manque des données concernant l'intervalle 20.000105-21.000194. Comme dans l'intervalle 21.000194-22.000068, 146 - (- 111) = 257 paquets ont été reçus, il semble qu'il y ait eu une mise en mémoire tampon sérieuse du réseau et une réorganisation dans l'intervalle 20.000105-21.000194, ce qui a provoqué l'arrivée d'un paquet avant 111 paquets précédents, et le 111 les paquets ne sont arrivés que pendant l'intervalle suivant.
Il semble que le principal problème est que parfois le premier paquet est reçu avec un nombre de paquets brouillé ou est reçu tronqué, de sorte que le compteur de paquets est brouillé. Par exemple dans:
46:24.9: [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
46:24.9: [ 8] 0.00-1.00 sec 246 KBytes 2.02 Mbits/sec 2567541.936 ms 393365/393539 (1e+02%)
il y avait probablement un problème avec le premier paquet supposé être reçu, donc son nombre de paquets brouillé était de 393539. En pratique, 393539-393365 = 174 paquets ont été reçus dans le premier intervalle. Tous les intervalles suivants montrent un nombre négatif de paquets perdus, puisque chaque paquet reçu est considéré comme une récupération du paquet perdu à partir du premier intervalle, jusqu'à ce que plus de 393539 paquets soient reçus.
Plus tard, j'enverrai une demande de tirage avec des modifications suggérées pour éviter d'utiliser un compteur de paquets brouillé.
davidBar-On
le 25 févr. 2020
Questions connexes
ili101
·
4Commentaires
smcifrankp
·
4Commentaires
arainero
·
3Commentaires
bmah888
·
7Commentaires
KevinJosephMorin
·
5Commentaires
Commentaire le plus utile
Salut,
La valeur négative des paquets perdus semble généralement correcte. Cela signifie que les paquets qui ont été considérés comme perdus dans les intervalles précédents ont été reçus. Par exemple, dans le cas suivant donné ci-dessus:
Les -2 paquets perdus signifient que les deux paquets perdus dans l'intervalle 30,00-31,00 ont été reçus dans l'intervalle 31,00-32,00.
Le total réel des paquets reçus dans l'intervalle est donc "Total" - "Perdu" (par exemple 173 - (- 2) = 175 paquets ont été reçus dans l'intervalle 31.00-32.00)
Pour le cas d'origine publié, il manque des données concernant l'intervalle 20.000105-21.000194. Comme dans l'intervalle 21.000194-22.000068, 146 - (- 111) = 257 paquets ont été reçus, il semble qu'il y ait eu une mise en mémoire tampon sérieuse du réseau et une réorganisation dans l'intervalle 20.000105-21.000194, ce qui a provoqué l'arrivée d'un paquet avant 111 paquets précédents, et le 111 les paquets ne sont arrivés que pendant l'intervalle suivant.
Il semble que le principal problème est que parfois le premier paquet est reçu avec un nombre de paquets brouillé ou est reçu tronqué, de sorte que le compteur de paquets est brouillé. Par exemple dans:
il y avait probablement un problème avec le premier paquet supposé être reçu, donc son nombre de paquets brouillé était de 393539. En pratique, 393539-393365 = 174 paquets ont été reçus dans le premier intervalle. Tous les intervalles suivants montrent un nombre négatif de paquets perdus, puisque chaque paquet reçu est considéré comme une récupération du paquet perdu à partir du premier intervalle, jusqu'à ce que plus de 393539 paquets soient reçus.
Plus tard, j'enverrai une demande de tirage avec des modifications suggérées pour éviter d'utiliser un compteur de paquets brouillé.