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:
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:
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
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 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!
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
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 ]
|