kinerja TCP yang lebih baik melalui "jaringan penundaan tinggi"

Saya mencoba untuk meningkatkan throughput TCP saya melalui "jaringan penundaan tinggi" antara mesin-mesin Linux.

Saya mengatur tcp_mem, tcp_wmemdan tcp_rmemke "8192 7061504 7061504".
Aku mengatur rmem_max, wmem_max, rmem_defaultdan wmem_defaultuntuk “7061504”.
Saya mengatur netdev_max_backlogdan txqueuelenke 10000.
Saya mengatur tcp_congestion_controlke "scalable".

Saya menggunakan "nist" (cnistnet) untuk mensimulasikan penundaan 100 ms, dan jangkauan BW saya sekitar 200mbps (tanpa penundaan saya mencapai sekitar 790mbps).

Saya menggunakan iperf untuk melakukan tes dan TCPTrace untuk menganalisis hasilnya, dan inilah yang saya dapatkan:

Di sisi penerima:
maks win adv: 5294720 bytes
avg win adv: 5273959 bytes
pkts pkts terkirim: 0

Di sisi pengirim:
byte data aktual: 3085179704
byte data rexmt: 9018144
maks owin : 5294577 byte
avg owin: 3317125 byte
RTT min: 19,2 ms
RTT maks: 218,2 ms
RTT avg: 98,0 ms

Mengapa saya hanya mencapai 200mbps? Saya menduga "owin" ada hubungannya dengan itu, tapi saya tidak yakin (hasil ini adalah tes 2 menit. Tes 1 menit memiliki "avg owin" dari 1552900) ...

Apakah saya salah untuk mengharapkan throughput hampir 790mbps bahkan jika penundaannya 100ms?

(Saya mencoba menggunakan angka yang lebih besar dalam konfigurasi jendela tetapi tampaknya tidak berpengaruh)

Ini adalah masalah TCP umum yang disebut "Long Fat Pipe". Jika Anda Google frasa dan TCP Anda akan menemukan banyak informasi tentang masalah ini dan solusi yang mungkin.

Utas ini memiliki banyak perhitungan dan saran untuk menyetel Linux TCP stack untuk hal semacam ini.

Situs

http://www.psc.edu/networking/projects/tcptune/

menyebutkan bahwa sebagai Linux saat ini melakukan autotunes pada pengaturan TCP, mengacaukan nilai-nilai kemungkinan tidak akan memperbaiki keadaan.

Yang sedang berkata, mungkin 100 ms bersama dengan bandwidth besar (setidaknya 790 mbps) dapat menyebabkan BDP yang sangat besar, jadi mungkin autotuning memutuskan bahwa ada sesuatu yang salah dan tidak cukup jauh ..

Coba atur ukuran jendela iperf untuk benar-benar membuat produk bandwidth-delay dari tautan itu. Jadi rata-rata RTT * 1Gbps seharusnya memberi Anda sekitar 10MB. Lihat apakah itu memperbaiki keadaan.

Satu-satunya cara Anda benar-benar dapat mulai memahami apa yang sedang terjadi adalah mendapatkan lebih banyak data - jika tidak, Anda hanya menebak atau meminta orang lain untuk menebak. Saya sarankan mendapatkan tampilan tingkat sistem (cpu, memori, interupsi dll) dengan sardari iostatpaket. Juga, Anda harus mendapatkan paket dump dengan Wireshark atau tcpdump. Anda kemudian dapat menggunakan Wireshark untuk menganalisanya karena memiliki banyak alat untuk ini. Anda dapat membuat grafik ukuran jendela dari waktu ke waktu, kehilangan paket, dll.

Bahkan sedikit kehilangan paket pada tautan latensi tinggi cenderung sedikit merusak bandwidth. Meskipun disimulasikan - ini agak aneh. Banyak paket kecil juga dapat menyebabkan gangguan tinggi (meskipun mungkin juga disimulasikan?).

Jadi singkatnya, dapatkan TCPDump dan Sar untuk melihat apa yang terjadi di tingkat paket dan dengan sumber daya sistem Anda.

Berapa banyak memori yang dimiliki mesin ini? The tcp_mempengaturan tampaknya gila, itu dikonfigurasi 28GB (7.061.504 * 4KB) untuk data TCP global. (Tapi ini bukan masalah perf Anda karena Anda kemungkinan besar tidak mencapai batas itu pada uji coba beberapa soket. Hanya ingin menyebutkannya karena pengaturan nilai tcp_mem ke tcp_xmem menunjukkan kesalahan konsep yang sangat umum).

7mb yang telah Anda konfigurasi untuk default tampaknya ok. Namun maksimum bisa naik jauh lebih tinggi pada pipa delay besar. Untuk pengujian saya akan menggunakan 64MB sebagai angka maksimum untuk tcp_wmemdan tcp_rmem, maka Anda dapat mengesampingkan bahwa ini adalah faktor pembatas Anda. (Ini menggembungkan buffer Anda, jadi itu hanya berfungsi jika Anda memiliki konkurensi terbatas dan koneksi memiliki jitter dan drop yang rendah).