Iperf: perilaku ketidakcocokan yang aneh UDP OUT OF ORDER

Ini berarti bahwa server iperf3 menerima paket uji UDP dalam urutan yang berbeda dari yang dikirim dari klien iperf3. Mungkin ada berbagai penjelasan untuk fenomena ini, mulai dari paket yang mengambil jalur berbeda melalui jaringan hingga bug di driver jaringan.

Informasi lebih lanjut akan diperlukan bagi seseorang untuk membantu Anda mendiagnosis masalah. Jika Anda mengambil jejak paket (misalnya menggunakan tcpdump) di tempat tujuan, Anda sebenarnya dapat mendekode nomor urut iperf3 dalam paket dan melihat apakah paket telah tiba dengan utuh, rusak, dll.

mungkin ada tautan terikat atau NIC terikat? Itu sering menyebabkan paket yang tidak sesuai pesanan.

Juga, silakan lihat apakah 3.1.6 memperbaikinya.

@bmah888 :

Mengingat bahwa UDP sebagai protokol tidak menjamin bahwa paket akan tiba dalam urutan yang sama dengan pengirimannya, mengapa paket yang rusak dihitung sebagai paket "hilang" dalam keluaran statistik?

Sebagai contoh, pada hasil pengujian UDP di bawah ini menggunakan komit f1415a0d98b terbaru dari iperf di kedua ujungnya dan menggunakan perintah iperf3 -R -u --get-server-output -b 4M -c <my_server_hostname> , ada beberapa pesan "OUT OF ORDER", kemudian segera setelah itu, paket yang rusak tersebut dilaporkan sebagai paket yang hilang (misalnya 2/342 ). Mengapa mereka dianggap hilang? Ini adalah UDP, jadi paket yang tidak sesuai pesanan adalah sesuatu yang dapat terjadi dalam keadaan yang benar-benar normal.

Connecting to host xxx, port 5201
Reverse mode, remote host xxx is sending
[  4] local 192.168.1.110 port 56316 connected to yyy port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec   510 KBytes  4.18 Mbits/sec  1.091 ms  0/358 (0%)
iperf3: OUT OF ORDER - incoming packet = 537 and received packet = 538 AND SP = 4
[  4]   1.00-2.00   sec   489 KBytes  4.01 Mbits/sec  1.111 ms  1/343 (0.29%)
[  4]   2.00-3.00   sec   488 KBytes  3.99 Mbits/sec  0.439 ms  0/342 (0%)
[  4]   3.00-4.00   sec   489 KBytes  4.01 Mbits/sec  1.150 ms  0/343 (0%)
iperf3: OUT OF ORDER - incoming packet = 1562 and received packet = 1563 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1581 and received packet = 1582 AND SP = 4
[  4]   4.00-5.00   sec   488 KBytes  3.99 Mbits/sec  1.397 ms  2/342 (0.58%)
iperf3: OUT OF ORDER - incoming packet = 2002 and received packet = 2004 AND SP = 4
[  4]   5.00-6.00   sec   488 KBytes  4.00 Mbits/sec  1.180 ms  1/342 (0.29%)
[  4]   6.00-7.00   sec   489 KBytes  4.01 Mbits/sec  0.753 ms  0/343 (0%)
[  4]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  0.989 ms  0/343 (0%)
[  4]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  2.294 ms  0/342 (0%)
[  4]   9.00-10.00  sec   486 KBytes  3.98 Mbits/sec  1.401 ms  0/341 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender
[SUM]  0.0-10.1 sec  4 datagrams received out-of-order
[  4]   0.00-10.00  sec  4.80 MBytes  4.02 Mbits/sec  1.361 ms  4/3445 (0.12%)  receiver

Server output:
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from zzz, port 35815
[  6] local yyy port 5201 connected to zzz port 39455
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  6]   0.00-1.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   1.00-2.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   2.00-3.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   3.00-4.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   4.00-5.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   5.00-6.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   6.00-7.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   7.00-8.00   sec   489 KBytes  4.01 Mbits/sec  343
[  6]   8.00-9.00   sec   488 KBytes  3.99 Mbits/sec  342
[  6]   9.00-10.00  sec   489 KBytes  4.01 Mbits/sec  343
[  6]  10.00-10.06  sec  28.5 KBytes  4.01 Mbits/sec  20
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  6]   0.00-10.06  sec  4.80 MBytes  4.00 Mbits/sec  0.000 ms  0/3445 (0%)  sender


iperf Done.

@AndrewJDR : Saya tidak yakin, sejujurnya, mengapa menghitung kesalahan seperti itu. Kode yang dimaksud ditulis sebelum saya mulai mengerjakan proyek ini, atau bahkan sebelum saya bergabung dengan ESnet.

Dugaan saya (dan hanya itu) adalah bahwa jika dua paket dipertukarkan, maka tampaknya ada celah dalam nomor urut yang diterima, yang (salah) dihitung sebagai kerugian. Dengan kata lain, jika paket dikirim dalam urutan ABCD tetapi diterima dalam urutan ACBD, maka iperf3 mungkin berpikir ada paket yang hilang antara B dan D. Tentu saja bukan itu yang terjadi. Saya tidak memiliki wawasan yang lebih dalam saat ini.

Saya pikir idealnya iperf3 akan cukup pintar untuk melacak kerugian vs rusak secara terpisah. Paket-paket yang tidak sesuai pesanan seharusnya tidak muncul di penghitung 'kehilangan'.

Kode yang dimaksud ada di iperf_udp_recv , kutipannya di bawah ini:

    /* Out of order packets */
    if (pcount >= sp->packet_count + 1) {
        if (pcount > sp->packet_count + 1) {
            sp->cnt_error += (pcount - 1) - sp->packet_count;
        }
        sp->packet_count = pcount;
    } else {
        sp->outoforder_packets++;
    iperf_err(sp->test, "OUT OF ORDER - incoming packet = %zu and received packet = %d AND SP = %d", pcount, sp->packet_count, sp->socket);
    }

pcount adalah nomor urut yang dibaca dari paket UDP yang tiba. sp->packet_count adalah nomor urut tertinggi yang terlihat sejauh ini. Ya, tampaknya salah nama, nilai ini mungkin tidak ada hubungannya dengan jumlah total paket yang diterima di aliran. Pada dasarnya pemeriksaan kondisional pertama untuk melihat apakah paket yang tiba membuat nomor urut maju atau mundur. Jika diteruskan, maka kami menghitung celah (jika ada) sebagai paket yang hilang dengan menambahkan ukuran celah ke sp->cnt_error . Kemudian kami menetapkan nomor urut yang diharapkan berikutnya.

Jika nomor urut paket mundur, kami menambahkan penghitung yang tidak sesuai pesanan sp->outoforder_packets dan menampilkan pesan kesalahan yang sedikit membingungkan dengan nomor urut yang sebenarnya dan yang diharapkan dan deskriptor file. Pesan kesalahan masuk ke stderr , yang saya yakini sebagai kesalahan (perhatikan bahwa kami tidak mencatat kehilangan paket individual)...mungkin lebih baik untuk menyembunyikan pesan kesalahan itu di balik flag debug atau verbose.

Misalkan urutan paket dikirim dengan nomor urut (1, 2, 3, 4) tetapi entah bagaimana diterima dalam urutan (1, 3, 2, 4). Paket 1 akan diproses tanpa insiden. Penerimaan paket 3 kemudian akan dihitung sebagai kerugian (karena iperf3 kemudian akan berpikir bahwa paket 2 telah dijatuhkan), tetapi penerima kemudian akan mengharapkan paket 4 berikutnya. Paket 2 benar-benar diterima, dan ini menambah penghitung yang tidak sesuai pesanan (tetapi paket 4 tetap menjadi paket yang diharapkan berikutnya). Akhirnya paket 4 tiba di penerima, yang merupakan nilai yang diharapkan. Urutan paket ini akan dihitung sebagai satu paket out-of-order dan satu kerugian, meskipun pada kenyataannya tidak ada kerugian yang sebenarnya.

Saya mendalilkan bahwa akan (lebih) benar bahwa untuk setiap paket out-of-order yang kami terima, kami dapat mengurangi jumlah kerugian (angka itu harus selalu bukan nol, karena kami harus memiliki celah dalam nomor urut untuk memiliki paket out-of-order, dengan asumsi tidak ada duplikasi paket). Saya yakin bahwa ada beberapa kasus tepi aneh dengan paket duplikat atau kombinasi kehilangan dan pemesanan ulang yang akan membuat ini jatuh, tetapi sejauh yang saya tahu satu-satunya cara untuk menghitung kerugian secara akurat dalam skenario seperti ini adalah dengan menyimpan bitmap dari semua nomor urut dan centang nomor urut yang sebenarnya telah kita lihat. Itu terasa agak merepotkan.

Jadi pada titik ini saya sedang mempertimbangkan untuk membuat sedikit perubahan pada pemrosesan yang tidak sesuai pesanan, mengubah pesan kesalahan sekarang, dan menambahkan beberapa dokumentasi internal yang menjelaskan apa yang dilakukan kode tersebut. Saya tidak memiliki cara mudah untuk menguji ini namun ... Saya siap untuk saran tentang cara menguji ini dengan cara yang agak terkontrol.

@bmah888 Jika Anda ingin menguji paket yang tidak sesuai pesanan dan/atau kehilangan paket, Anda dapat menggunakan alat 'tc' di linux:
https://wiki.linuxfoundation.org/networking/netem#packet -re-ordering

untuk misalnya:

# First add a qdisc:
tc qdisc add dev eth0 root netem delay 1ms # Simulates 1ms of delay
# After running "qdisc add", to simulate packet loss:
tc qdisc change dev eth0 root netem loss 1%
# Alternatively, for simulating re-ordering:
tc qdisc change dev eth0 root netem gap 5 delay 10ms # re-orders every 5th packet
# To switch between loss/re-ordering, first run:
tc qdisc del dev eth0 root
# Then run "tc qdisc add" and the appropriate "tc qdisc change" command above...

Setelah menjalankan perintah ini, jalankan iperf seperti biasa (gunakan mesin yang Anda jalankan 'tc' sebagai pengirim) dan Anda harus mengamati kehilangan paket atau pemesanan ulang.

Anda juga harus dapat menggunakan perintah ini dengan "lo" alih-alih "eth0" jika Anda ingin melakukan pengujian pada adaptor loopback.

(Mungkin ada cara yang lebih ringkas untuk menggunakan perintah ini, tetapi ini adalah metode yang biasa saya gunakan.)

@AndrewJDR : Terima kasih atas infonya, itu sangat membantu saya untuk memulai. Pada CentOS 7 VM yang saya gunakan, saya perlu melakukan sesuatu yang sedikit berbeda, seperti ini:

tc qdisc add dev lo root netem delay 1ms
tc qdisc change dev lo root netem reorder 100 gap 5 delay 10ms

Sekarang pengujian dengan server ini:

bmah-centos7:iperf% src/iperf3 --server

Dan klien ini:

bmah-centos7:iperf% src/iperf3 --client localhost --udp -b 15m

Saya perlu meningkatkan bitrate pengiriman UDP pada klien, karena dengan default, sepertinya paket-paket tidak diberi jarak yang cukup dekat agar penataan ulang netem memiliki efek apa pun. 15Mbps tampaknya cukup cepat sehingga kami melihat sejumlah pemesanan ulang tetapi kami tidak kewalahan dengan hasilnya.

@bmah888 Terima kasih untuk ini... Saya akan mencobanya lain kali saya menjalankan beberapa tes iperf, dan memberi tahu Anda cara kerjanya.

Saya menggabungkan permintaan tarik (#589) untuk dikuasai setelah beberapa pengujian, dengan alasan bahwa perilaku sebelumnya cukup rusak, dan tidak akan menjadi lebih buruk bahkan jika apa yang disebut solusi saya tidak berfungsi. Saya tidak berpikir itu sepenuhnya benar dalam semua kasus BTW, tetapi itu dihitung dengan benar (atau mendekati dengan benar) dalam kasus yang telah saya uji. Menutup masalah ini untuk saat ini... dapat dibuka kembali jika diperlukan.