[Sammelthread] 10Gbit Homenetzwerk

[AxelMertes]

@danielmayer

Ich habe mich nun für die Emulex OCE14104-NX entschieden (ist ja für einen Windows Server, da laufen die super). War deutlich günstiger als die Intel und ich habe bislang sehr gute Erfahrungen mit dem 2 Port Modell, sowie den dual 4GBit FC HBAs von Emulex gemacht. Die halten, was sie versprechen und gingen früher als "Intel-Killer" durch.
Zur Kopplung an den Brocade VDX6720 habe ich original Brocade Active Copper Kabel mit 3m und 5m geordert, da sollten die Bandbreite noch gehalten werden. Alle längeren Verbindungen laufen dann über Brocade SFP+ mit OM3. Die Clients nutzen die Connect X2 Mellanox Karten. Auch da bislang keine Probleme.

An der Stelle gefragt:
Bringen die Jumbo-Packets noch nennenswert etwas an Durchsatz?
Ich hab es noch nicht getestet, und da einige der Clients über diese Links auch mit dem Internet kommunizieren, bin ich da vorsichtig ob das so alles klappt... Gibt es da nicht trunkated Packages oder wie wird das verhindert?
Bei reinkommenden Paketen dürfte das kein Problem sein, aber wie sieht es in der anderen Richtung aus?

 

[Falo999]

In der CT 20/2016 auf Seite 70 wurden 2 Mini ITX Boards mit Xeon D-1507 bzw 1521 CPU getestet die auch 10GbE haben.

Dort konnten die nur mit mehrfachen Verbindungen und Jumboframes auf normale Werte von 8,9Gb/s kommen.

Dort haben sie auch die billigen Mellanox 10GbE Karten als Gegenstellen zu den obrigen Boards getestet hat aber die Verbindung war extrem unzuverlässig und nicht brauchbar.

 

[danielmayer]

Ich hatte irgendwo mal Durchsatztests gepostet, hier oder im 10GBase-T-Schwesterthread.
Jumbo hat was gebracht, bzw. bringt überhaupt nur was, bei großen Dateitransfers (Filme). Da hatte sich der Testdurchsatz von 4-5Gbit zu gut 7G gebessert, glaube ich.
10G gingen im Einzeltest nie, das dürfte tatsächlich eher bei Multiverbindungen relevant sein.

 

[AxelMertes]

In der CT 20/2016 auf Seite 70 wurden 2 Mini ITX Boards mit Xeon D-1507 bzw 1521 CPU getestet die auch 10GbE haben.

Dort konnten die nur mit mehrfachen Verbindungen und Jumboframes auf normale Werte von 8,9Gb/s kommen.

Dort haben sie auch die billigen Mellanox 10GbE Karten als Gegenstellen zu den obrigen Boards getestet hat aber die Verbindung war extrem unzuverlässig und nicht brauchbar.

Habt Ihr denn schlechte Erfahrungen mit den billigen Mellanox Karten?
Unsere laufen bislang recht gut und die Verbindung zu den Emulex-Karten via dem Brocade VDX6720 Switch klappt auch bestens.

Ich habe übrigens heute bei Ebay für ein 10er Pack je 10 US$ pro Karte bezahlt, dazu 15 US$ je 5m Brocade Active Copper SFP+ 10 GbE/FCoE Kabel. Dazu dann Porto und 19% Einfuhrumsatzsteuer (die man ja bei gewerblicher Nutzung wieder zurückbekommt). Da kann man nicht meckern... Hatte ich erwähnt das manche die Mellanox Karten inzwischen im Hunderterpack verkaufen...?

Den VDX6720 gibts inzwischen unter 900 US$ mit 60 Ports freigeschaltet. Von wegen 10 GbE Switche seien unverhältnismäßig teuer... ;-)

Ich habe auch die ersten Baremetal Switche mit z.B. 24 bis 40 x 40 GbE QSFP Ports zu Preisen deutlich unter 2000 US$ gesehen. Aber da braucht es dann ein Net OS und da bin ich noch nicht sicher, wie das endet, die kosten schnell mal 1000 Euro pro Jahr Lizenzgebühr. Facebook ja ein eigenes OS geschrieben und im Grunde auch die Switche entwickelt. Aber haben sie das OS auch freigegeben? Macht Facebook bei manchen Produkten ja... Da müsste ich mal tiefer einsteigen, ob es für diese Switche sozusagen eine Free OS gibt. Wenn ja, wäre das der Hammer.

 

[pumuckel]

keine Beschwerden hier (allerdings von HP auf Mellanox umgeflashed)

für den Preis gibts da so garnix zu meckern wer da lieber die Intel X520 nimmt und viel mehr zahlen mag, dem kann auch geholfen werden : Refurbished Networking Equipment - Fully Tested

 

[AxelMertes]

Ich hatte irgendwo mal Durchsatztests gepostet, hier oder im 10GBase-T-Schwesterthread.
Jumbo hat was gebracht, bzw. bringt überhaupt nur was, bei großen Dateitransfers (Filme). Da hatte sich der Testdurchsatz von 4-5Gbit zu gut 7G gebessert, glaube ich.
10G gingen im Einzeltest nie, das dürfte tatsächlich eher bei Multiverbindungen relevant sein.

Ich denke ich probiere das mal. Vermutlich setze ich ein echtes 1 GBit Netz für Internet-Zugriff auf und das 10 GbE für rein internen Verkehr in einem anderen LAN und lasse darüber die SMB Shares laufen. So müsste das eigentlich gut trennbar sein. Oder würdet Ihr das anders lösen?

 

[besterino]

Nö, hab ich genauso: 1gbit 1500er MTU Standardnetz für normalkram, 10gbit 9000er MTU fürs "StorageNetz".

 

[Lynxx]

Error Code 10 ? RSS disabled ..

Nach langem Überlegen habe ich mir auch 2x Mellanox ConnectX2 besorgt (26€ das Stück) und günstige Kabel dazu gefunden, dann gestern eingebaut und Windows meckert, der Netzwerk-Treiber kann nicht gestartet werden (Code 10).
Dann habe ich mir erstmal einen Wolf gesucht aber leider nicht passendes gefunden, ausser jede Menge andere Leute mit dem gleichen Problem. Habe dann sogar eine Intermediate Firmware 2.9.1200 erstellt und geflashed, aber auch das hat nicht geholfen.
Ein Blick ins Systemlog brachte dann die Lösung, RSS (Receive-Side Scaling) war nicht aktiviert, standardmässig ist es aktiviert, aber viele Optimierer/Netzwerk-Speedup-Tips schalten es häufig aus.
Einschalten kann man es per:
netsh int tcp set global rss=enabled

oder die .reg ausführen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters]
"EnableRSS"=dword:00000001

Dann musste ich zwar noch zum alten Bios zurück (2.9.1000), aber jetzt läuft alles so wie es soll.

Edit:

Ich denke ich probiere das mal. Vermutlich setze ich ein echtes 1 GBit Netz für Internet-Zugriff auf und das 10 GbE für rein internen Verkehr in einem anderen LAN und lasse darüber die SMB Shares laufen. So müsste das eigentlich gut trennbar sein. Oder würdet Ihr das anders lösen?

Ich hab das jetzt genau so, alle Rechner haben normale Verbindung untereinander und Internet-Zugriff übers 1 GBit Netz und ein 10 GbE für großen Datentransfer Server<->Client

2nd Edit:
Die Meldung im System-Log lässt vermuten das man RSS für die Karte auch ausschalten kann, nur finde ich in den Einstellungen nichts dazu, nur die Maximal-Anzahl der RSS-Processors und Queues kann ich einstellen.
Falls jemand weiss wie man RSS für die Karten ausschalten, bitte posten.

3rd Edit:
Mhhh, vielleicht einfach beide auf 1 setzen? Werde ich nachher mal testen ...
Nein das war es nicht, aber es gibt eine Option Receive-Side Scaling enabled/disabled. d0h

 

[pumuckel]

also selbst mit der Stock HP FW meckerte Win nur über 2 Sachen (protokolle welche fallback haben und das OS auf der karte nicht in Stock kann) , aber Treiber liefen (stock und nativ)

getestet unter win7/win8/win10/WS 2012R2/ esxi/omv/Freenas

spielt halt bei zu alter FW die native mellanox auf (aber auch alt) ... ich hab 2.9.1200, ansonsten kann man deren FW selber zusammenstellen

dazu: https://www.mellanox.com/page/winof_matrix?mtag=windows_sw_drivers&ssn=4ssh8ao3fi9ipje4lfebal9760

wichtig auch : Mellanox WinOF nicht Mellanox WinOF2 nutzen ! (wenn überhaupt, da native Treiber in Win/linux/bsd)

 

[AxelMertes]

Das ist jetzt etwas verwirrend. Da ist Win 10 nicht als kompatibel gelistet (WinOF). Ich nutze es aber unter Win 10 bislang völlig ohne Probleme...

Ich hatte den Eindruck es ist eine Art Universaltreiber. Oder gehen nur bestimmte Features nicht, die wir nicht benutzen? iSCSI z.B. habe ich noch nicht verwendet - ist auch nur bedingt wahrschenlich.

Windows Server 2012 R2 (x64 only)
Windows Server 2012 (x64 only)
Windows Server 2008 R2 (x64 only)
Windows 8.1 Client (64 bit only)
Windows 7 Client (64 bit only)

4.80 (See the Archive tab)

ConnectX®-2 EN 2.9.1200 and above
ConnectX®-2 VPI 2.9.1000 and above


Hier ist was meine Karten so machen:

Driver Version : 5.10.11345.0
Firmware Version : 2.9.1200
Port Number : 1
Bus Type : PCI-E 5.0 Gbps x8
Link Speed : 10.0 Gbps/Full Duplex
Part Number : MNPA19-XTR
Device Id : 26448
Revision Id : B0
Current MAC Address :
Permanent MAC Address :
Network Status : Connected
Adapter Friendly Name : LAN-Verbindung 10 GBit
IPv4 Address :
Adapter User Name : -
Adapter PKey : -

Warum auch immer, für mich läuft das bislang super.

Welche Treiberversion nutzt ihr?

WinOF 5.25 ist NUR noch für Microsoft Server 2016 gelistet.
WinOF 5.22 und 5.10 immerhin für Server 2012 R2/2012/2008 R2, Win 10, Win 8.1 und Win 7 - alles in x64 versteht sich.
Die Kombination MNPA19-XTR mit Windows 10 gibt es offenbar nicht. Oder wird das von Mellanox für die alten Karten nur nicht mehr gelistet, weil sie die nicht mehr verkaufen?
Wie sind Eure Erfahrungen?

 

[pumuckel]

zu Win10/WS2016 kann ich wenig sagen (da ich nur einen rechner noch auf Win hab und der ist win7) ... aber ich hab auch auf dem testsystem mit win10 die günstigen HP Mellis getestet

spuckt zwar in der Ereignissanzeige/Win Protokoll/System einige Errors aus, aber läuft und für den Preis auch gut
... die nativen treiber reichen schonmal um single SSDs auszulasten

und ja ich sehe wie günstig die in den USA sind, leider nicht hier in der EU : met-server-parts | eBay

solange man aber unter den Import Charges (per Ebay global program) bleibt, teils günstiger (werden dort aber ausgewiesen im Punkt "import charges")

... aber auch (für hardcore intel lover) wie oben geschrieben gibts die X520 single auch zu um die 30 Dollar + ship + import bei Natex



...immer bedenken, für ne Gbit Karte zahlt man in da auch schon 10+€ und für ne Quad GBit 40€

 

[AxelMertes]

Hallo Zusammen,

hier eine kleine "Denksportaufgabe" ;-)

Ich plane gerade, wie ich das mit den 1500er/9000er MTUs bei den verschiedenen Clients am Server löse, denn da gibt es folgende Problemstellung, das ich hier mal abstrahiert darstelle:

A = Server hat sowohl n * 1 GbE als auch n * 10 GbE Ports
B = Clients haben 1 * 1 GbE und 1 * 10 GbE Ports
C = Clients haben nur 2 * 1 GbE Ports (keine Option auf 10 GbE)
D = Clients haben nur 1 * 1 GbE Port (keine Option auf 10 GbE)

Zur Verbindung stehen ein nativer 10 GbE Switch sowie ein 1 GbE Switche mit 10 GbE Uplink Ports zur Verfügung.

Clients sollen auf den Storage über 9000er MTU vorzugsweise via 10 GbE zugreifen.
Clients sollen auf das Internet über 1500er MTU über 1 GbE zugreifen.

Bei Clients B und C wäre das z.B. über zwei VLANs und/oder seperate IP Adressräume auf den unterschiedlichen Karten (1 GbE + 10 GbE oder 1 GbE + 1 GbE) realisierbar. Die Metrik würde dem Intranet den Vorzug geben, externer Internet-Traffic darf langsamer sein.

Bei Clients D müsste nun beides über dieselbe Karte geregelt werden:
Eine mögliche Option könnte ein drittes VLAN sein, diesmal mit 1500er MTU und einer zusätzlichen Verbindung zum Server und zum Internet.
Nachteil: Diese Clients D könnten die Clients B und C im Netz nicht sehen - was aber wegen Renderfarm, Peer-to-Peer Transfers etc. auch dringend möglich sein sollte. Hat jemand eine schlaue Idee dazu?


Ich könnte auch alles im selben IP Adressraum und im selben VLAN betreiben, die 1 GbE 1500er MTU und 10 GbE 9000er MTU Serverports aber mit unterschiedlichen IP Adressen angeben. Dann kann man die SMB Shares über die IP Adressen verbinden und somit die Karte des Servers "addressieren". Das funktioniert, wie ich gerade ausprobiert habe. Die Clients D müssten dann wohl auf 1500er MTU laufen und auf den Server über die 1 GbE Ports (alle mit 1500er MTU) zugreifen, richtig?

Das heißt dann auch, die Clients C mit 2 * 1 GbE Ports holen sich für Storage über eine 1 GbE Karte mit 9000er MTU die Daten via 10 GbE Uplink zwischen den Switchen von der 9000er MTU 10 GbE Verbindung des Servers, mit der anderen 1 GbE Karte mit 1500er MTU dann das Internet.

Seht Ihr da ein Problem?

Wenn ich die SMB3 Shares ordentlich vom Server mounte - also penibel auf die IP Adresse (statt NETBIOS Namen) der zu verwendenden Karte vom Server achte (1 GbE 1500er oder 10 GbE 9000er) - ist das kein Problem.
Kritisch könnte es im Peer-to-Peer Betrieb zwischen den Clients werden, wenn z.B. über NETBIOS agiert wird und die Namensauflösung nicht eindeutig eine bestimmte Netzwerkkarte ergibt, insbesondere wenn Client D auf z.B. Client A zugreift und Client A 9000er Pakete an der 1500er Port von Client D zu schicken versucht. Hat jemand eine Idee, wie man das am besten löst?
Vielleicht könnte man überall NETBIOS deaktivieren und LMHOSTS Files hinterlegen, die jede Kombination gültig vorschreiben, sodass z.B. Client D den Client B nur via dessen 1500er MTU Netzwerkkarte sieht und umgekehrt. Ist das ein guter Ansatz oder geht das anders und leichter?
Es ist ein gehöriger Aufwand, die LMHOSTS vorzugeben und in der Netzwerksuche werden am Ende doch alle gefunden.


Ich hatte bislang z.B. getrennte Metadaten Netzwerke für FC-SAN, aber die waren über IP Adressräume klar getrennt, Metrik manuell.


Ich denke das neue SMB3 Protokoll kann zwar Kanalbündelung und auch Fallback zwischen 1 GbE und 10 GbE, wird aber kaum das MTU Problem lösen können (wenn Jumbo-Frames ins Internet geleitet werden etc.). Oder habt Ihr da noch einen Trick parat?

Ich weiß, hört sich ziemlich komplex an, ist es aber eigentlich nicht...

 

[Killer Chris]

Die MTU ist auch abwärtskompatibel / aushandelbar und nicht fix.

Ein System mit MTU1500 kann auch mit einem System mit MTU9000 sprechen, mach es dir nicht komplizierter als nötig ;-)

Häng alles in ein IP Netz, bind die Systeme mit 10GBit Nic mit nur dieser an und die mit 1GBit mit selbiger.

Dann sprechen MTU9000 auf beiden seiten auch so und wenn einer nur weniger kann dann dieser eben mit weniger. Heißt nicht umsonst Maximum Transmission Unit und gibt nur an, wie groß die Pakete maximal sein können und schreibt es nicht fix vor.
Dein Router spielt da auch nicht quer, wenn du ADSL nutzt spricht er nach außen sogar nur mit einer MTU von 1492, also alles halb so wild.

 

[AxelMertes]

Die MTU ist auch abwärtskompatibel / aushandelbar und nicht fix.

Ein System mit MTU1500 kann auch mit einem System mit MTU9000 sprechen, mach es dir nicht komplizierter als nötig ;-)

Häng alles in ein IP Netz, bind die Systeme mit 10GBit Nic mit nur dieser an und die mit 1GBit mit selbiger.

Dann sprechen MTU9000 auf beiden seiten auch so und wenn einer nur weniger kann dann dieser eben mit weniger. Heißt nicht umsonst Maximum Transmission Unit und gibt nur an, wie groß die Pakete maximal sein können und schreibt es nicht fix vor.
Dein Router spielt da auch nicht quer, wenn du ADSL nutzt spricht er nach außen sogar nur mit einer MTU von 1492, also alles halb so wild.

Vielen Dank für den Hinweis!!!

Das hatte ich noch nie gewagt zu testen ;-) aber sehr gut zu wissen. Probiere ich nachher mal aus, bin gespannt wie das klappt und wie sich die Performance ändert.
Damit könnte ich dann doch eigentlich ALLE meine Ethernet Ports und Switche auf MTU 9000 einstellen und es müsste immer noch mit dem Internet funktionieren - richtig?
Das wäre in der Tat eine gute Sache!

Übrigens habe ich bei meinen Connext X2 Mellanox Karten und Windows 10 Clients mal die Ereignisanzeigen durchgeschaut und keinerlei Fehlermeldungen bezüglich Ethernet/Mellanox etc. gefunden - es läuft soweit alles super. Keine Ahnung was andere für Probleme in der Kombination haben.

 

[besterino]

Mal ne dumme Frage - auf welcher Ebene wird denn die MTU ausgehandelt?

Im Zweifel doch mit der direkten Gegenstelle, also jeweils zwischen NIC und Switch, oder doch nicht?

Jedenfalls heißt es doch, dass sämtliche Komponenten zwischen PC1 und PC2 die Jumbos können müssen, ansonsten wird fragmentiert bzw. handeln die Komponenten eben die niedrigere MTU aus. Auch hatte ich das Phänomen, dass ein älterer Switch gerne mal in die Knie gegangen ist, wenn an den Kisten daran unterschiedliche MTUs eingestellt waren - vermute mal, das hat dann irgendwo irgendwie zu viel Last erzeugt wenn einer mit 9000 rumballern will und die (Layer-3-)Gegenstelle nur 1500 kann...?

Bin gerade zu faul zu googeln, vielleicht weiß das hier ja jemand.

 

[Killer Chris]

Die MTU wird auf Layer 2 ausgehandelt, also muss auch der Switch dies unterstützen.

Es kann bei älteren oder schwachen Switches durchaus vorkommen, das diese in der Data Backplane oder im Cache schnell dicht sind, gerade wenn sie fragmentieren müssen weil nicht der gesamte Pfad die selbe Größe kann.

Dann wird jedes Paket fragmentiert, es kommt weiterer Overhead durch die Header dazu, aus einem 9000er Packet werden 6x 1500er, bei je Paket 18 Byte Header = in Summe 90 Byte mehr zu übertragen. Dies wird entsprechend hoch potenziert je mehr los ist.

Der kleine Overhead mal rein Theoretisch durchgerechnet (Bei nur 1GBit, und ja, der Overhead von L2 gehört eigentlich auch mit in die 125MB/s..., ist so aber anschaulicher):

Input:
125 MByte/Sec =
131.072.000 Byte/Sec =
14563,55555555556 Frames/Sec á 9000 MTU
Overhead = 262.134 Byte/Sec

Output:
125 MByte/Sec =
131.072.000 Byte/Sec =
87381,33333333333 Frames/Sec á 1500 MTU
Overhead = 1.572.858 Byte/Sec

Cache-Füllrate: 1.310.724 Byte/Sec = 1,25 MByte/Sec (Differenz aus ein- und ausgehend)

Man sieht schon, das am besten beide Enden der Verbindung durchgängig die selbe MTU sprechen sollten. Moderne Switchen können hier mit z.B. FlowControl die Input-Rate drosseln, um eben nicht zusammenzubrechen. Der Problem tritt aber auch nur auf, wenn alle Links voll ausgelastet sind, also beide Enden entsprechend schnell lesen bzw schreiben können. Sobald hier einer bremst wird eh der gesamte Link langsamer (Switch-zu-Switch/Uplinks mal außen vor genommen, nur wenn beide Enden am selben hängen).

PS: Mal von der CPU Last und weiteren Headern auf Schichten höher 2 Angesehen, lassen sich bei 10GBit mit MTU 9000 statt 1500 Netto etwa 12,5MByte/Sec mehr Payload übertragen, wohoooo
Interessanter wird es hier auf Schichten mit größeren Headern, z.B. bei IPv6 alleine 40 Byte Header pro Packet.

 

[Bzzz]

Input:
125 MByte/Sec =
131.072.000 Byte/Sec =
14563,55555555556 Frames/Sec á 9000 MTU
Overhead = 262.134 Byte/Sec

SCNR:
In nichts zeigt sich der Mangel an mathematischer Bildung mehr...

„In nichts zeigt sich der Mangel an mathematischer Bildung mehr als in einer übertrieben genauen Rechnung.“
―Carl Friedrich Gauß

Drölf Nachkommastellen, aber wie du selbst schon vorschiebst ist das ja gar nicht richtig, da das Paket ja keine 9000 Bytes hat. Mit sagen wir 9018 Bytes sinds schon nur mehr 14534,4865823907740075404746063428698159237081392770015525... Häppchen pro Sekunde, und daraus ziehen wir jetzt bitte auf das Pikobit pro Äone genau den Overhead, um die Vorteile von Jumboframes klarzustellen

Vorschlag: 1518 Bytes bei 1500 Bytes Nutzdaten sind 1,20% Overhead, bei 9000 statt 1500 Bytes (x6) verkleinert sich das auf 1/6 = 0,20%.
Die Differenz, also dein zulaufender Puffer, sind demnach 1,20% - 0,20% = 1,00% (als hätts jemand so hingedreht!) von 125 MB/s, also 1,25 MB/s. Das sind in Bytes total hochgenau ausgerechnet...1310720 pro Sekunde.

Mal vergleichen:

Cache-Füllrate: 1.310.724 Byte/Sec = 1,25 MByte/Sec (Differenz aus ein- und ausgehend)

Sch**ße, jetzt liegen unsre Abschätzungen doch glatt 4 Bytes pro Sekunde auseinander, bei ner voll ausgelasteten Gigabitleitung

 

[besterino]

Mal ganz ehrlich @Bzzz: dein Post ist mal außer rumgekacke - bzw. der Versuch einem anderen Hilfsbereiten vors Schienbein treten zu wollen - nix wert, da nur das gleiche wiederholt in dem Irrglauben, Deine Beschreibung sei ja ach um Welten besser.

Der Punkt kam schon mit Killer Chris' Beschreibung prima rüber und wenn Du Dir bei derlei Themen tatsächlich a) die 87. Nachkommastelle anschaust und b) dann noch so einen Aufwand betreibst um zu zeigen, dass man das Gleiche auch hätte anders beschreiben können (und wir alle wissen, dass dann im Internet wahrscheinlich irgendwer aus dem Busch gesprungen wäre, um den Verfasser auf seine gottverdammte Schlamperei in der 88. Nachkommastelle hinzuweisen), tja dann solltest Du vielleicht mal in Dich gehen, ob das so sinnvoll angelegte Zeit war - oder Dich nochmal fragen, was der Kollege Gauss da sagen wollte. Oder geh zurück zu den Mathematik-Genies.

Manmanman. Da ist einer nett, beantwortet ne Frage (richtig) und bekommt trotzdem auf die Nuss, weil's ja auch anders geht.

 

[Killer Chris]

Wir kommen beide auf 1,25MB/sec, ist doch toll

 

[AxelMertes]

So, nachdem wir hier eindrucksvoll angewandten Dreisatz geübt haben (Wofür ich ausdrücklich Danke - ich bin auch öfter mal sehr präzise, wie ich weiter oben schon zu Schau gestellt habe - und bitte streitet Euch nicht deswegen), stellt sich mir doch noch eine andere Frage:

Wenn bei 10 GbE der Wechsel von 1500er MTU auf 9000 MTU nur 1% Traffic einspart, jedoch die Paketzahl auf 1/6 reduziert wird, wieso berichten immer wieder Anwender in Benchmarks von z.B. messbar 10% mehr Durchsatz?

Ich kann mir das eigentlich nur so erklären, das die Engine, die die Metadaten verarbeiten muss (also die Paket-Header) irgendwann an eine Lastgrenze kommt, während die Paketinhaltsdaten jedoch quasi im Bypass durchlaufen können. Ich sage es mal anders herum: Wenn es nur 1% bringen würde, warum hätte es dann die gesamte Industrie implementiert?
Der Aufwand wäre im Zweifel in die nächst schnellere Technologie besser investiert. Ich denke die Wahrheit liegt irgendwo dazwischen.

 

[onlyReaver]

Bei Virtualisierungsumgebungen gehören Jumbo Frames dazu wenn iSCSI genutzt wird. Weniger aber größere Pakete, somit weniger CPU Last, falls nicht sowieso Offloading benutzt wird.
Resultiert damit in höheren Durchsätzen. Das heißt nicht dass man es erst bei Volllast von 1/10/40 GBit merkt, sondern auch bei weniger Last. Ihr geht hier immer von 100% aus, sehr interessant.

Als Tipp: Denkt mal nicht nur an den Durchsatz, sondern an die Zeiten die ein Paket benötigt um verarbeitet zu werden. Da kommt das Gefühl der "Geschwindigkeit" her.

 

[AxelMertes]

[..] Ihr geht hier immer von 100% aus, sehr interessant.

Als Tipp: Denkt mal nicht nur an den Durchsatz, sondern an die Zeiten die ein Paket benötigt um verarbeitet zu werden. Da kommt das Gefühl der "Geschwindigkeit" her.

Ja und nein. 100% Last sind sicher nicht der Standart, aber in meinem Fall werden mitunter ständig solche Lasten erzeugt, das fällt mir relativ leicht: Renderjob and Renderfarm schicken, und schon ziehen hunderte Prozessorkerne die gleichen Texturen, Videodaten, Projektfiles vom Server. Da gehen die Peaks locker durch die Decke. Die CPUs sind flink, je nach Job sind die schneller als das Netz mit den Daten hinterher kommt, und da wird das Netz zum Nadelöhr. Darum tauche ich ja in diese 40 GbE/10 GbE Technik ein.

Selbst bei Videoschnitt u.ä. kommen wir auf sehr hohe Lasten, weil eben mehrere Clients mit mehreren Strömen versorgt werden wollen.

Geschwindigkeit ist tatsächlich vor allem ein Ding von Latenz. Nirgends merkt man das mehr als im Videoschnitt. Selbst 1 Frame Latenz (40ms bei PAL/25 Hz, 20ms bei PAL/50 Hz) sind sichtbar und vor allem spürbar. Framedrops weil der Storage nicht "just in time" die Bilddaten liefern konnte, sind für ein geübtes Auge sofort sichtbar - und nervig. Also ja, Geschwindigkeit misst sich nicht nur in MByte/s, sonder vor allem in: "Wann kommen die angefragten Daten an?"

Daher versuche ich ein Netz mit so wenigen "Hops" wie möglich zu haben. Ein Switch - mehr nicht. Leider muss ich aber noch 1 GbE Clients ansteuern, und die hängern in einer Kaskade am 2. Switch. Aber das sind auch nicht die Maschinen mit zeitkritischen Anwendungen, sondern eher Buchhaltung.

Kann leider im Moment noch nicht testen, bin gespannt was ich messen kann wenn es soweit ist.

 

[Killer Chris]

Zu den nur 1% Gewinn:
Wir haben oben auch nur den Layer 2 Overhead gerechnet, dazu kommen noch alle weiteren, die wiederum auch reduziert werden wenn es durchgängig ist, angefangen bei IPv4 (20Byte) oder gar IPv6 (40Byte) auf L3 und so weiter.

Und wie schon angesprochen auch die Latenzen auf dem kompletten Pfad. Bei einem Windows Copy Job wirst du keine Steigerung von z.B. 120MB/sec auf 130MB/sec sehen durch das Umstellen auf Jumboframes.
Die realitätsnahen Benches sind zu 90% auch keine reinen Durchsatzbenches sondern Mischkalkulationen, wo eben auch die Latenz mit rein spielt. Dazu kommen noch dropped Frames, Retransmissions, das übliche Chaos.

Auch sehr schön hierzu das Beispiel vom iSCSI, hier wird ein RAW Block mehrfach auf anderen Protokollen gekappselt und übertragen, da macht jedes bisschen Latenz-/Overheadverringerung mehr aus als der reine Netto-Durchsatz. Nicht umsonst zielen viele SSD Benches auf Zugriffszeiten ab.

Übertrag das mal über ein Netzwerk, da ist die Performance einer SSD durchaus mal nur noch auf dem Niveau einer normalen HDD (und eine HDD nochmal langsamer als eigentlich...).

Kommen dann noch mehr Layer dazu, wie bei SMB, potenziert es sich immer weiter.

 

[onlyReaver]

Hatte heute auf der Arbeit zwecks erweiterung des Storage Netzwerks auch ein Dokument von DELL durchgelesen, da stand bei den Best Practise Anleitungen auch einige Dinge zu MTU und Offloading.
Man hatte in der Regel ca. 13% Performance Steigerung mit Jumboframes und Offloading, natürlich nicht allein in MB/s gemessen sondern I/O per Sekunde. Schon ein großer Unterschied.

 

[AxelMertes]

Ich checke gerade alle Netzwerkkarten durch und stelle fest, dass die meisten auf eine maximale MTU von 9014 Bytes für Jumbo Frames ausgelegt sind.
Mein Brocade VDX6720 macht bis 9216 Bytes mit, die Mellanox Connect X2 sogar bis 9614 Bytes, aber die meisten 1 GBit Karten sind bei 9014 Bytes dicht, die Emulex dual/quad 10 GBit auch.

Ich denke 9014 Bytes wird dann auch der Wert den ich einstelle.

Bei einer Karte kommt "9KB" als Einstellwert - was auch immer das heißt. Und da kann man auch nichts ändern. Ich vermute das sind dann 9*1024 = 9216 Bytes, aber wissen tue ich es nicht ;-)

Wenn der Switch auf 9014 eingestellt wird, sollten die Karten sich ja darauf herunterhandeln, auch wenn sie höher eingestellt sind.

- - - Updated - - -

So, ich hab jetzt mal getestet mit zwei Rechnern, beide über 1 GbE und 10 GbE verbunden (jeweils Switche dazwischen):

ATTO Disk Benchmark via 1 GbE und MTU 1514 Bytes:


ATTO Disk Benchmark via 10 GbE und MTU 1514 Bytes:

Die Werte für 4096 und 8192 Write sind MODULO, weil es die 32 Bit Version des Benchmark ist (also noch 1 GByte oben drauf rechnen).

ATTO Disk Benchmark via 10 GbE und MTU 9014 Bytes:

Während die Werte für das Schreiben großer Blöcke deutlich abnehmen (aber immer noch völlig OK sind), nehmen die Werte für das Lesen großer Blöcke etwas zu. Viel drastischer sind allerdings die Zugewinne bei den kleinen Blockgrößen, da sind zum Teil 25% mehr Leistung zu sehen. Bin noch nicht ganz sicher ob alles optimal eingestellt ist, aber zumindest sieht man Unterschiede.

 

[JanV]

Hallo ihr Lieben!

Ich habe eine kurze Frage, die für die Profis und Hobbyisten unter euch sicherlich lächerlich einfach zu beantworten ist:

Ich habe ein altes Fachwerkhaus saniert und dort auch Netzwerkkabel verlegt (Cat7 4x2xAWG 23 S/FTP 100Mhz) und dies bereits auf den Dosen aufgelegt.

Dosen sind Cat6 und dort habe ich die Kabel nach T568B aufgelegt, wie auf dem Sticker in der Dose vermerkt (Weiß/Blau, Blau, Weiß/Orange, Orange, Weiß/Grün, Grün, Weiß/Braun, Braun).

An meinem Patchpanel (Cat6A) sind jedoch andere Sicker angebracht. Es ist auch nach T568A und B differenziert, die Belegung ist aber anders.

Im Anhang im roten Kasten ist die Belegung der Dosen, im hellblauen Kasten die vorgeschlagene Belegung vom Patchpanel.



Ich würde am Patchpanel einfach stumpf genau wie in den Dosen auflegen.

Meine Frage ist nur, ist das richtig oder falsch? Will nur ungerne alle Kabel neu auflegen müssen, weil ich die Belegung verdreht habe.
Ich hoffe ihr könnt mir das kurz bestätigen und wünsche schonmal ein schönes Wochenende!

Lieben Gruß
Jan

 

[underclocker2k4]

Wieso ist die Belegung unterschiedlich auf dem Bild? Die Belegung von "B" ist oben und unten exakt identisch.
Schau dir mal die Nummerierung und Reihenfolge der Pins an!
Danach kannst du dir die Frage selbst beantworten.

EDIT:
Kleine Gedankenstütze:
Du musst PIN1 der Dose mit PIN1 am Patchfeld verbinden. Da hilft die das CATx-Kabel. Wenn du also PIN1 in der Dose auf Weiß/Orange gelegt hast, auf welchen PIN musst du die Ader Weiß/Orange auf dem Patchfeld legen?

 

[JanV]

Erstmal Danke für die Antwort.

Mir ist durchaus klar, dass ich eine 1:1 Belegung zwischen den Dosen haben muss, es ist ja im Prinzip nur eine Verlängerung des Kabels.

Trotzdem irritiert es mich ungemein, dass die Belegung anders ist. Ist es nicht so, dass der "oberste Kontakt", egal wie der Pin nun heißt, auch an den "obersten Kontakt" im Patchfeld müsste?
Ich würde ein Multimeter nehmen und gucken, an welchen Kontakt in der RJ45 Buchse welcher Pin geht und dies genauso beim Panel machen. Wenn die Belegung gleich ist, lege ich nach dem roten Kästchen auf, wenn nicht, dann eben nach dem Blauen.
Ich bin wirklich verwirrt und blicke da absolut nicht mehr durch. Sprichwörtlich sehe ich den Wald vor lauter Bäumen nicht...

Im Bild ändert sich ja nunmal die Bezeichnung der Kontakte. In der Dose nennt sich der Oberste Kontakt Pin5 und im Patchpanel Pin1. Da sehe ich die Drehung.

 

[underclocker2k4]

Die Belegung ist NICHT anders!!!!!1111elfelfelf (sie ist EXAKT identisch)
Wie der Hersteller die LSA-Kontakte anordnet ist SEIN Ding. (und da jeder seine eigene Suppe kocht...)
Er kann die auch wild zerstreut wie aufm Schlachtfeld anordnen. Glaubst du dann, dass die Dose (mit gerade runter Anordnung) und das Patchfeld (Kreuzdiequer) garnicht kompatibel sein können?

Der Kontakt oben heißt nicht Pin5, sondern er geht auf PIN5 des Ports. Daher musst du den Kontakt der Dose, der mit PIN5 des Ports verbunden ist, mit dem Kontakt auf dem Patchfeld verbunden werden, der dort mit PIN5 des dortigen Ports verbunden ist. Dann hast du PIN5 des RJ45 der Dose mit dem PIN5 des RJ45 des Patchfeldes verbunden. Extrem einfaches Prinzip. Einfach PIN mit PIN verbinden. Die Anschalteblätter sagen dir, wo du welchen PIN auf den Klemmen findet und sagen dir dann, welche Adernfarbe (ist ja standardisiert) du da draufpacken musst.

 

[JanV]

Ok, vielen Dank!

Wenn du mir nun noch erklären kannst, warum bei dem Foto (aus der "Bedienungsanleitung" des Patchfeldes bei CAT5E / CAT6 der obere LSA Kontakt an Pin5 geht und bei CAT6A auf Pin1 bin ich zufrieden.