Iperf: Bande passante de récepteur manquante en sortie JSON pour UDP

Droite. C'est un bogue très ancien, qui aurait pu être présent dans iperf3 depuis le début. Je l'ai en quelque sorte réalisé (pourquoi n'ai-je pas signalé un problème?) Lorsque je faisais le travail sur # 562. Comme vous l'avez correctement souligné, les tests UDP ne séparent pas les statistiques côté client et côté récepteur séparément. Je ne sais pas si ce qui est signalé est le client, l'expéditeur ou un méli-mélo des deux. Je ne vois pas non plus pourquoi TCP est différent.

Ce serait une bonne chose si les tests UDP pouvaient émettre des statistiques qui ressemblent plus à TCP à cet égard (à la fois côté expéditeur et côté récepteur séparément), bien que je ne sache pas comment maintenir une sorte de compatibilité avec les programmes qui consomment le JSON existant. production. (Dans # 562, j'ai corrigé la sortie lisible par l'homme pour UDP, que vous avez présentée dans votre premier extrait de sortie ... J'étais moins inquiet de la compatibilité descendante dans ce cas parce que les programmes ne devraient pas essayer de lire cette sortie de toute façon.)

Y a-t-il une solution à ce problème pour la sortie JSON UDP? Nous essayons d'analyser la sortie JSON mais nous ne savons pas ce qui est quoi. Un exemple de sortie JSON est: -

    }],
            "sum":  {
                    "start":        0,
                    "end":  10.004644870758057,
                    "seconds":      10.004644870758057,
                    **"bytes":        4364528380,**
                    "bits_per_second":      3484585580.8672519,
                    "jitter_ms":    2.3222640079292773,
                    "lost_packets": 2102766,
                    "packets":      2989403,
                    "lost_percent": 70.34066668160834
            },

mais nous ne sommes pas sûrs de ce qu'est cette chose d'octets, est-ce que c'est des octets envoyés ou des octets reçus?

Quand sera-t-il réparé? J'ai besoin d'obtenir les bps du récepteur à partir de la sortie JSON.

Peut-être y a-t-il une solution de contournement?

Ce n'est pas sur la feuille de route pour le moment. La résolution de cela nécessite en fait une modification de la machine d'état et du protocole entre le client et le serveur.

Puis-je demander ... Si je teste avec UDP et j'analyse le json du côté client et j'obtiens

end.sum.bits_per_second     AND 
end.sum.lost_packets

Vais-je avoir une représentation juste pour savoir si la transmission envoie et reçoit des données du côté serveur? Que dois-je faire pour vérifier que l'envoi / la réception dans les deux sens a réussi? Analysez la sortie de texte à partir de:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.000 ms  0/81 (0%)  sender
[  5]   0.00-10.00  sec  1.26 MBytes  1.06 Mbits/sec  0.052 ms  0/81 (0%)  receiver

@awardblvr : Cela dépend, je suppose, de la façon dont vous définissez «réussi». Je suppose qu'une mesure pourrait être que si end.sum.lost_packets est égal à zéro, le récepteur n'a détecté aucun paquet perdu. Cependant, il existe des cas extrêmes autour de cela, principalement liés à ce qui arrive aux paquets qui sont encore en vol lorsque le client déclare le test terminé.

Merci ..., je veux seulement savoir que je peux lire cette sortie ONE json et voir
Fondamentalement, les paquets transférés du serveur -> client et les paquets
transmis du client -> le serveur est arrivé et qu'il n'y a pas eu de perte
paquets sur les paquets reçus par le client:

Je crois que c'est:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- NEW avec PATCH
end.sum_receiver.lost_packets <--- NEW avec PATCH

S'il vous plait corrigez moi si je me trompe!

"finir": {
"somme": {
"fin": 10h00,
"secondes": 10,00,
"bits_par_seconde": 1058280.26,
"octets": 1322892,
"paquets": 81,
"start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
},
"ruisseaux": [
{
"udp": {
"fin": 10h00,
"prise": 5,
"secondes": 10,00,
"bits_par_seconde": 1058280.26,
"octets": 1322892,
"paquets": 81,
"out_of_order": 0,
"start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
}
}
],
"sum_sender": {<--- NEW avec PATCH
"fin": 10h00,
"secondes": 10,00,
"bits_par_seconde": 1058280.26,
"octets": 1322892,
"paquets": 81,
"start": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": {<--- NEW avec PATCH
"fin": 10h00,
"secondes": 10,00,
"bits_par_seconde": 1058271.16,
"octets": 1322892,
"paquets": 81,
"start": 0,
"jitter_ms": 0,0568,
"lost_packets": 0,
"lost_percent": 0
}

Merci

-UNE

Le jeu 13 septembre 2018 à 10 h 04 Bruce A. Mah [email protected]
a écrit:

@awardblvr https://github.com/awardblvr : Cela dépend je suppose de la façon dont vous
définir "réussi". Je suppose qu'une mesure pourrait être que si
end.sum.lost_packets vaut zéro, alors le récepteur n'a détecté aucune perte
paquets. Cependant, il y a des cas extrêmes autour de cela, la plupart du temps devant faire
avec ce qui arrive aux paquets qui sont encore en vol lorsque le client
déclare le test terminé.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Rencontré un problème similaire avec le manque de Tx / Rx B / W indépendants pour UDP.
A adopté une approche différente.

J'ai calculé RxMbps en utilisant le TxRate et Drop%.

TxMbps = result.Mbps
RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100))

Serveur --- 10Mbps --- SRX (routeur) --- 5Mbps ----- Client
(Traffic shapers appliqués sur les interfaces SRX)

Je teste les deux sens à 20 Mbps.

Téléchargement UDP iPerf3:

Télécommande: 10.8.8.100
Local: 10.9.9.222
Protocole / Port: UDP / 33333
Heure de début: dim, 10 janvier 2021 03:51:23 GMT
Durée (sec): 10
Taux de transmission: 20,0 Mbps
Taux de réception: 9,58 Mbps
Gigue: 0,7 ms
Paquets perdus: 8990
Pourcentage de perte: 52,07%
Processeur local: 9,03%
CPU à distance: 0,76%

Téléchargement de iPerf3 UDP:

Télécommande: 10.8.8.100
Local: 10.9.9.222
Protocole / Port: UDP / 33333
Heure de début: dim, 10 janvier 2021 03:51:38 GMT
Durée (sec): 10
Taux de transmission: 20,0 Mbps
Taux de réception: 4,82 Mbps
Gigue: 0,49 ms
Paquets perdus: 13172
Pourcentage de perte: 75,9%
Processeur local: 2,5%
CPU à distance: 8,26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" ne fonctionnera probablement pas en général. En effet, les données sont collectées uniquement localement et pas également à partir de l'extrémité distante. Par exemple, dans les données que vous avez envoyées, la bande passante du lien de bout en bout entre le serveur et le client est de 5 Mbps. Cependant, en supposant que le téléchargement est de serveur à client, vous obtenez 10 Mbps sur le serveur. Cela est dû au fait qu'il s'agit de la mesure du débit du serveur par rapport à SRX et non de bout en bout.

@ bmah888 , étant donné que les données du serveur peuvent être reçues à l'aide de --server-output , l'approche suivante peut être utilisée comme solution / contournement pour le problème des statistiques récapitulatives JSON UDP:

1. Les sections JSON "_sum_received_" et "_sum_sent_" seront ajoutées au résumé UDP _end_ sur le serveur et le client. Cette section ne remplacera
2. Le "_sum_received_" inclura des données non nulles uniquement d'un récepteur. Par exemple, le client le définira lorsque -R ou bidirectionnel sont utilisés, mais mettra à zéro lorsque seul un expéditeur.
3. "_sum_sent_" sera défini en utilisant des règles similaires, mais pour l'expéditeur ou bidirectionnel.

Cette approche semble rétrocompatible avec la solution actuelle. Si vous approuvez cela peut être une approche utilisable, je vais essayer de la mettre en œuvre.