Iperf: JSON-Ausgabe fehlende Empfängerbandbreite für UDP

Recht. Dies ist ein sehr alter Fehler, der möglicherweise von Anfang an in iperf3 vorhanden war. Ich habe es irgendwie bemerkt (warum habe ich kein Problem dafür eingereicht?), Als ich die Arbeit an # 562 gemacht habe. Wie Sie richtig betont haben, teilen UDP-Tests die clientseitigen und empfängerseitigen Statistiken nicht getrennt auf. Ich bin mir nicht sicher, ob es sich bei dem gemeldeten Kunden um den Kunden, den Absender oder einen Mischmasch der beiden handelt. Mir ist auch nicht klar, warum TCP anders ist.

Es wäre eine gute Sache, wenn UDP-Tests eine Statistikausgabe ausgeben könnten, die in dieser Hinsicht eher TCP ähnelt (sowohl Sender- als auch Empfängerseite getrennt), obwohl ich nicht sicher bin, wie ich eine Art Kompatibilität mit Programmen aufrechterhalten kann, die den vorhandenen JSON verwenden Ausgabe. (In # 562 habe ich die für Menschen lesbare Ausgabe für UDP korrigiert, die Sie in Ihrem ersten Ausgabeausschnitt vorgestellt haben. In diesem Fall war ich weniger besorgt über die Abwärtskompatibilität, da Programme sowieso nicht versuchen sollten, diese Ausgabe zu lesen.)

Gibt es eine Lösung für dieses Problem bei der UDP-JSON-Ausgabe? Wir versuchen, die JSON-Ausgabe zu analysieren, sind uns aber nicht sicher, was was ist. Ein Beispiel für eine JSON-Ausgabe ist: -

    }],
            "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
            },

aber wir sind nicht sicher, was dieses Bytes ist, sind es gesendete Bytes oder die empfangenen Bytes?

Wann wird es behoben? Ich muss die Bit / s des Empfängers von der JSON-Ausgabe abrufen.

Vielleicht gibt es eine Problemumgehung?

Es ist momentan nicht auf der Roadmap. Um dies zu beheben, muss die Statusmaschine und das Protokoll zwischen Client und Server geändert werden.

Darf ich fragen ... Wenn ich mit UDP teste und den JSON von der Client-Seite aus analysiere und bekomme

end.sum.bits_per_second     AND 
end.sum.lost_packets

Habe ich eine faire Darstellung, ob die Übertragung Daten von der Serverseite sendet und empfängt? Was muss ich tun, um zu überprüfen, ob beide Richtungen beim Senden / Empfangen erfolgreich waren? Analysieren Sie die Textausgabe von:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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 : Es hängt davon ab, wie Sie "erfolgreich" definieren. Ich nehme an, eine Maßnahme könnte sein, dass der Empfänger keine verlorenen Pakete erkannt hat, wenn end.sum.lost_packets Null ist. Es gibt jedoch einige Randfälle, die hauptsächlich damit zu tun haben, was mit Paketen passiert, die sich noch im Flug befinden, wenn der Client den Test für abgeschlossen erklärt.

Danke ..., ich möchte nur wissen, dass ich diese EINE json-Ausgabe lesen und sehen kann
Grundsätzlich, dass die Pakete vom Server -> Client und die Pakete übertragen
vom Client übertragen -> Server angekommen und es gab keine verloren
Pakete auf einem der vom Client empfangenen Pakete:

Ich glaube das ist:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- NEU mit PATCH
end.sum_receiver.lost_packets <--- NEU mit PATCH

Bitte korrigieren Sie mich, wenn ich falsch liege!

"Ende": {
"Summe": {
"Ende": 10.00,
"Sekunden": 10,00,
"bits_per_second": 1058280.26,
"Bytes": 1322892,
"Pakete": 81,
"Start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
},
"Streams": [
{
"udp": {
"Ende": 10.00,
"Steckdose": 5,
"Sekunden": 10,00,
"bits_per_second": 1058280.26,
"Bytes": 1322892,
"Pakete": 81,
"out_of_order": 0,
"Start": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"lost_percent": 0
}}
}}
],
"sum_sender": {<--- NEU mit PATCH
"Ende": 10.00,
"Sekunden": 10,00,
"bits_per_second": 1058280.26,
"Bytes": 1322892,
"Pakete": 81,
"Start": 0,
"jitter_ms": 0,
"lost_packets": 0,
"lost_percent": 0
},
"sum_receiver": {<--- NEU mit PATCH
"Ende": 10.00,
"Sekunden": 10,00,
"bits_per_second": 1058271.16,
"Bytes": 1322892,
"Pakete": 81,
"Start": 0,
"jitter_ms": 0,0568,
"lost_packets": 0,
"lost_percent": 0
}}

Vielen Dank

-EIN

Am Do, 13. September 2018 um 10:04 Uhr Bruce A. Mah [email protected]
schrieb:

@awardblvr https://github.com/awardblvr : Es hängt davon ab, wie Sie
definiere "erfolgreich". Ich nehme an, eine Maßnahme könnte sein, wenn
end.sum.lost_packets ist Null, dann hat der Empfänger keinen Verlust festgestellt
Pakete. Es gibt jedoch einige Randfälle, die meistens zu tun haben
mit was passiert mit Paketen, die noch im Flug sind, wenn der Client
erklärt den Test für abgeschlossen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Ein ähnliches Problem trat beim Fehlen unabhängiger Tx / Rx-S / Ws für UDP auf.
Hat einen anderen Ansatz gewählt.

Ich habe RxMbps mit TxRate und Drop% berechnet.

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

Server --- 10 Mbit / s --- SRX (Router) --- 5 Mbit / s ----- Client
(Traffic Shaper, die auf die SRX-Schnittstellen angewendet werden)

Ich teste beide Richtungen bei 20 Mbit / s.

iPerf3 UDP Upload:

Fernbedienung: 10.8.8.100
Lokal: 10.9.9.222
Protokoll / Port: UDP / 33333
Startzeit: So, 10. Januar 2021 03:51:23 GMT
Dauer (Sek.): 10
Übertragungsrate: 20,0 Mbit / s
Empfangsrate: 9,58 Mbit / s
Jitter: 0,7 ms
Verlorene Pakete: 8990
Verlorener Prozentsatz: 52,07%
Lokale CPU: 9,03%
Remote-CPU: 0,76%

iPerf3 UDP Download:

Fernbedienung: 10.8.8.100
Lokal: 10.9.9.222
Protokoll / Port: UDP / 33333
Startzeit: So, 10. Januar 2021 03:51:38 GMT
Dauer (Sek.): 10
Übertragungsrate: 20,0 Mbit / s
Empfangsrate: 4,82 Mbit / s
Jitter: 0,49 ms
Verlorene Pakete: 13172
Verlorener Prozentsatz: 75,9%
Lokale CPU: 2,5%
Remote-CPU: 8,26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" wird wahrscheinlich im Allgemeinen nicht funktionieren. Dies liegt daran, dass die Daten nur lokal und nicht auch vom Remote-Ende erfasst werden. In den von Ihnen gesendeten Daten beträgt die End-to-End-Verbindungsbandbreite von Server zu Client beispielsweise 5 Mbit / s. Angenommen, der Upload erfolgt von Server zu Client, haben Sie 10 Mbit / s auf dem Server. Dies liegt daran, dass dies das Maß für den Durchsatz von Server zu SRX ist und nicht von Ende zu Ende.

@ bmah888 , da die Serverdaten mit --server-output empfangen werden können, kann der folgende Ansatz als Lösung / Problemumgehung für das Problem der UDP JSON-Zusammenfassungsstatistik verwendet werden:

1. Die JSON-Abschnitte "_sum_received_" und "_sum_sent_" werden sowohl auf dem Server als auch auf dem Client zur UDP _end_-Zusammenfassung hinzugefügt. Dieser Abschnitt ersetzt nicht den Abschnitt _sum_.
2. Die "_sum_received_" enthält nur Daten ungleich Null von einem Empfänger. Der Client setzt es beispielsweise, wenn -R oder bidirektional verwendet werden, setzt jedoch Null, wenn nur ein Absender verwendet wird.
3. "_sum_sent_" wird nach ähnlichen Regeln festgelegt, jedoch für Absender oder bidirektional.

Dieser Ansatz scheint mit der aktuellen Lösung abwärtskompatibel zu sein. Wenn Sie zustimmen, dass dies ein brauchbarer Ansatz ist, werde ich versuchen, ihn umzusetzen.