Wifi TCP iperf throughput: 1 stream vs beberapa stream?

Dalam tes throughput WLAN iperf TCP, multiple parallel stream akan memberi saya throughput lebih tinggi dari 1 stream. Saya mencoba meningkatkan ukuran jendela TCP, tetapi saya masih tidak dapat mencapai throughput maks hanya dengan 1 stream. Apakah ada hal lain dalam lapisan TCP yang mencegah kapasitas tautan penuh agar tidak digunakan?

— Elin05
sumber

Berapa banyak perbedaan yang Anda amati? Idealnya, jika satu aliran TCP menyediakan throughput T, maka dua aliran harus masing-masing menyediakan throughput T / 2 masing-masing.

— Manoj Pandey

Perhatikan bahwa kapasitas tautan penuh terlepas dari jumlah aliran tidak akan pernah tercapai. IPv4 dengan header [IP + TCP] minimal akan menghasilkan efisiensi saluran ~ 95%. Lihat posting Overhead Protokol yang luar biasa di sd.wareonearth.com/~phil/net/overhead .

— generalnetworkerror

@ ManojPandey, saya tidak yakin dia melihat kasus yang ideal ... terutama karena dia menggunakan wifi ... Saya menduga dia memiliki beberapa paket yang hilang ...

— Mike Pennington

TCP mengisap melalui Wi-Fi, hadapi itu. Jika Anda harus menggunakannya dan Anda melihat hilangnya paket lapisan 3, saya akan menyarankan untuk meningkatkan jumlah coba lagi maksimum layer 2, karena TCP tidak dirancang untuk menangani tautan yang hilang tanpa merusak kinerja.

— BatchyX

Dalam tes throughput WLAN iperf TCP, multiple parallel stream akan memberi saya throughput lebih tinggi dari 1 stream. Saya mencoba meningkatkan ukuran jendela TCP, tetapi saya masih tidak dapat mencapai throughput maks hanya dengan 1 stream. Apakah ada hal lain dalam lapisan TCP yang mencegah kapasitas tautan penuh agar tidak digunakan?

Dalam pengalaman saya, jika Anda melihat hasil yang sangat berbeda antara 1 aliran TCP dan beberapa aliran TCP masalahnya biasanya paket loss; jadi "sesuatu yang lain" di lapisan TCP adalah pengiriman ulang (karena paket-lapisan yang lebih rendah).

Sebuah contoh yang saya buat untuk menggambarkan bagaimana packet loss memengaruhi throughput aliran tunggal ...

                   [Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+                                        +--------------+
|              |                                        |              |
| Thinkpad-T61 |----------------------------------------| Linux Server |
|              |                                        | Tsunami      |
+--------------+                                        +--------------+
iperf client             ------------------>            iperf server
                             Pushes data

Ini adalah tabel yang merangkum hasil tes dari tes 60 detik iperfantara klien dan server ... Anda mungkin melihat sedikit variasi dalam hasil iperf dari jitter RTT (yaitu standar deviasi RTT yang lebih tinggi); Namun, perbedaan paling signifikan datang ketika saya mensimulasikan kehilangan 2% meninggalkan NIC kabel klien. 172.16.1.56 dan 172.16.1.80 adalah laptop yang sama (menjalankan Ubuntu). Server adalah 172.16.1.5, menjalankan Debian. Saya menggunakan netem pada NIC kabel klien untuk mensimulasikan paket loss ...

Client IP       Transport    Loss     avg RTT    RTT StdDev    TCP Streams   Tput
-----------     ----------   ----     -------    ----------    -----------   ----------
172.16.1.56     802.11g      0.0%      0.016s          42.0              1     19.5Mbps
172.16.1.56     802.11g      0.0%      0.016s          42.0              5     20.5Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              1    937  Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              5    937  Mbps
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              1    730  Mbps <---
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              5    937  Mbps

EDIT untuk tanggapan komentar :

Bisakah Anda menjelaskan apa yang terjadi dalam skenario terakhir (1000BaseT, 5 stream, 2.0% loss)? Meskipun ada paket loss, total throughput masih jenuh pada 937 Mbits / detik.

Sebagian besar implementasi TCP mengurangi jendela kemacetan ketika paket hilang terdeteksi. Karena kami menggunakan netem untuk memaksa kehilangan paket 2% dari klien ke server, beberapa data klien akan dibatalkan. Efek bersih dari netem dalam contoh ini adalah laju transmisi rata-rata aliran tunggal 730Mbps. Menambahkan beberapa aliran berarti bahwa masing-masing aliran TCP dapat bekerja bersama untuk menjenuhkan tautan.

Tujuan saya adalah untuk mencapai throughput TCP tertinggi melalui WiFi. Seperti yang saya pahami, saya harus meningkatkan jumlah stream untuk mengatasi penurunan throughput yang disebabkan oleh packet loss. Apakah ini benar?

Iya

Selain itu, pada titik mana aliran terlalu banyak akan mulai berdampak negatif terhadap throughput? Apakah ini disebabkan oleh memori yang terbatas dan / atau daya pemrosesan?

Saya tidak dapat menjawabnya tanpa eksperimen lebih lanjut, tetapi untuk tautan 1GE, saya tidak pernah memiliki masalah menjenuhkan tautan dengan 5 aliran paralel. Untuk memberi Anda gambaran tentang bagaimana scalable TCP, server linux dapat menangani lebih dari 1500 soket TCP bersamaan dalam kondisi yang tepat. Ini adalah diskusi SO lainnya yang relevan dengan penskalaan soket TCP bersamaan, tetapi menurut pendapat saya apa pun di atas 20 soket paralel akan berlebihan jika Anda hanya mencoba menjenuhkan tautan.

Saya harus memiliki kesalahpahaman bahwa iperf menggunakan ukuran jendela -w semaksimal kedengarannya seperti yang Anda katakan tumbuh melebihi nilai awal 21K

Saya tidak menggunakan iperf -w, jadi saya pikir ada kesalahpahaman. Karena Anda memiliki begitu banyak pertanyaan tentang case wifi, saya menyertakan grafik wireshark dari throughput TCP untuk wifi single case stream TCP.

Wifi TCP single-stream throughput

Data Uji

Saya juga menyertakan data uji mentah jika Anda ingin melihat bagaimana saya mengukur hal-hal ini ...

802.11g, 1 Aliran TCP

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
  --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.8  16.0   0.7 189.4  42.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.1 sec   139 MBytes  19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

802.11g, 5 Streaming TCP

[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[  5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[  7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[  4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[  6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  28.0 MBytes  3.91 Mbits/sec
[  5]  0.0-60.1 sec  28.8 MBytes  4.01 Mbits/sec
[  4]  0.0-60.3 sec  28.1 MBytes  3.91 Mbits/sec
[  6]  0.0-60.4 sec  34.0 MBytes  4.72 Mbits/sec
[  7]  0.0-61.0 sec  30.5 MBytes  4.20 Mbits/sec
[SUM]  0.0-61.0 sec   149 MBytes  20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 Stream, kerugian 0,0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
>   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.54 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 Streaming, kerugian 0,0%

[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[  3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[  4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[  5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[  6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  5]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  3]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[  7]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 Streaming, kerugian 2,0%

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 1.7%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-64.1 sec  5.45 GBytes   730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 Streaming, kerugian 2,0%

[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[  3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[  5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[  4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[  6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.74 GBytes   250 Mbits/sec
[  7]  0.0-60.0 sec   711 MBytes  99.3 Mbits/sec
[  4]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.59 GBytes   228 Mbits/sec
[  5]  0.0-60.0 sec  1.24 GBytes   177 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

Hapus simulasi packet loss

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root

— Mike Pennington
sumber

Bisakah Anda menjelaskan apa yang terjadi dalam skenario terakhir (1000BaseT, 5 stream, 2.0% loss)? Meskipun ada paket loss, total throughput masih jenuh pada 937 Mbits / detik. Tujuan saya adalah untuk mencapai throughput TCP tertinggi melalui WiFi. Seperti yang saya pahami, saya harus meningkatkan jumlah stream untuk mengatasi penurunan throughput yang disebabkan oleh packet loss. Apakah ini benar? Selain itu, pada titik mana aliran terlalu banyak akan mulai berdampak negatif terhadap throughput? Apakah ini disebabkan oleh memori yang terbatas dan / atau daya pemrosesan?

— elin05

@ elin05: Menggunakan beberapa stream menyebarkan paket loss pada beberapa stream, jadi ketika packet loss terjadi, hanya satu stream yang akan mengurangi ukuran jendela TCP-nya, sehingga stream lainnya tidak terpengaruh.

— BatchyX

Bukankah BDP 802.11g (54Mbps) membutuhkan ukuran jendela 54KB dengan penundaan 8ms (16ms RTT / 2) agar pipa penuh dengan paket dalam penerbangan? Berapa ukuran jendela di sisi server?

— generalnetworkerror

@generalnetworkerror, jendela TCP tidak statis ... mereka berubah berdasarkan kebutuhan TCP ... selama penangkapan itu, ukuran jendela maksimum yang diiklankan Tsunami adalah 1177600 bytes; Jendela rata-rata tsunami adalah 1045083 byte dan rata-rata RTT selama 60 detik pengujian adalah 32,2 ms.

— Mike Pennington

@ MikePennington: Saya harus memiliki kesalahpahaman bahwa iperf menggunakan ukuran jendela -w semaksimal kedengarannya seperti Anda mengatakan itu tumbuh melampaui nilai awal 21K.

— generalnetworkerror

Inilah perhitungan untuk throughput maksimum dari satu aliran tcp.

(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)

Jadi, Anda memiliki hambatan dan latensi memainkan peran besar.

— James.Birmingham
sumber

Mungkin karena beberapa proses vs satu proses. dengan iperf 2.0.9 kita dapat menguji ini melalui -P 2 pada klien. Ini akan memotong dua utas alih-alih satu. Sebagian besar CPU modern memiliki banyak inti sehingga menggunakan beberapa utas akan dapat memanfaatkannya.

— rjmcmahon
sumber