3
Extrem unterschiedliche Up- und Downloadrate im LAN!
Problem im nForce-2 Chipsatz ?
Beim Zugriff auf einen Samba-Server (getestete Distris: Debian, Mandrake, RedHat und Arch, immer die aktuellste Distri- und Samba-Version mit allen Patches) erreicht der Barebone (WinXP-Pro SP2 - onboard nForce-2 NIC - aktuellste Treiber - mit aktivierter und deaktivierter Windows-Firewall) im geswitchten LAN bei 100MBit/Full Duplex auf beiden Seiten rund 8.500k/S im Upload und 250k/S im Download. Mit anderen Windows-Computern hat der Rechner keine Probleme, im Ereignisprotokoll wird nichts vermerkt und andere Computer haben keine Probleme beim Zugriff auf den Server (selbst per WLan).
Serverseitig wird die onboard NIC (i810er Chipsatz - nicht schnell, aber stabil) verwendet.
Mit einer 3com Karte erreicht der Barebone rund 10.000k/S in beiden Richtungen, allerdings ist der Platz im Barebone prinzipbedingt begrenzt, daher würde ich gerne die onboard-NIC verwenden. 8.500k/S sind erträglich, 250k/S definitiv zu wenig.
Wie kann diese Diskrepanz entstehen?
Serverseitig wird die onboard NIC (i810er Chipsatz - nicht schnell, aber stabil) verwendet.
Mit einer 3com Karte erreicht der Barebone rund 10.000k/S in beiden Richtungen, allerdings ist der Platz im Barebone prinzipbedingt begrenzt, daher würde ich gerne die onboard-NIC verwenden. 8.500k/S sind erträglich, 250k/S definitiv zu wenig.
Wie kann diese Diskrepanz entstehen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 62442
Url: https://administrator.de/contentid/62442
Printed on: April 27, 2024 at 02:04 o'clock
3 Comments
Latest comment
Auf die Frage ist nicht einfach zu antworten ob der geringen Informationen....
Als Erstes solltest du definitiv klären ob dein Netz bzw. die Karten der bremsende Faktor ist. Das macht man natürlich nicht mit einem unökonomischen Hin- und Herkopieren von Dateien mit dem Windows CIFS Protokoll sondern mit einem nativen Tool was einem den nackten Netzdurchsatz des netzes an sich und der NICs für unterschiedliche Packetgrößen anzeigt.
Ein Tool wie NETIO:
http://www.ars.de/ars/ars.nsf/docs/netio
hilft dir dabei. Es rennt unter Linux und Windows und wird einfach in der Eingabeaufforderung oder am CLI Prompt gestartet. (Ohne Paramter gibt die Syntax aus ! netio -t -s startet den Server und netio <ipadresse_server> -t den Client)
Danach weisst du erstmal sicher ob der Engpass im Netz selber oder auf der verwendeten NIC Hardware liegt. Ggf. kann man hier mit aktuellen treibern noch tunen.
Liegt der Engpass nicht hier, kann es nur ein internes Problem mit Plattencontrollern etc. sein.
Auch dies Dokument in Bezug auf Samba kann hilfreich sein:
http://gertranssmb3.berlios.de/output/speed.html
Als Erstes solltest du definitiv klären ob dein Netz bzw. die Karten der bremsende Faktor ist. Das macht man natürlich nicht mit einem unökonomischen Hin- und Herkopieren von Dateien mit dem Windows CIFS Protokoll sondern mit einem nativen Tool was einem den nackten Netzdurchsatz des netzes an sich und der NICs für unterschiedliche Packetgrößen anzeigt.
Ein Tool wie NETIO:
http://www.ars.de/ars/ars.nsf/docs/netio
hilft dir dabei. Es rennt unter Linux und Windows und wird einfach in der Eingabeaufforderung oder am CLI Prompt gestartet. (Ohne Paramter gibt die Syntax aus ! netio -t -s startet den Server und netio <ipadresse_server> -t den Client)
Danach weisst du erstmal sicher ob der Engpass im Netz selber oder auf der verwendeten NIC Hardware liegt. Ggf. kann man hier mit aktuellen treibern noch tunen.
Liegt der Engpass nicht hier, kann es nur ein internes Problem mit Plattencontrollern etc. sein.
Auch dies Dokument in Bezug auf Samba kann hilfreich sein:
http://gertranssmb3.berlios.de/output/speed.html
OK, danke für die Tipps und sorry für die späte Antwort, war eine Weile unterwegs und bin auch die nächsten Tage wieder unterwegs, komme aber spätestens am Wochenende wieder dazu und werde mich wohl insbes. mit dem Thema Socket-Optionen beschäftigen.
Die habe ich bisher immer auf "TCP_NODELAY", "SO_RCVBUF=8192" und "SO_SNDBUF=8192" gesetzt.
Die habe ich bisher immer auf "TCP_NODELAY", "SO_RCVBUF=8192" und "SO_SNDBUF=8192" gesetzt.
Habe jetzt auf dem (Problem)Rechner auch LINUX installiert und siehe da: keine Probleme mehr - Zugriff auf die Daten geht einwandfrei.
Was jetzt genau die Ursache war, kann (und will) ich nicht mehr nachvollziehen - dennoch, danke für die Tipps.
Was jetzt genau die Ursache war, kann (und will) ich nicht mehr nachvollziehen - dennoch, danke für die Tipps.