10GBE - Vorteile auch für kleine Dateien?

[LukS]

Quelle ist üblicherweise eine Client-Workstation mit SSD (häufig sogar M2), Ziel ein Windows Server mit 2-4 Festplatten und einer Cache-SSD.

Die Info wäre vorher schon interessant gewesen...

Es wäre halt zu klären ob der Server lokal mehr als 30MB/s bei demselben Datensatz schaffen könnte, z.B. beim Kopieren auf eine externe SSD.

Das wäre dann auch mein nächster Vorschlag gewesen. Schafft der Server lokal mehr?

 

[Grimba]

Was heißt Bandbreite? Wenn jedes verfügbare Paket genutzt wird, ist die ja auch ausgenutzt, auch wenn nur 30MB/s übertragen werden.

Dann hättest du in dem Moment ja bei 1Gbit/s ca. 70-80 MegaByte/s Protokoll-Overhead bei einer Übertragungsgeschwindigkeit von 30 MegaByte/s, das müssen dann schon sehr sehr viele sehr kleine Dateien sein. Und dann kommt irgendwann eher die Verbindungsgrenze. I/O Overhead der Festplatte im System zählt ja nicht zur Netzwerkbandbreite.

Ich vermute eher, dass hier der Physische Speicher das Problem ist. In deinem Benchmark ist er es jedenfalls nicht.
Denn das ist ja die erste Station, bekomme ich pro Sekunde möglichst viele Zugriffe, und dann kommt erst das Netzwerkprotokoll und schaut mal, was es damit macht. Wenn hier schon der erste Flaschenhals ist, kann die Bandbreite so hoch sein, wie sie will, mehr kommt halt von der Platte nicht an. (oder wird auf der Gegenseite nicht schnell genug geschrieben, kommt auf's gleiche raus.)

 

[Rickmer]

Dann hättest du in dem Moment ja bei 1Gbit/s ca. 70-80 MegaByte/s Protokoll-Overhead bei einer Übertragungsgeschwindigkeit von 30 MegaByte/s, das müssen dann schon sehr sehr viele sehr kleine Dateien sein. Und dann kommt irgendwann eher die Verbindungsgrenze. I/O Overhead der Festplatte im System zählt ja nicht zur Netzwerkbandbreite.

Naja...

Das einzige was bei TCP je Verbindung nur einmalig passiert ist das 3-Way-Handshake für den Verbindungsaufbau vorneweg (Stichwort: SYN) und das Handshake für den Verbindungsabbau (Stichwort: FIN) hintendran. Das sind jeweils 3 Pakete, die bei kleinen Dateien, die in wenige Pakete oder gar in nur eines passen (~1500 Byte abzüglich Header), natürlich entsprechend als Overhead durch das Netzwerk laufen.

Wenn die Dateien in eine MTU rein passen kann 2/3 der Leitung als Overhead schon passen. Oder mehr noch - siehe meine Benchmarks mit reinen 4K Zugriffen, mehr als 10MB/s über 1G war da nicht drin.

 

[xxMuahdibxx]

@Rickmer Naja MTU größe ist doch knapp 1500 byte ... also sooo viele kleine Datein wird man beim 4k Test auch nicht haben .. besonders da 4k schon 3 MUT´s groß ist wird der Overhead nicht so riesig sein.

 

[Grimba]

Das wäre dann aber echt extem.
Zumal SlowStart ja eigentlich verhindert, dass in diesem Fall die gesamte Leitung genutzt werden kann. Eh Witzlos, bei Payload < MTU.
GERADE bei kleinen Dateien, die in eine MTU passen, kann die Übertragung ja gar nicht in fahrt kommen, es sei denn, du machst mehr Verbindungen gleichzeitig auf. Für die gilt dann aber einzeln jeweils das gleiche.
Dass der Protokoll-Overhead die gesamte Pipeline der Leitung füllt, halte ich an dieser Stelle für eine sehr gewagte These.

Genau das meine ich ja: Bei 10G werden vermutlich einfach mehr gleichzeitige Verbindungen zur Verfügung gestellt, weil die 10fache Bandbreite zur Verfügung steht. (Quark) Und der SATA-Benchmark zeigt, dass deine SSD die geforderten Daten auch zur Verfügung stellen kann bzw. auf der Gegenseite speichern kann. Dadurch wird die Übertragung bei 10G schneller.

 

[Gee858eeG]

Wenn du also die vorhandene Bandbreite nicht ausnutzen kannst, bringt es nichts, sie noch weiter zu verbreitern.

Nur weil bei einer 1Gbit Leitung 30MB/s an reinen Daten übertragen werden, heißt es nicht, dass die Verbindung nicht maximal genutzt wird!

 

[Grimba]

Doch natürlich. Die Gegenprobe ist ganz einfach: Du machst ein ZIP der Dateien und kopierst die ZIP-Datei und dann ist erstaunlicherweise die Übertragung weit schneller. Hier verzettelt sich also das, nein DIE verwaltenden Protokolle an den kleinen Dateien und den X-Verbindungen dafür. PLUS I/O Overhead der Platten selbst auf beiden Seiten. Das heißt nicht, dass die Leitung ausgelastet ist.

 

[Raijin]

Es ist ja auch eine Frage was man als "kleine Dateien" definiert. Damit der TCP-Overhead signifikanten Einfluss auf die Übertragungsgeschwindigkeit hat, müssen die Dateien dicht an der MTU liegen.

Dateigröße / KB	Anzahl Pakete (netto, exkl. Handshake)	Anzahl Pakete (brutto, inkl. Handshake)	Effizienz (netto/brutto)
1	1	7	0,14
4	3	9	0,33
8	6	12	0,5
25	17	23	0,74
50	34	40	0,85
100	67	73	0,92

Schon ab 8 KB kleinen Dateien sind wir bei 50% Nutzdatenrate, ab 25 KB geht's dann Richtung 75% und ab 100 KB sind wir schon jenseits der 90%. Wenn man also zig Tausende von 1 KB txt-Dateien durch die Gegend kopiert, merkt man das sicherlich deutlich. Definiert man "kleine Dateien" aber mit 50 KB, zB Tausende von jpg, fällt der Overhead durch das TCP-Handshake kaum noch ins Gewicht.

 

[Gee858eeG]

Die Gegenprobe ist ganz einfach: Du machst ein ZIP der Dateien und kopierst die ZIP-Datei und dann ist erstaunlicherweise die Übertragung weit schneller

Die Protokollkommunikation geht über die die gleiche Verbindung, von daher darf man nicht dem Trugschluss verfallen, dass wenn beispielsweise 30MB/s als aktuelle Übertragungsrate angezeigt werden, dass dann noch 970 MB/s "frei" wären. Dein Beispiel untermauert eigentlich nur meine Aussage.
Neben dem von Raijn schön aufgelisteten Overheadeinfluss, kommt dann auch noch der Einfluss der tasächlichen Übertragungsgeschwindigkeit der Nutzlast hinzu. 1KB braucht bei einer 1Gbit Leitung 8µs, wohingegen dies bei einer 10GBit leitung 0,8µs dauert. Dementsprechend kann das Handling des nächsten Datenpakets bei Steigerung der Übertragungsgeschwindigkeit früher anfangen.

 

[Grimba]

Die Protokollkommunikation geht über die die gleiche Verbindung,

Aus SMB-Sicht vielleicht. Aus TCP Sicht ganz sicher nicht.

von daher darf man nicht dem Trugschluss verfallen, dass wenn beispielsweise 30MB/s als aktuelle Übertragungsrate angezeigt werden, dass dann noch 970 MB/s "frei" wären.

Ok, bei deinen Werten wären wir dann bei der 10Gbit/s Verbindung in etwa. Und bei 30MB/s Overhead AUF der Leitung von fast 1Gbyte/s ist absurd bei Protokollen, die für die Datenübertragung in größeren Infrastrukturen gedacht sind, wie SMB. Du musst dich mal frei machen davon, dass in einer Situation mit sehr viel Overhead die gesamte Zeit hindurch auch tatsächlich pausenlos Payload übertragen wird.

Dein Beispiel untermauert eigentlich nur meine Aussage.
Neben dem von Raijn schön aufgelisteten Overheadeinfluss, kommt dann auch noch der Einfluss der tasächlichen Übertragungsgeschwindigkeit der Nutzlast hinzu. 1KB braucht bei einer 1Gbit Leitung 8µs, wohingegen dies bei einer 10GBit leitung 0,8µs dauert.

Auch das hängt davon ab, womit du überträgst. Schneller werden die Daten in der Leitung nicht. Die Geschwindigkeit im Medium bestimmt nur die Beschaffenheit selbst, und die direkten Gegenstellen. Die gesamte Logik, was eigentlich ein Datenpaket zu sein hat, und was damit zu tun ist (und zwar pro Ebene), bestimmt zum Großteil der Rechner, siehe OSI Modell.

Dementsprechend kann das Handling des nächsten Datenpakets bei Steigerung der Übertragungsgeschwindigkeit früher anfangen.

Darauf würde ich mich sogar einlassen, dass in einem Netzwerk mit nur 10Gbit/s Komponenten die einzelnen NICs einfach flotter sind, wodurch sicher etwas Durchsatz rausgeholt werden kann.

 

[Gee858eeG]

Du musst dich mal frei machen davon, dass in einer Situation mit sehr viel Overhead die gesamte Zeit hindurch auch tatsächlich pausenlos Payload übertragen wird

Das war nicht meine Aussage
Auch deine restlichen Ausführungen führen etwas an meinen Aussagen vorbei. Wie zum Beispiel

Schneller werden die Daten in der Leitung nicht.

Das habe ich halt nicht geschrieben.

Gut die 970MB/s waren falsch, meinte natürlich 1Gbit/s-27MB/s = 98MB/s .

 

[Grimba]

Doch, in etwa ist das deine Aussage, denn wenn die restlichen (jetzt) 98MB/s nicht frei sind, was dann?
Durch die verschärfte Overheadsituation erzeugst du auch sehr viele Wartezeiten. Und Handshake Pakete sind keine großen Datenmengen. Was ist also auf der Leitung, wenn sie dann eben nicht frei ist?
Wenn du jetzt noch dazu nimmst, dass das alles die gleiche Verbindung ist, schlimmstenfalls TCP, dann kommst du ja niemals auf Geschwindigkeit, wenn du hier nicht mehrgleisig fährst.

1KB braucht bei einer 1Gbit Leitung 8µs, wohingegen dies bei einer 10GBit leitung 0,8µs dauert.

Hier auch wieder: Du hast es schon in etwa geschrieben. Diese Aussage gilt nämlich nicht ohne weiteres und vorallem nicht allgemein. Und daher sage ich, nein, die Leitung wird nicht schneller. Sie wird halt breiter. Es kommt nur darauf an, was alle teilnehmenden Kommunikationspartner untereinander ausgehandelt haben und auf was dann gleichzeitig an Ressourcen zugegriffen werden kann. Egal ob Netzwerk-Verbindung oder Daten-I/O.

 

[Gee858eeG]

Ich gebe zu, ich kenne die Bandbreite eines einzelnen Impulses bei 10Gbit-Verbindungen nicht. Bezeichnen wir die Datenmenge pro Impuls bei 10GBit Ethernet mit X Bit und dementsprechend bei 1Gbit Ethernet = X/10 Bit (du sagtest, ja die Leitung wird breiter, damit sollten wir uns soweit noch einig sein).
Die Übertragungsdauer ist im allgemeinen bestimmt durch Zeit_overhead + Zeit_nutzdaten. Angenommen Daten_Overhead = X Bit und Daten_Nutzen = X Bit
Dann braucht die 1Gbit Leitung 10 Impulse für Overhead und 10 Impulse für Daten = 20.
Die 10Gbit-Leitung benötigt insgesamt 2 Impulse. Bei gleicher Pulsfrequenz benötigen wir also bei einer zehnmal so breiten Leitung lediglich 1/10 der Zeit. Es macht also selten einen Unterschied, ob die Leitung breiter oder schneller ist. Dies ist nur in Grenzfällen der Fall. Ich hatte vorher einfachheitshalber 1KB als X angenommen. Und wenn wir uns das von dir berechtigerweise genannte OSI Modell noch ein mal angucken, sollte klar werden, dass auch TCP-Verbindungen nicht am Kabel vorbei kommunizieren können und somit Bandbreite aufbrauchen.

Zu den anderen Punkten:

• Der Overhead nimmt Kapazität der Leitung in Anspruch, aber nicht zwingend die gesamte restliche Kapaztität, denn der restliche Geschwindigkeitsverlust sollte sich darauf zurückschließen lassen, dass die Teilnehmer aufeinander warten und die Protokolldaten verarbeiten.
• Daten werden nicht schneller in einer Leitung, weil Lichtgeschwindigkeit und so. Die Datenübertragung kann dennoch sehr wohl schneller ablaufen. Ich dachte du spieltest darauf an

_________________________

Nachtrag:

Die Protokollkommunikation geht über die die gleiche Verbindung

Aus SMB-Sicht vielleicht. Aus TCP Sicht ganz sicher nicht.

Dass Nicht-Nutztraffic in der gleichen Leitung ist, ist trivial, wo soll er auch sonst sein?

Viel mehr habe ich nicht mehr zusagen, wenn dir jetzt noch nicht klar ist, was ich mit meiner ursprünglichen Aussage in #26 gemeint habe, dann wird es das auch nach weiteren Erklärungen nicht mehr. War jetzt genug off-topic meiner Meinung nach

 

[Grimba]

Das ist aber nur das Potential der Leitung.

Natürlich kann ich 1en und 0en schneller, bzw. mehr zum gleichen Zeitpunkt übertragen.

Damit ist aber noch nicht darauf eingegangen, was es mit diesen Bits auf sich hat. Ohne Protokoll haben diese ja keine Bedeutung. Und da hängt dann eben alles mögliche an Zeitfressern dran. Zusätzlich würde ich behaupten, dass die Leitungsbeschaffenheit innerhalb eines lokalen, kabelgebundenen Gigabit-Netzwerks (jetzt mal mögliche topologische Flaschenhälse außer Acht gelassen), eine eher untergeordnete Rolle spielt, was die Übertragung des 1kb angeht.

Dass Nicht-Nutztraffic in der gleichen Leitung ist, ist trivial, wo soll er auch sonst sein?

Wenn du mit der "Verbindung" die Leitung im Sinne von Kabel meinst, klar.
Mit Verbindung kann man eben, und so hab ich es verstanden, eben die bestehende, hier SMB Verbindung meinen. Bei 30MB/s werden hier schon mehrere kleinere Dateien übertragen. Und aus Sicht einer TCP Verbindung ist das (zumindest) eine Datei, eine Verbindung, ein Übertragungsvorgang, fertig, next. Du hast es also in jedem Fall aus TCP-Sicht mit mehreren Verbindungen (oder zumindest Übertragungsvorgängen) zu tun. "Protokollkommunikation" ist halt nicht gerade eindeutig gewählt als Begriff. Eben wegen des OSI Modells.

 

[RalphS]

Persönlicher Erfahrung (und Einschätzung) nach bringt es mit SMB nicht viel.

Besser: Dafür sorgen, daß "kleine" Dateien eben nicht klein sind. Selbst wenn man hergehen würde und eine on-the-fly Komprimierung mit Kompressionsrate 0 anstrengen würde (effektiv: sowas wie tar) und diesen Datenstrom übers Netzwerk schickt, hat man signifikantere Vorteile, trotz pre- und postprocessing.

Unter Windows wäre ggfs zu fragen, ob man die ganzen kleinen Dateien erst in ein Archiv schreiben kann, bevor man dieses übers Netzwerk schickt. Wie gesagt, Kompressionsrate ist egal. Es muß nur "mehr" am Stück durchgehen.

Unter SMB liegt da meines Wissens die Blockgröße bei 1MB. Vielfache davon wären entsprechend Optimum. Und zur Sicherheit: "MB" nach PC-Verständnis, nicht nach Menschenverständnis, da sich bei PCs niemand für 10-hoch-irgendwas interessiert.

 

[Miuwa]

Aus SMB-Sicht vielleicht. Aus TCP Sicht ganz sicher nicht.

Sorry, wenn ich hier nen alten Thread ausgrabe, aber:
Warum sollte smb für jede Datei ne eigene TCP Verbindung aufbauen anstatt die bestehende zu nutzen (oder eine der bestehenden, SMB3.0 kann mehrere TCP verbindungen parallel nutzen)? Das macht doch nicht den geringsten Sinn.

Verwechselst du das vielleicht mit HTTP1.0, wo wirklich traditionell, jede neue Anfrage über ne separate TCP connection abgewickelt wurde? Oder hab ich deine Aussage missverstanden?

@Topic: Eine Sache, die ich erstmal checken würde ist, welche Protokollversion genutzt wird (Get-SmbConnection). Scheint immer noch einige Serversystem zu geben, die standardmäßig SMB1 nutzen (bzw. wurden die halt mal so eingerichtet und seid dem nicht mehr geupdated). Den Unterschied zu SMB2 und später hat man IIRC schon deutlich gemerkt.