Gigabit- Lan Performance mit Explorer viel schlechter...

[mono]

.. als bei Linux

Dank Cyrus großartiger Hilfe, konnten wir am WE meine HNA Infrastruktur deutlich aufmöbeln, was sich insgesammt positiv für meine ff-user auswirken sollte.

Zum einen sind Fileserver (guckt mal bei den ff-diensten nach ) und Firewall (600 Mhz Epia, 1Gig Ram) jetzt getrennte Rechner. Dadurch sollte die Verfügbarkeit steigen, da nicht jedesmal wenn ich am Fileserver bastele das I-Net verloren geht. Ausserdem hat die Firewall, ermöglicht durch die größere Rechenleistung, ein paar tolle Features gekriegt. Proxy mit Werbeblocker und großzügigen Cache, und einen extra Cache für Updates. So werden Linux, Microsoft, Adobe,.. -Patches direkt bei mir geladen. Mehrere Tausend Verbindungen sollten kein Problem sein. Lediglich den Virenscanner mussten wir wieder deaktivieren

Gleichzeitig gab es einen kleinen Performance-Schub für mein internes Lan. Das Gigabit-Lan wurde doch sehr durch die UML beschnitten.

Jetzt aber das merkwürdige.

Unter Linux:

Samba: 15MB/s
Cifs: 25 MB/S
Http: 45 MB/S ! (firefox 2.0)
ftp: 60 MB/S !!!

Wohlgemerkt immer das gleiche File, vom gleichen Server, von der gleichen Platte.


Windows:

Samba: 15-20 MB/ S (wenns gut läuft)
Http: 3-6 MB/S (firefox)
ftp: 15-20 MB/S


Gut, könnte man sagen, schlechte Netzwerktreiber, falsche Einstellungen, mieser Stack, etc... ABER!
FTP über Winscp : 45-50 MB/s

Firewall und Virenscanner wurden Probehalber auf XP deaktivier, kein nenneswerter Unterschied.

Irgendwelche Ideen?

[tmk]

das sind ja erstmal fabelhafte neuigkeiten! So ein Zwischenspeicher ist interessant. Macht das der gleiche Rechner, der auch die Firewall fährt?

zu den schwankenden werten kann man eigentlich mal googeln. ich hab mal http://www.debianforum.de/forum/viewtopic.php?p=604992 angelesen, ist nicht genau dein problem, aber die leute da flamen nicht und gehen auch der sache nach, warum Gbit nicht gleich Gbit ist. Und noch http://www.nwlab.net/netzwerk-forum/Net ... m-245.html und http://www.computerbase.de/forum/showth ... ?p=1668434 vielleicht. http://www.sebbi.de/archives/2007/07/23 ... lan-hilfe/

[mono]

Ja, das googeln bringt leider nur sinnlose allgemeinplätze wie schlechte treiber und hardware.
Das erklärt aber nicht die 60 MB/s bei ftp auf der Gentoo Kiste.
Sind ja immer die gleichen treiber mit der gleichen hardware.
Und das es Windows auch grundsätzlich kann zeigt ja der WinScp test.

Ja, alle oben beschriebenen dienste (ausser den freigaben) laufen auf dem Firewallrechner.

[4huf]

Also das FTP mit eines der schnellsten Protokolle ist, ist wohl bekannt und wird hier
noch mal bestätigt.
Wie ist die Netzwerkkarte am Bus/Prozessor angebunden ? PCI-Express ?

Die Windows-Protokolle sind leider sehr lahm ...
Das HTTP unter Windows so einbricht könnte an Einstellungen liegen.
Das könnte man mal mit einem Downloadmanager mit identischen Einstellungen vergleichen (oder mit wget).

Das man mit einer Gbit-Verbindung keine 125MByte/s (minus Overhead) bekommt sollte
auch bekannt sein. Die 60Mbyte/s sind aber ein sehr guter Wert
Ich hätte mit 35..40Mbyte gerechnet.
Selbst 100Mit-Verbindungen schaffen leider keine 12,5Mbyte/s sondern typisch nur 4..5Mbyte/s mit ftp dann so ca 8MByte/s.

OT:
Wer sich eine externe Festplatte mit 100Mbit-Anschluss zulegt sollte sowas bedenken.
USB2 bietet hier schon bis zu 20MByte/s aber eben nur eine Verbindung.
Für Gbit-Modelle braucht man aber dann auch einen Gbit-Switch.

Ein Firewall mit transparentem Proxy läuft auch hier. In meinem Fall pfSense auf einem
älteren Notebook mit gemessenen ca 22W Stromaufnahme.
Das soll aber mit anderer Hardware noch besser werden.

[Cyrus]

Ja wget hat unter Windows bei Mono ähnliche http-durchsätze wie unter linux gemacht (50MB/s wenn ich mich richtig erinnere).
Es ging auch glaub ich nicht darum zu sagen das 60MB/s schlecht ist im Gegenteil, es ist nur verwunderlich dass z.B.: der Firefox unter Windows xmal langsamer als unter Linux ist, auf der gleichen Kiste bei gleichen Setup und allgemein die Netzwerkprotokolle im Vergleich so unterschiedliche Werte bringen auf den beiden Betriebssystemen.

[PapaBaer]

So, dann versuche ich mich auch mal:

Die Samba/CIFS-Werte sind ja auf beiden Systemen identisch, relativ lahm im Vergleich, aber bei all dem, was man so über das SMB-Protokoll hört sollte sich das mit dem Overhead erklären lassen.

Die übrigen Werte sind auch im Rahmen des zu Erwartenden, FTP ein wenig zügiger und sonst alles so zwischen 40 - 50.

Unter diesen Gesichtspunkten steht also die Frage, warum Windows mit Firefox bzw. FTP so einbricht.

Ich hatte mich vor einiger Zeit mal mit OpenAFS beschäftigt und dort das Phänomen, dass es unter Linux gut um den Faktor 30 schneller ist, auch bei ähnlicher Hardware. Ich hab dann der Sache mal hinterher gesucht und gelesen, dass es wohl gar nicht so einfach ist an eine saubere Dokumentation ranzukommen, was das Schreiben auf Windows-Dateisysteme angeht. Das hatte zur Folge, dass der OpenAFS-Client für Windows im Vergleich zu dem Linux-Teil einen sehr resourcenverballernden Weg geht, die übetragenen Daten auf die Platte zu meißeln. Hatte wohl irgend etwas mit Interrupts und so Kram zu tun (alles nur grob ausm Gedächtnis und nicht 100% sicher gerade). Es hat daher kaum nen Unterschied gemacht, ob man das Zeugs über 100MBit oder GBit laufen lässt, weil der Client die meiste Zeit damit beschäftigt ist auf irgendwelche Rückmeldungen von Windows zu warten.

Könnte mir gut vorstellen, dass das in eine ähnliche Richtung läuft. Was für Clients hast du denn genommen? Mal mit dem IExplorer getestet? Wie sind denn da die Werte?

An sonsten vielleicht mal mit nem ngrep oder tcpdump direkt in die übetragenen Protokolle sehen, vielleicht verhält sich nen Firefox unter Windows anders. Alles schon mal gesehen und böse Kopf zerbrochen drüber.

Stefan

[mono]

Also Firefox und IE verhalten sich auf xp gleich langsam.

Habe gestern noch einen nfs server aufgesetzt.

ergebnis:

Linux :35MB/s also ca. 10 MB/s schneller als samba mit cifs (samba ohne cifs 18 mb/s)

Windows: identisch mit samba

[HotShot]

Die schlechte Netzwerkperformanz unter Windows ist mir auch schon oft aufgefallen - vor allem zu meinen Netzwerkadminzeiten in Leipzig. Da sind manche Rechner total in die Knie gegangen, wenn zu viele Netzwerkverbindungen offen waren. Da war die Geschwindigkeit, die in den Netzwerkverbindungen zu erzielen war, auch stark von der CPU-Auslastung abhängig. Mit jedem Transfer erhöhte sich die CPU-Auslastung drastisch und die Geschwindigkeit brach ein. Dagegen waren FTP-Verbindungen davon völlig unbeeindruckt. Als wir dann Linux auf die Server aufgesetzt hatten, ging das alles viel schneller. Woran das lag, konnten uns auch die Microsoft-Abgesandten im URZ nicht wirklich erklären.

Ich Tipp auch mal auf vermurkste Protokolle.

Unter Vista hab ichs noch nicht getestet. Intranet ist hier zu Hause ja eh nich möglich durch den blöden Uni-WLan-VPN-Client. Wir kopieren hier alles per USB-Festplatte.

[tox]

so. ich hab das jetz mal bei mir probiert. xp-server, xp-client.

smb > 30 mb/s
http > 20 mb/s
ftp > 20 mb/s

diese werte muss man allerdings noch wegen zweierlei dinge relativieren:
a) ich habe die datei direkt von festplatte gelesen, sodass bereits die latenz der festplatte sich negativ auf die geschwindigkeit auswirkt,
b) ich habe es mit einem clr-kompatiblen framework ausprobiert, sodass die umsetzung der einzelnen smb- (das protokoll heißt übrigens smb, samba heißt nur das linux-projekt), ftp- und http-verbindungen noch einmal stark abstrahiert wurde, was der geschwindigkeit ebenfalls nicht zuträglich ist.
ich persönlich bin mit diesen werten daher also zufrieden.

mono, hast du schon in irgendeiner weise ausgeschlossen, dass es möglicherweise mit dem server zusammenhängt?

edit: dieselben werte bekomme ich auch beim ie, allerdings hier begrenzt durch die langsame laptop-festplatte des clients.

[Cyrus]

edit: dieselben werte bekomme ich auch beim ie, allerdings hier begrenzt durch die langsame laptop-festplatte des clients.

versuchs mal mit ner ramdisk auf clientseite wenn du denkst dass da der flaschenhals ist

HTTP und FTP sollten auf grund der art der datenübertragung auf jedenfall schneller sein.
Für HTTP und FTP-Tests empfehle ich wget auf client-seite. Auf server seite etwas performantes: Lighttpd aber Apache solltes auch tun.

[PapaBaer]

ich habe die datei direkt von festplatte gelesen, sodass bereits die latenz der festplatte sich negativ auf die geschwindigkeit auswirkt.

Das sollte ja bei fast allen im produktiven Einsatz befindlichen Servern der Fall sein, die wenigsten Systeme dürften mit memcache unterwegs sein und im Freifunk bestimmt gar keiner. Bei reinen File-Servern wäre es dazu noch ganz schön unsinnig. Aber selbst so sollte man ja wenigstens in etwa an die Lesegeschwindigkeit der Festplatte kommen, also ca. 80MB/s abzüglich Protokoll-Overhead. Das spiegeln ja auch Mono's Daten rund um FTP unter Linux ganz gut wieder. Bei HTTP hält sich der Overhead eigentlich in Grenzen, wenns nur n reiner Datei-Download ist, also sollte da doch mehr zu erwarten sein, gerade wenn man auf stabile und getestete Server wie Apache setzt.

Ich würde den Flaschenhals also eher am Client suchen, zumal zu erwarten ist, dass das schreiben dort mehr Zeit braucht als das Lesen auf der Serverseite (und Mono ja seine zwei Versuche mit dem selben Server gefahren hat). Hatte schon n paar bekackte Home-User Controller in der Hand, die beim gleichzeitigen Lesen und Schreiben von Daten böse zusammen gebrochen sind, von daher wären Tox' Werte von 20 - 30MB/s im Rahmen des zu Erwartenden. Wäre wirklich mal spannend, das mit ner Ramdisk anzugehen.

Offen bleibt allerdings die Frage, warum im gleichen Setup bei Mono das HTTP so einbricht unter Windows. Dazu mal noch ne Frage: das WinSCP, waren das die Datenraten auf Dateiebene oder die reine Übertragungsbandbreite? Könnte ja sein, dass du zwar Daten mit 50MB/s übertragen hast, aber alles zum entschlüsseln in den RAM ging und dann entschlüsselt und mit viel geringerer Datenrate auf die Platte gehämmert wurde.

Stefan

[mono]

nö. die kopierdauer war der übertragungsrate entsprechend kürzer.

[tox]

yay, ihr versteht mich falsch. es geht mir doch nich darum zu verdeutlichen, wie suboptimal meine testumgebung ist, sondern darum, dass monos werte auch für windows nicht normal sind. mit ner ramdisk und nem dicken cache bei mir würde dass doch alles nur noch n bisschen schneller gehen, was doch aber meine aussage, dass es bei mono ungewöhnlich langsam ist (wie gesagt, auch mitm ie hab ich mehr als 20 mb/s), nicht ändert ich wollte damit verdeutlichen, dass es nicht potenziell nur daran liegen muss, dass es ein windows-client ist, denn meiner war ja auch einer

[PapaBaer]

Jep, soweit klar.

Ich würd mal die Ramdisk-Variante angehen, damit könnte man sehen, ob es an der Übetragung bzw. dem Netzwerkstack hängt oder am Schreiben am Client. Weiß wer, wie man sowas mit Windows macht?

Stefan

[tox]

guckst du hier http://support.microsoft.com/?kbid=257405

[Cyrus]

Offen bleibt allerdings die Frage, warum im gleichen Setup bei Mono das HTTP so einbricht unter Windows.

Naja mit wget unter win konnte man gegenüber Linux annähernd gleiche Werte erreichen, nur Firefox und noch schlimmer Internet suXplorer waren unter aller sau was das ganze noch seltsamer erscheinen lässt, da der linux-firefox eigentlich nicht sooo schlecht von der übertragung war.