[[U]nixchecker]

Hallo Jungs ich hab hier ein absolut dämliches Problem, evtl. kennt jemand das Problem.

Ich hab hier mehrere Rechner, ein FileServer RedHat Enterprise (Dual Xeon , 2TB Raid 0) der hängt an einem Netgear Gigabit Switch.
Folgendes Problem, ich transferiere ein Testfile mit 1GB Größe, die Transfergeschwindigkeit ist ein Witz und zwar wenn ich Windowsclients benutzte. Folgende Results habe ich:

Laptop (XP Intel 1GB Karte) :1,8MB/s
Workstation(Win 2000 XP Intel 1GB Karte) :1,8MB/s

Linux(100MBit 3Com Karte) :8MB/s
Linux(1000MBit Intel 1GB Karte) :20MB/s
(Die Werte sind offensichtlich OK)

Der Server hat ne 1GBit Karte von Intel. Ich hab das mit verschiedenen Protokollen getestet es sieht immer gleich aus. Die Windowsrechner sind frisch installiert.
Treiber etc habe ich jeweils die aktuellsten.

Es bleibt mir im Moment nur mal nen Sniffer anzuschmeißen und hoffen, dass ich da was auffälliges sehe.

[Rika]

Zitat

Die Windowsrechner sind frisch installiert.

Das dürfte wohl das Problem sein.

[QuentinT]

In wiefern ist das das Problem ?
Häh ?

[Rika]

Ich dachte da eher an per Default deaktiviertes TCP Window Scaling und zu kleine MTU.

[[U]nixchecker]

Zitat

Firewall , Antivirus und schlechte Kabel bzw. Schirmung und Aktive komponenten können das Problem sein.

Vermutlich ist die Backplane des Hubs bzw Switsches zu lahm ..

Das glaube ich wohl kaum, wenn ich den selben Rechner nehme und einmal Windows boote und einmal Linux, dann habe ich unter win die 1,8MB/s und unter linux die 20MB/s :-)
Außerdem haben die Intel Gigabit Karten unter Windows ein Testool, das Linkquality etc testet:-)

Ich denke auch, dass es an unterschiedlichen TCP Parametern liegt, wie Rika schon sagte, denn ich hab mal mit ethereal die Pakete gelogged und bis auf Unterschiede in RWIN MTU sehe ich da nix.

Aber es kann ja nicht angehen, dass ich hier zuerst Einstellungen vornehmen muss, damit das richtig läuft.
Den Intel Support kann man auch komplett vergessen, da kommen nur Standardphrasen und planloses Geschribsel.

[Rika]

Zitat

Aber es kann ja nicht angehen, dass ich hier zuerst Einstellungen vornehmen muss, damit das richtig läuft.

Naja, es läuft, nur halt nicht soooo performant. Wobei 1,8 MB/s doch shcon irgendwie etwas unrealistisch niedrig ist, vielleicht liegt an den Treiber-Einstellungen (Intel-Karten unterstützen beispielsweise QoS-Tagging auf Layer 2, zwar in Hardware, aber es bremst trotzdem).

Ansonsten:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters]
"EnableFastRouteLookup"=dword:1
"EnablePMTUBHDetect"=dword:1
"EnablePMTUDiscovery"=dword:1
"FFPControlFlags"=dword:1
"MaxFreeTcbs"=dword:00002000
"MaxFreeTWTcbs"=dword:4
"MaxHashTableSize"=dword:0000100
"SackOpts"=dword:1
"StrictTimeWaitSeqCheck"=dword:1
"Tcp1323Opts"=dword:1
"TcpMaxDupAcks"=dword:1

[[U]nixchecker]

Tja auch die Optionen haben nix gebracht, der Dump sieht jetzt aber fast identisch aus.

Der linux dump zeigt mehr ACKs soweit ich das sehe und header lenght is 32 statt 20 , da linux noch Options(12byte) mit sendet, 2mal NOP und Timestamp.

Irgendwas muss da im Linuxtreiber schief laufen. Es bleibt mir wohl nicht erspart mir mal den Quellcode anzugucken.
Im schlimmsten Falle muss ich mal Gigabitkarten von Realtek ordern. Ne ganze Schachtel mit Intel Gigabit Karten habe ich da liegen und nicht eine andere Gigabitkarte :-(

[Rika]

Die von RealTek sind doch wesentlich schlimmer. Und was soll denn mit den Linux-Treibern nicht in Ordnung sein, wenn's doch unter Windows nicht ordentlich läuft?

Und hast du unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters \TcpWindowSize mal eine geeignete große Start-Fenstergröße wie z.B. 569500 eingestellt? Nur für den Fall daß PMTUD nicht ordentlich funzt.

Ach ja, mit "Tcp1323Opts"=dword:3 aktivierst du auch Timestamps, falls es Spaß macht, daß die Dumps noch ähnlicher aussehen. Oder du deaktivierst es mal unter Linux, damit die Performance etwas hoch geht.

[[U]nixchecker]

Zitat

Die von RealTek sind doch wesentlich schlimmer. Und was soll denn mit den Linux-Treibern nicht in Ordnung sein, wenn's doch unter Windows nicht ordentlich läuft?

Ich dachte da an den Linuxtreiber des Linuxservers.


Ich hab jetzt mal zwei dumps rein. Ich hab dabei von der gleichen Maschine einmal mit Windows scp einmal mit Linux per scp ein file gezogen.

http://www.mysharefi...ransfer.7z.html
http://www.mysharefi...ransfer.7z.html

Linux hat mir 20MB/s angezeigt bei Windows 2MB/s.


Ich hab auch die Windowsize schon angepasst, da gabs ne Anleitung im Netz die speziell für Gigabit Ethernet Werte aufgelistet hat bzw. wie man die optimalen Werte ermittelt.

[Rika]

Also mal ganz davon abgesehen, daß da offenbar kein Window Scaling verwendet wird, fällt vor allem eines auf: es gehen Daten verloren, die neugesendet werden müssen. Daher die fehlenden ACKs. Vielleicht mal Selective ACKs abschalten?

[[U]nixchecker]

Ich hab den Fehler gefunden, es gibt da offensichtlich nen Bug in den Windows scp Versionen, wenn ich auf SSH1 Protokoll umschalten habe ich auf einmal volle Leistung.

Der Witz warum ich da nicht früher draufgekommen bin, der Server hat zwei interfaces eth0 mit 10MBit Anbindung und eth1 mit 1GB Anbindung, wenn ich per scp über eth0(10Mbit) reinging hatte ich ne höhere Rate als wenn ich über eth1(1000Mbit) reinging, irgendwie scheint die hohe Transferrate die windows scp versionen im Falle von SSH2 komplett aus dem Tritt zu bringen.

[[U]nixchecker]

Meine Vermutung wurde bestätigt, ich hab gerade cygwin installiert, wenn ich da mit scp kopiere auch bei ssh2 habe ich volle Power. Tja WinSCP und pscp saugen (suck) wie man so schän sagt