Iperf: Keluaran JSON tidak memiliki bandwidth penerima untuk UDP

Baik. Ini adalah bug yang sangat lama, yang mungkin sudah ada di iperf3 sejak awal. Saya agak menyadarinya (mengapa saya tidak mengajukan masalah untuk itu?) Ketika saya melakukan pekerjaan di # 562. Seperti yang Anda tunjukkan dengan benar, pengujian UDP tidak membagi statistik sisi klien dan sisi penerima secara terpisah. Saya tidak yakin apakah yang dilaporkan adalah klien, pengirim, atau campuran keduanya. Juga tidak jelas bagi saya mengapa TCP berbeda.

Akan menjadi hal yang baik jika tes UDP dapat memancarkan keluaran statistik yang lebih mirip TCP dalam hal ini (baik sisi pengirim dan penerima secara terpisah), meskipun saya tidak yakin bagaimana menjaga beberapa jenis kompatibilitas dengan program yang menggunakan JSON yang ada. keluaran. (Dalam # 562, saya memperbaiki keluaran yang dapat dibaca manusia untuk UDP, yang Anda sajikan dalam cuplikan keluaran pertama Anda ... Saya tidak terlalu khawatir tentang kompatibilitas ke belakang dalam hal itu karena program seharusnya tidak mencoba membaca keluaran itu.)

Apakah ada penyelesaian untuk masalah ini untuk keluaran UDP JSON? Kami mencoba mengurai keluaran JSON tetapi tidak yakin apa itu. Contoh keluaran JSON adalah: -

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

tetapi kami tidak yakin apa itu byte, apakah itu byte yang dikirim atau byte yang diterima?

Kapan itu akan diperbaiki? Saya perlu mendapatkan bps penerima dari keluaran JSON.

Mungkin ada beberapa solusi?

Itu tidak ada di peta jalan sekarang. Memperbaiki ini sebenarnya membutuhkan perubahan pada mesin negara dan protokol antara klien dan server.

Bolehkah saya bertanya ... Jika menguji dengan UDP dan saya mengurai json dari sisi klien dan mendapatkan

end.sum.bits_per_second     AND 
end.sum.lost_packets

Apakah saya akan mendapatkan gambaran yang adil tentang apakah transmisi mengirim dan menerima data dari sisi server? Apa yang harus saya lakukan untuk memverifikasi kedua arah agar pengiriman / penerimaan berhasil? Parse keluaran teks dari:

- - - - - - - - - - - - - - - - - - - - - - - - -
[ 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 : Saya kira tergantung bagaimana Anda mendefinisikan "sukses". Saya kira satu ukuran mungkin bahwa jika end.sum.lost_packets adalah nol, maka penerima tidak mendeteksi adanya paket yang hilang. Namun, ada beberapa kasus tepi di sekitar ini, sebagian besar berkaitan dengan apa yang terjadi pada paket yang masih dalam penerbangan ketika klien menyatakan pengujian selesai.

Terima kasih ..., saya hanya ingin tahu bahwa saya dapat membaca output ONE JSON ini dan melihat
DASARnya paket ditransfer dari server -> klien dan paket
dikirim dari klien -> server tiba dan tidak ada yang hilang
paket pada salah satu paket yang diterima klien:

Saya percaya itu adalah:

end.sum.packets.
end.sum.lost_packets
end.sum_receiver.packets <--- BARU dengan PATCH
end.sum_receiver.lost_packets <--- BARU dengan PATCH

Mohon koreksi saya jika saya salah!

"akhir": {
"jumlah": {
"akhir": 10.00,
"detik": 10.00,
"bits_per_second": 1058280.26,
"byte": 1322892,
"paket": 81,
"mulai": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"persen_hilang": 0
},
"aliran": [
{
"udp": {
"akhir": 10.00,
"soket": 5,
"detik": 10.00,
"bits_per_second": 1058280.26,
"byte": 1322892,
"paket": 81,
"out_of_order": 0,
"mulai": 0,
"jitter_ms": 0,056,
"lost_packets": 0,
"persen_hilang": 0
}
}
],
"sum_sender": {<--- BARU dengan PATCH
"akhir": 10.00,
"detik": 10.00,
"bits_per_second": 1058280.26,
"byte": 1322892,
"paket": 81,
"mulai": 0,
"jitter_ms": 0,
"lost_packets": 0,
"persen_hilang": 0
},
"sum_receiver": {<--- BARU dengan PATCH
"akhir": 10.00,
"detik": 10.00,
"bits_per_second": 1058271.16,
"byte": 1322892,
"paket": 81,
"mulai": 0,
"jitter_ms": 0,0568,
"lost_packets": 0,
"persen_hilang": 0
}

Terima kasih

-SEBUAH

Pada Kamis, 13 Sep 2018 jam 10:04 Bruce A. Mah [email protected]
menulis:

@awardblvr https://github.com/awardblvr : Saya kira tergantung bagaimana Anda
definisikan "sukses". Saya kira satu ukuran mungkin jika
end.sum.lost_packets adalah nol, maka penerima tidak mendeteksi adanya kehilangan
paket. Ada beberapa kasus tepi di sekitar ini, namun sebagian besar harus dilakukan
dengan apa yang terjadi pada paket yang masih dalam penerbangan saat klien
menyatakan tes selesai.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/esnet/iperf/issues/584#issuecomment-421079759 , atau bisukan
utasnya
https://github.com/notifications/unsubscribe-auth/AFE_e3JCfwSxfr_negMTgZCq8Z6xIkdlks5uapAegaJpZM4NgILa
.

Mengalami masalah serupa dengan kurangnya Tx / Rx B / Ws independen untuk UDP.
Mengambil pendekatan yang berbeda.

Saya menghitung RxMbps menggunakan TxRate dan Drop%.

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

Server --- 10Mbps --- SRX (Router) --- 5Mbps ----- Klien
(Pembentuk lalu lintas diterapkan pada Antarmuka SRX)

Saya menguji kedua arah @ 20Mbps.

Unggahan UDP iPerf3:

Terpencil: 10.8.8.100
Lokal: 10.9.9.222
Protokol / Port: UDP / 33333
Waktu Mulai: Min, 10 Jan 2021 03:51:23 GMT
Durasi (detik): 10
Kecepatan Pengiriman: 20.0Mbps
Tingkat Penerimaan: 9,58Mbps
Jitter: 0,7 ms
Paket Hilang: 8990
Persentase Hilang: 52,07%
CPU Lokal: 9,03%
CPU jarak jauh: 0,76%

Unduh iPerf3 UDP:

Terpencil: 10.8.8.100
Lokal: 10.9.9.222
Protokol / Port: UDP / 33333
Waktu Mulai: Min, 10 Jan 2021 03:51:38 GMT
Durasi (detik): 10
Kecepatan Pengiriman: 20.0Mbps
Kecepatan Terima: 4.82Mbps
Jitter: 0,49 ms
Paket Hilang: 13172
Persentase Hilang: 75,9%
CPU Lokal: 2,5%
CPU jarak jauh: 8,26%

@ hakujin22 , "_RxMbps = TxMbps - (TxMbps * (result.lost_percent / 100)) _" mungkin tidak akan berfungsi secara umum. Ini karena data dikumpulkan hanya secara lokal dan tidak juga dari ujung yang jauh. Misalnya dalam data yang Anda kirim, bandwidth link ujung ke ujung server ke klien adalah 5Mbps. Namun, dengan asumsi Unggahan adalah server ke klien, Anda mendapat 10Mbps di server. Ini karena ini adalah ukuran server untuk throughput SRX dan tidak ujung ke ujung.

@ bmah888 , karena data server dapat diterima menggunakan --server-output , pendekatan berikut dapat digunakan sebagai solusi / solusi untuk masalah ringkasan statistik UDP JSON:

1. Bagian JSON "_sum_received_" dan "_sum_sent_" akan ditambahkan ke ringkasan UDP _end_ di server dan klien. Bagian ini tidak akan menggantikan bagian _sum_.
2. "_Sum_received_" hanya akan menyertakan data bukan nol dari penerima. Misalnya, klien akan menyetelnya saat -R atau dua arah digunakan, tetapi akan menyetel nol jika hanya pengirim.
3. "_sum_sent_" akan disetel menggunakan aturan serupa, tetapi untuk pengirim atau dua arah.

Pendekatan ini tampaknya kompatibel dengan solusi saat ini. Jika Anda setuju, ini mungkin pendekatan yang dapat digunakan, saya akan mencoba menerapkannya.