WiFi TCP iperf verimi: 1 akış vs çoklu akışlar?

WLAN iperf TCP işlem testinde, birden fazla paralel akış bana 1 akıştan daha yüksek işlem hacmi sağlayacaktır. TCP pencere boyutunu artırmayı denedim, ancak sadece 1 akışla maksimum verimi elde edemiyorum. TCP katmanında tam bağlantı kapasitesinin kullanılmasını engelleyen başka bir şey var mı?

— elin05
kaynak

Ne kadar fark gözlemliyorsunuz? İdeal olarak, eğer bir TCP akışı bir T verimi sağlıyorsa, ikisi ayrı ayrı T / 2 verimi sağlamalıdır.

— Manoj Pandey

Akış sayısına bakılmaksızın tam bağlantı kapasitesine asla ulaşılamayacağını unutmayın. Minimum [IP + TCP] başlıklı IPv4, ~% 95 kanal verimliliği sağlar. Sd.wareonearth.com/~phil/net/overhead adresindeki mükemmel Protokol Tepegöz yayınına bakın .

— generalnetworkerror

@ManojPandey, ideal bir durum gördüğünden emin değilim ... özellikle wifi kullandığından beri ... Paket kaybı olduğundan şüpheleniyorum ...

— Mike Pennington

TCP Wi-Fi üzerinden berbat, onunla başa çıkmak. Kullanmanız gerekiyorsa ve katman 3 paket kayıplarını görüyorsanız, TCP performansı yok etmeden kayıplı bağlantıları işlemek için tasarlanmadığından, katman 2 maksimum yeniden deneme sayısını artırmanızı öneririm.

— BatchyX

WLAN iperf TCP işlem testinde, birden fazla paralel akış bana 1 akıştan daha yüksek işlem hacmi sağlayacaktır. TCP pencere boyutunu artırmayı denedim, ancak sadece 1 akışla maksimum verimi elde edemiyorum. TCP katmanında tam bağlantı kapasitesinin kullanılmasını engelleyen başka bir şey var mı?

Deneyimlerime göre, 1 TCP akışı ve birden çok TCP akışı arasında önemli ölçüde farklı sonuçlar görürseniz, sorun normalde paket kaybıdır; bu nedenle TCP katmanındaki "başka bir şey" yeniden iletimdir (alt katman paket kaybı nedeniyle).

Paket kaybının tek akışlı verimi nasıl etkilediğini göstermek için hazırladım bir örnek ...

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

Bu, bir iperfistemci ve sunucu arasındaki 60 saniyelik bir testin test sonuçlarını özetleyen bir tablodur ... RTT titresinden (yani daha yüksek RTT standart sapması) iperf sonuçlarında küçük bir değişiklik görebilirsiniz; ancak, en önemli fark, istemci kablolu NIC'den% 2 kayıp simüle ettiğimde ortaya çıktı. 172.16.1.56 ve 172.16.1.80 aynı dizüstü bilgisayarlardır (Ubuntu çalıştıran). Sunucu, Debian'ı çalıştıran 172.16.1.5. Paket kaybını simüle etmek için istemci kablolu NIC'de netem kullandım ...

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

Yorum yanıtları için DÜZENLE :

Son senaryoda neler olduğunu açıklayabilir misiniz (1000BaseT, 5 akış,% 2.0 kayıp)? Paket kaybı olmasına rağmen, toplam üretim hala 937 Mbits / sn'de doymuş durumda.

Çoğu TCP uygulaması , paket kaybı algılandığında tıkanıklık pencerelerini azaltır . İstemciden sunucuya% 2 paket kaybını zorlamak için netem kullandığımız için, istemcinin bazı verileri düşüyor. Net etkisi netem bu örnekte 730Mbps bir tek akım ortalama nakil oranıdır. Birden çok akış eklemek, ayrı TCP akışlarının bağlantıyı doyurmak için birlikte çalışabileceği anlamına gelir.

Amacım WiFi üzerinden mümkün olan en yüksek TCP verimini elde etmek. Anladığım kadarıyla, paket kaybından kaynaklanan verimdeki azalmaya karşı koymak için akış sayısını artırmalıyım. Bu doğru mu?

Evet

Ayrıca, hangi noktada çok fazla akış verimi olumsuz yönde etkilemeye başlayacak? Buna sınırlı bellek ve / veya işlem gücü neden olur mu?

Daha fazla deney yapmadan buna gerçekten cevap veremem, ancak 1GE bağlantıları için, 5 paralel akışla bağlantıyı doyurmakta hiç sorun yaşamadım. TCP'nin ne kadar ölçeklenebilir olduğu hakkında bir fikir vermek için, linux sunucuları doğru koşullar altında 1500'den fazla eşzamanlı TCP soketini işleyebilir . Bu, eşzamanlı TCP soketlerini ölçeklendirmeyle ilgili başka bir SO tartışmasıdır , ancak bence, sadece bir bağlantıyı doyurmaya çalışıyorsanız, 20 paralel soketin üzerindeki herhangi bir şey aşırıya kaçar.

İperf'in -w pencere boyutunu maksimum olarak 21K başlangıç değerinin ötesine büyüdüğünü söylediğiniz gibi kullandığına dair bir yanlış anlaşılmam olmalı

Kullanmadım iperf -w, bu yüzden bir yanlış anlama olduğunu düşünüyorum. Wifi kasası hakkında çok fazla sorunuz olduğu için, wifi tek TCP akış durumu için TCP veriminin bir wireshark grafiği ekliyorum.

Kablosuz TCP tek akış hızı

Test verisi

Bunları nasıl ölçtüğümü görmek istemeniz durumunda ham test verilerini de dahil ediyorum ...

802.11g, 1 TCP Akışı

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 TCP Akışı

[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 Akış,% 0.0 kayıp

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 Akış,% 0.0 kayıp

[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 Akış,% 2.0 kayıp

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 Akış,% 2.0 kayıp

[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:~$

Paket kaybı simülasyonunu kaldır

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

— Mike Pennington
kaynak

Son senaryoda neler olduğunu açıklayabilir misiniz (1000BaseT, 5 akış,% 2.0 kayıp)? Paket kaybı olmasına rağmen, toplam üretim hala 937 Mbits / sn'de doymuş durumda. Amacım WiFi üzerinden mümkün olan en yüksek TCP verimini elde etmek. Anladığım kadarıyla, paket kaybından kaynaklanan verimdeki azalmaya karşı koymak için akış sayısını artırmalıyım. Bu doğru mu? Ayrıca, hangi noktada çok fazla akış verimi olumsuz yönde etkilemeye başlayacak? Buna sınırlı bellek ve / veya işlem gücü neden olur mu?

— elin05

@ elin05: Birden fazla akış kullanmak, paket kaybını birkaç akışa yayar, bu nedenle bir paket kaybı meydana geldiğinde, yalnızca bir akış TCP penceresinin boyutunu küçültür ve diğer akışları etkilenmez.

— BatchyX

802.11g (54Mbps) BDP, boruyu uçuş paketleriyle dolu tutmak için 8ms (16ms RTT / 2) gecikmeli 54KB pencere boyutu gerektirmez mi? Sunucu tarafındaki pencere boyutu nedir?

— generalnetworkerror

@generalnetworkerror, TCP pencereleri statik değil ... TCP'nin ihtiyaçlarına göre değişir ... bu yakalama sırasında, Tsunami'nin reklamını yaptığı maksimum pencere boyutu 1177600 bayt; Tsunami'nin ortalama penceresi 1045083 bayt ve bu 60 saniyelik testin ortalama RTT'si 32.2 ms idi.

— Mike Pennington

@MikePennington: iperf'in -w pencere boyutunu maksimum olarak 21K başlangıç değerinin ötesinde büyüdüğünü söylediğiniz gibi kullandığına dair bir yanlış anlaşılmam olmalı.

— generalnetworkerror

İşte tek bir tcp akışının maksimum verimi için hesaplama.

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

Yani bir darboğaz var ve gecikme büyük bir rol oynuyor.

— James.Birmingham
kaynak

Muhtemelen birden çok işlem ve bir işlemden kaynaklanmaktadır. iperf 2.0.9 ile bunu istemcide -P 2 ile test edebilirsiniz. Bu, bir yerine iki ipliği kesecektir. Modern CPU'ların çoğunun birden fazla çekirdeği vardır, bu nedenle birden fazla iş parçacığı kullanmak bunları kaldırabilecektir.

— rjmcmahon
kaynak