300Mbit'de (% 14) aşırı UDP paket kaybı, ancak yeniden iletim olmadan TCP> 800Mbit


11

iperf3İstemci olarak kullandığım bir linux kutum var, Broadcom BCM5721, 1Gb adaptörlerle (2 bağlantı noktası, ancak yalnızca 1 test için kullanılan) aynı donanımlı 2 Windows 2012 R2 sunucu kutusunu test ediyorum . Tüm makineler tek bir 1 Gb anahtar ile bağlanır.

UDP'yi örneğin 300Mbit'te test etme

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

gönderilen tüm paketlerin% 14'ünün kaybıyla sonuçlanır (tam olarak aynı donanıma sahip diğer sunucu kutusu için, ancak daha eski NIC sürücüleri, kayıp% 2 civarındadır), ancak kayıp daha az da olsa 50Mbit'de bile gerçekleşir. Eşdeğer ayarları kullanarak TCP performansı:

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

rapor edilen yeniden iletim olmadan 800Mbit'in kuzeyindeki iletim hızlarını verir.

Sunucu her zaman aşağıdaki seçenekler kullanılarak başlatılır:

iperf3 -sB192.168.30.161

Kim suçlanacak?

  1. Linux istemci kutusu (donanım? Sürücüleri? Ayarları?)? Düzenleme: Ben sadece bir Windows sunucu kutusundan diğerine test çalıştırdı ve 300Mbit UDP paket kaybı daha yüksek,% 22
  2. Windows sunucu kutuları (donanım? Sürücü? Ayarları?)?
  3. Tüm test makinelerini bağlayan (tekli) anahtar?
  4. Kablolar?

Düzenle:

Şimdi diğer yönü denedim: Windows -> Linux. Sonuç: Paket kaybı her zaman 0 iken, iş hacmi yaklaşık en üst düzeye çıkar

  • 840Mbit -l8192, yani parçalanmış IP paketleri için
  • Parçalanmamış -l1472IP paketleri için 250Mbit

Akış kontrol kapaklarının verimini tahmin ediyorum ve paket kaybını önlüyor. Özellikle sonuncu, parçalanmamış rakam TCP veriminin yakınında değildir (parçalanmamış TCP parçalanmış TCP'ye benzer rakamlar verir), ancak paket kaybı açısından Linux -> Windows üzerinde son derece büyük bir gelişme.

Nasıl öğrenilir?

Performansı en üst düzeye çıkarmak için sunucudaki sürücü ayarları için normal tavsiyeleri izledim ve etkinleştirmeye / devre dışı bırakmaya / en üst düzeye çıkarmaya / en aza indirmeye / değiştirmeye çalıştım

  • Kesinti Denetimi
  • Akış kontrolü
  • Tamponları Al
  • RSS
  • Wake-on-LAN

Tüm boşaltma özellikleri etkindir.

Düzenle Ayrıca etkinleştirmeyi / devre dışı bırakmayı denedim

  • Ethernet @ kablolu hızında
  • Çeşitli boşaltma özellikleri
  • Öncelik & VLAN

Benzer kayıp oranları ile.


Bir UDP çalıştırmasının tam çıktısı:

$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522639.098587.3451f174
[  4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  33.3 MBytes   279 Mbits/sec  4262
[  4]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  4577
[  4]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec   176 MBytes   296 Mbits/sec  0.053 ms  3216/22571 (14%)
[  4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  27.2 MBytes   226 Mbits/sec  0.043 ms  781/4261 (18%)
[  5]   1.01-2.01   sec  30.0 MBytes   252 Mbits/sec  0.058 ms  734/4577 (16%)
[  5]   2.01-3.01   sec  29.0 MBytes   243 Mbits/sec  0.045 ms  870/4578 (19%)
[  5]   3.01-4.01   sec  32.1 MBytes   269 Mbits/sec  0.037 ms  469/4579 (10%)
[  5]   4.01-5.01   sec  32.9 MBytes   276 Mbits/sec  0.053 ms  362/4576 (7.9%)

TCP çalıştırması:

$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522833.505583.4078fcc1
      TCP MSS: 1448 (default)
[  4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   910 Mbits/sec    0   91.9 KBytes       
[  4]   1.00-2.00   sec  97.3 MBytes   816 Mbits/sec    0   91.9 KBytes       
[  4]   2.00-3.00   sec  97.5 MBytes   818 Mbits/sec    0   91.9 KBytes       
[  4]   3.00-4.00   sec  98.0 MBytes   822 Mbits/sec    0   91.9 KBytes       
[  4]   4.00-5.00   sec  97.6 MBytes   819 Mbits/sec    0   91.9 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   499 MBytes   837 Mbits/sec    0             sender
[  4]   0.00-5.00   sec   498 MBytes   836 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec  97.5 MBytes   818 Mbits/sec                  
[  5]   2.00-3.00   sec  97.6 MBytes   819 Mbits/sec                  
[  5]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec                  
[  5]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec                  

Yanıtlar:


8

Sorun yok. Bu normal ve beklenen bir davranıştır.

Paket kaybının nedeni UDP'nin tıkanıklık kontrolü olmamasıdır. Tıkanıklık kontrol algoritmaları devreye girdiğinde tcp'de, verimi en üst düzeye çıkarmak ve kaybı en aza indirmek için gönderme ucunun gönderimi yavaşlatmasını söyleyecektir.

Bu aslında UDP için tamamen normal bir davranış. Alma sırası aşırı yüklendiğinde ve paketleri düşürürse UDP teslimatı garanti etmez. UDP için daha yüksek iletim hızları istiyorsanız, alma arabelleğinizi artırmanız gerekir.

-L veya --len iperf seçeneği hile yapmalıdır. Ve muhtemelen hedef bant genişliği ayarı -b istemcide.

-l, --len n [KM] uzunluk okuma / yazma arabelleğini n olarak ayarlar (varsayılan 8 KB)

8KB ?? Tıkanıklık kontrolü olmadığında küçük tarafta bu biraz.

örneğin sunucu tarafında.

~$ iperf -l 1M -U -s

Linux'tan Linux'a aldığım şey bu

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Ancak varsayılan ayarları kullanan UDP için yalnızca

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT?

Bazı deneylerden sonra hem uzunluğu hem de bant genişliği hedefini ayarlamam gerektiğini buldum.

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

Sunucu tarafı:

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

Küçük tamponlarla paket kaybını göstermek. Dürüst olmak gerekirse, beklediğim kadar aşırı değil. Linux / Windows arasında test edebileceğim iperf3 için güvenilir bir kaynak nerede?

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Sunucu tarafı:

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Ayrıca iperf3 github sayfa benioku baktınız mı?

Bilinen Sorunlar

UDP performansı: ESnet 100G test yatağında iperf3 ile yüksek UDP hızlarında (10Gbps'nin üzerinde) bazı sorunlar fark edildi. Belirti, iperf3'ün herhangi bir özel işleminde, alıcının, müşteri tarafında kullanılan -b seçeneğine bakılmaksızın, yaklaşık% 20'lik bir kayıp oranı raporlamasıdır. Bu sorun iperf3'e özgü görünmemektedir ve iperf3 işleminin bir CPU'ya yerleştirilmesi ve gelen NIC ile ilişkisi nedeniyle olabilir. Bazı durumlarda, CPU benzeşimi (-A) seçeneğinin uygun bir şekilde kullanılmasıyla bu sorun azaltılabilir. (Sayı # 55)

Daha yavaş bir NIC kullanıyorsunuz ama bunun ilgili olup olmadığını merak ediyorum.


Evet ve paket kaybına gelince, bunun nasıl olabileceğini göstereceğim. cevap güncelleniyor.
Matt

Teşekkürler Matt, güncellemeni gördüm. Iperf'im (hem Windows sunucusunda hem de Linux istemcisinde) sürüm 2.0.5. Seninki nedir?
Eugene Beresovsky

Aynısı. Ve aslında hedef bant genişliğini 1G olarak ayarladığımda 14756449370562973696 Bayt / sn ve diğer bozuk çıktıların bonkas bant genişliği oranlarını alıyorum. Bu yüzden muhtemelen kırıldığını düşünüyorum. Hala sorunların tamponlar olduğunu düşünüyorum ... Windows ve TCP ve UDP tamponlama ile bazı alışılmadık şeyler yaptığını biliyorum.
Matt

Garip. Daha sonra bugün muhtemelen iyi bir 10G üretim ortamına erişeceğim ve bu konuda iperf3'ü serbest bırakacağım. Bunun nasıl gittiğine bakalım.
Eugene Beresovsky

1
Sanırım -lanahtarın ne yaptığını yanlış anlıyorsun . Arabellek boyutunu ayarlamıyor; paket boyutunu ayarlar. Bu, iperf3'ün bir seferde sokete yazacağı ve bir seferde soketten okuyacağı veri miktarıdır. Soket arabellek boyutunu kullanarak ayarlayabilirsiniz -w. Kaynağa bakarsanız setsockopt(), soket arabellek boyutunu daha sonra belirttiğiniz herhangi bir değere ayarlamak için çağırdığını görürsünüz -w.
András Korn

0

En bariz suçluyu - adaptörleri ve sonra sürücüleri tamamen kaçırdınız (farklı bir sürüm sürücüsü kullanmanın farklı sonuçlar verdiğini belirtiyorsunuz).

Tüm boşaltma yeteneklerini kapatmayı deneyin.


Bu yardımcı olmadı - soru buna göre güncellendi.
Eugene Beresovsky
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.