Netzwerkanalyse, Fehlersuche, Testberichte
Home / News
Netzwerkanalyse
Grundlagen
Verkabelung
Erste Schritte
Baselining
Let's sniff
Tools
Auswerten/Filtern
Typische Probleme 1
Typische Probleme 2
Sicherheit
Bücher
Tutorials
Cacti
DSL einrichten
DynDNS einrichten
m0n0wall | pfSense
Nmap
VirtualBox
Wireshark
FAQ
Know How
Testberichte
Hardware-DB
Netzwerklexikon
Links / Service
Suche
Kontakt
Impressum
Feedback
Sitemap
Netzwerktechnik Forum

Forum Netzwerktechnik (Archiv)

Kategorie Netzwerktechnik - Forum Tools

 
netio:Einbruch der Transferrate bei Vorgabe der Blockgroesse

geschrieben am 29.10.2007 um 17:00 von geller1a

Hallo,

der Test einer Netzwerkverbindung per netio funktioniert bei mir wie erwartet:

Code:
netio_linux-i386  -t  otherhost

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  114879 KByte/s Tx,  114843 KByte/s Rx.
Packet size  2k bytes:  114921 KByte/s Tx,  114852 KByte/s Rx.
Packet size  4k bytes:  114890 KByte/s Tx,  114858 KByte/s Rx.
Packet size  8k bytes:  114913 KByte/s Tx,  114859 KByte/s Rx.
Packet size 16k bytes:  114912 KByte/s Tx,  114874 KByte/s Rx.
Packet size 32k bytes:  114924 KByte/s Tx,  114865 KByte/s Rx.


Gibt man die Blockgroesse fuer den Test jedoch vor, so entstehen deutliche Performanceeinbrueche:

Code:
netio_linux-i386  -t  -b 16 otherhost

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 16 bytes:  12324 KByte/s Tx,  11892 KByte/s Rx.
Done.


Ich habe im Moment keine Idee warum die Vorgabe der Blockgroesse die Transferrate beeinflusst. Hat jemand eine Idee?

Danke im voraus
AG
 

geschrieben am 30.10.2007 um 09:38 von bewa

Re: netio:Einbruch der Transferrate bei Vorgabe der Blockgro

"geller1a" wrote:

Ich habe im Moment keine Idee warum die Vorgabe der Blockgroesse die Transferrate beeinflusst. Hat jemand eine Idee?


Ja, das Problem ist fast so alt wie TCP. :-)

Zum einen generierst du recht viel Overhead. Du verschickst eine Nutzlast von 16 Bytes. IP+TCP-Header benötigen zusammen mindestens 20+20 = 40 Bytes. Für je 16 Bytes Daten ein 56 Byte Paket (40 Byte Header) - ein absolut lausiges Verhältnis für performante Datenübertragung... Rechne das mal hoch: Selbst wenn du "nur" 12MB/s verschickst: 12*1024^2/16 = 786 432 Pakete PRO SEKUNDE. Macht 786432 * 40 Bytes = 31457280 Bytes, also 30 MB an Header. Es gehen also 42 MB/s über die Leitung. Immer noch schlechter, aber schon nicht mehr so schlecht.

Zum anderen verschickst du damit natürlich Unmengen kleiner Pakete. Das Problem ist dabei in diesem Fall NICHT wie sonst häufiger, das diese (recht kleine) Menge Nutzdaten nicht in den Puffer beim Empfänger passt, sondern, das dieser alle bestätigen muss. Er muss also zu jedem Paket ein ACK-Paket ("Jau, habe ich bekommen") generieren - zig mal mehr pro Sekunde, als bei großen Paketen. Zum einen "verbraucht" das natürlich Kapazität auf der Leitung, zum anderen generiert das deutlich höhere Last für den Treiber und damit die CPU, da er stolze 786 000 Pakete auswerten und bearbeiten muss - zzgl. der Pakete, die evtl. doppelt oder nicht vorhanden sind... Wie ist denn die CPU-Last, wenn du 16 Byte-Pakete sendet? Aktuelle CPUs können das in der Regel aushalten, aber sichtbar sollte es bei GBit sein. An dieser Stelle merkt man übrigens oft Unterschiede zwischen guten und schlechten Treibern sowie Karten die manches in Hardware beschleunigen, gegenüber denjenigen, die alles im Treiber machen - gute Treiber/Karten machen dabei messbar weniger Last.

Man kann das Bestätigen der Pakete natürlich intelligenter lösen - in dem man gebündelt bestätigt "Die letzten zehn habe ich" oder sogar ein bischen wartet und dann "Ja, habe Paket 1 bis 23123 bekommen" antwortet. Das ist aber nicht überall standardmäßig aktiviert und muss natürlich auf beiden Seiten beherrscht werden. Dazu kommen noch diverse andere Probleme von TCP in Zusammenhang mit schnellen, kleinen Paketen - wenn du mal eine Suchmaschine deiner Wahl anwirfst, solltest du zu den Themen TCP ACK (Acknowledgement), Selective ACK, High Performance TCP, usw. finden.

Letztlich beseitigt das aber auch nicht alle Probleme - viele kleine Pakete sind insbesondere über TCP richtiger "Stress" für Server, Paketfilter+Proxies in Firewalls, usw. Damit kann man manche Systeme schon richtig in die Kniee zwingen!

Wenn du noch Fragen hast, kannst du dich gerne wieder melden - aber ich denke das grundlegende Problem ist klar?!
 

geschrieben am 30.10.2007 um 10:18 von geller1a

Erst einmal vielen Dank für die Antwort.
Grundsätzlich habe ich die Antwort schon verstanden. Ich glaube allerdings, dass ich meine Frage nicht präziese genug formuliert habe.

Wenn man per netio eine Messung ohne Vorgabe der Blockgroesse macht, führt das Tool mehrere Einzelmessungen durch. Ich erhalte eine Transferrate von

Code:
114912 KByte/s Tx
bei der Blockgroesse von 16k.
Soweit so gut.
Gebe ich bei der Messung eine bestimmte Blockgroesse vor, so erwarte ich eigentlich das gleiche Ergebnis, da ja eine identische Messung gefahren wird.
Statt dessen ergibt sich eine um den Faktor 10 schlechtere Transferrate!
Code:
12324 KByte/s Tx


Natürlich ist die Transferrate von der Blockgroesse abhängig (siehe Beitrag von bewa), aber warum unterscheiden sich die Ergebnisse bei identischer Blockgroesse je nachdem ob die Option '-b' vorgegeben wird oder nicht?
 

geschrieben am 30.10.2007 um 16:52 von geller1a

mea culpa

Argh,
man sollte halt nicht Äpfel mit Birnen vergleichen. Die Vorgabe der Option '-b 16' setzt die Blockgrösse halt auf 16 Byte. Wenn man das mit 16 KByte (= 16000 Byte) Blöcken vergleicht...

Sorry
 

geschrieben am 03.11.2007 um 12:15 von bewa

Re: mea culpa

"geller1a" wrote:
Argh,
man sollte halt nicht Äpfel mit Birnen vergleichen. Die Vorgabe der Option '-b 16' setzt die Blockgrösse halt auf 16 Byte.


Hehe, kommt vor. :-)

Es gibt übrigens tatsächlich Anwendungen, in denen dermaßen kleine Pakete häufiger verschickt werden - wenn auch in der Regel nicht mit so hohen Durchsätzen. Ein Beispiel wäre SS#7 over IP - dafür nimmt man dann aber in letzter Zeit weder UDP, noch TCP, sondern SCTP, da es für diese Zwecke entwickelt wurde.
 

[ Dieses Thema im Live-Forum aufrufen ]

Sie befinden sich im Archiv des Forums.
Zum Forum

Archiv erstellt mit phpBB2HTML 0.1 - Foren in statisches HTML umwandeln © 2006 Mirko Kulpa

 

 
© 2004-2023, network lab - we make your net work - Netzwerkforum
aktualisiert am 13.05.2019