Netzprobleme, -erfahrungen

Hallo,

für die Problembeschreibung muss ich etwas ausholen:

Als mir vor einigen Wochen ne Netzwerkkarte übern Jordan ging, dacht ich, wenn ich schon ne neue brauch, warum nich gleich auf Gigabit aufrüsten. Hier im forum las ich dann, dass es mit den Intel-Karten wohl problemlos klappen sollte - ok, hab also 3 Intel-karten und nen Switch besorgt.

Damit fing mein Leidensweg an.

Offensichtlich habe ich eine neue Charge der Karten erwischt, die erst ab kernel 2.6.14 oder so unterstützt wird. Zumindest bei 2.6.8 und 2.6.12 kommen Fehlermeldungen.
Bei 2.6.14.xx klappt es mit der Karte, nur gibt es mit der kernel-Konstellation eine nfs-Schreibrate von ca. 200 K/s.
Das fiel mir zum ersten Mal auf, als ich gerade den ersten Rechner mit Gentoo fertig hatte und dachte, es wäre ein Problem von Gentoo.
Bin nach 4 Wochen verzweifelter Suche zurück zu Suse.
Als ich dann unter Suse die neue Version ausprobierte, tauchte das Phänomen genau so wieder auf.
Leserate ok, Schreibrate unter 200 K/s - egal, ob ich ipv6 deaktiviert hatte oder nich (zumindest bei Suse weiß ich wie das geht).
Also dachte ich, probier es doch mal mit Debian. Ist eigentlich ein stabiles Serversystem ...
Wie sich dann herausstellte, funzt es bei sarge stable nicht mit der Intel-Karte.
Habe also den Kernel 2.6.14 aus unstable genommen.
Jetzt geht die Karte, aber jetzt habe ich auch das nfs-Problem wieder.

Daraufhin habe ich mir die Kernelparameter rund um nfs mal angeschaut und folgendes ausprobiert:
- nfs über tcp ausgeschaltet
- nfs-v4 deaktiviert
- direct-io über nfs deaktivert
Jeweils als einzelne Option, kernel backen, reboot und anschließend copy-Test.
Leider hatte ich an keiner Stelle Erfolg.

In den letzten Wochen ist nicht blos eine Netzwerk-Karte abgesemmelt, sondern es sind auch noch 3 Festplatten an Altersschwäche eingegangen. Deshalb konnte ich die Phänomene anfangs nicht richtig zuordnen. Inzwischen ist die restliche HW überprüft und läuft auch soweit und wie sich in den letzten Tests rausgestellt hat, ließ sich das nfs-Problem eindeutig mit dem kernel-update in Verbindung bringen (ich habe auch schon ein 2.6.15-rc2 ausprobiert, ist genauso davon betroffen).
Was mich total verblüfft:
Unter linvdr mit darkangels 2.6.12.2er wird die Intelkarte unterstützt und das nfs-Problem besteht nicht. Offensichtlich ist der kernel gut gepatched!

Jetzt bin ich mit meinem Latein total am Ende.

Fällt Euch noch was ein, wie ich aus dem desaster wieder rauskommen könnte?

P.S.: Weiß jemand, ob man einfach die Kartentreiber von einem 2.6.14er nehmen und in einen 2.6.8er von debian stable einpflanzen könnte ???

P.P.S.: so meldet sich die Karte (bei lspci -v):

01:07.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
        Subsystem: Intel Corporation: Unknown device 1376
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11
        Memory at df020000 (32-bit, non-prefetchable) [size=128K]
        Memory at df000000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at 9000 [size=64]
        [virtual] Expansion ROM at 88000000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [e4] PCI-X non-bridge device

Hallo kilroy,

das Tuhl kannte ich noch garnicht.
Die Messung ging auch über Switch einfach mit Rechnername.

Ergebnisse sehen so aus:

NETIO - Network Throughput Benchmark, Version 1.13
(C) 1997-2001 Kai Uwe Rommel


TCP/IP connection established.
Packet size  1 k bytes:   40716 k bytes/sec
Packet size  2 k bytes:   40771 k bytes/sec
Packet size  4 k bytes:   41078 k bytes/sec
Packet size  8 k bytes:   41168 k bytes/sec
Packet size 16 k bytes:   41086 k bytes/sec
Packet size 32 k bytes:   40638 k bytes/sec

Noch kurz was zum Test-Szenarium:
Der Server exportiert ein Verzeichnis für nfs.
Am Desktop wird dieses eingebunden.
Kopieraktion mache ich mit mc
Dabei habe ich ne Rate von ~180K/s von lokalem Laufwerk auf nfs-share
und
ne Rate von ca. 23 MB/s von nfs-share zu lokalem Laufwerk.

Wobei ich schon überprüft habe, dass es nicht am Server und seiner Festplatte liegt.
Wenn ich dort ein Laufwerk vom Desktop einbinde und den Test durchführe komme ich auf ähnliche Ergebnisse.

Es muss also irgendwie mit dem Schreiben auf nfs zusammen hängen.

Hallo kilroy,

ich danke Dir für Deine Aufmerksamkeit und Deine Fragen!

Zitat

In beide Richtungen?

Ja, da scheint der Hund begraben zu liegen

Egal, ob mit oder ohne Switch, ich bekomme nur eine Messung vom client zu Server.

Vom Server zum client bekommt netio keine Verbindung.
Dabei funktioniert die Namesauflösung auf beiden Maschinen vor und zurück und ping funktioniert auch. Firewall habe ich für die tests auch deaktiviert.

Die Tests habe ich mit und ohne Switch probiert, mit 'normalem' und mit crossover-Kabel und dann habe ich noch die Netzkarten ausgetauscht, um auch HW-Fehler auszuschließen (ich hoffe mal, dass nicht alle 3 Karten den gleiche Defekt haben).

Zitat

Zeige auch mal die Einträge der exports und wie Du auf dem Client mountest.

exportiert werden die schreibbaren Verzeichnisse mit (rw,sync) und eingebunden nur noch mit 'defaults'.
Früher war mal "rsize=8192,wsize=8192" notwendig, dann gab es jedoch mal ein kernel-release, bei dem sich alle Maschinen mit den Einstellungen aufgehängt haben und es nur noch mit "rsize=1024,wsize=1024" ging und inzwischen scheint 8k der default zu sein.
Versuchsweise habe ich die Werte mal wieder eingebaut, ohne Effekt, wobei eine Größe von 1k die Übertragungsrate nochmals reduzierte.

Sch... - dadurch dass ich die Karten getauscht habe, funzt jetzt nichmal mehr linVDR - jetzt bin ich ganz am A... bend.
... und ja, alle Karten melden sich mit Rev.05 und 'unknown device 1376

update:

Hab die Karte gefunden, die unter LinVDR tat (weiß nicht, ob die MAC-Adresse irgendwo mit der Konfiguration gespeichert wird, nach Kartentausch musste ich die Netzkonfiguration wieder komplett neu erstellen - zumindest unter Suse, bei LinVDR konnte ich nix in der Richtung tun, so ganz ohne Netz).

Stand der Dinge ist (alle Ergebnisse mit Switch):

- von Server zu LinVDR: ca. 15000 kB/s
- von Server zu Desktop: keine Verbindung
- von Desktop zu LinVDR: ca. 50000 kB/s
- von Desktop zu Server: ca. 42000 kB/s
- von LinVDR zu Server: ca. 23000 kB/s
- von LinVDR zu Desktop: keine Verbindung

die Ergebnisse sind unabhängig davon, ob bei Desktop und Server die Karten ausgetauscht werden, ja und LinVDR tut z.Zt. nur mit der einen Karte.
Ach ja, auf dem Server läuft sarge stable mit kernel 2.6.14.2 auf dem Desktop läuft Suse mit kernel 2.6.14.2 und LinVDR läuft mit kernel 2.6.12.2

kilroy:
Wenn Du die gleiche Karte hast, wie sind den Deine netio-Werte (übern Daumen)

Hallo,

also mc verwende ich deshalb, weil ich ne Kopieraktion abbrechen kann, wenn ich sehe, dass die Transferrate zu klein ist. Ausserdem gibt er rel. schnell eine Transferrate aus.
Die Unterschiede zwischen den div. Kopiervarianten dürften geringer sein, als die aktuellen Unterschiede (ca. 200KB/s lokal -> nfs und ca 25 MB/s nfs -> lokal).

Live-CD habe ich leider keine, bei der die Karte erkannt und richtig initialisiert wird.

Inzwischen habe ich Suse wieder vom Desktop runter und Gentoo drauf.
Jetzt bringt netio zum Desktop die gleiche Rate wie zu LinVDR (15000 kB/s).
Wobei ich das nicht verstehe.
Im server werkelt ein Athlon XP 2000, im Desktop ein Athlon XP 2500 und unter LinVDR ein PII/400.
Kann so ein Mega-Unterschied alleine am Chipsatz liegen?

Wenn ich top bei netio anschaue, liegt der CPU-Bedarf unter 5% (bei 10-15% si?).

Beim Kopieren läuft der Server mit 80-90% idle, der Desktop mit 90-98% wait.
Beim Server gibt es auch wieder ca. 10% si.

kilroy:
Wenn ein Celeron 850 auf 60000 kB/s kommt, muss doch bei mir was janz doll daneben laufen? Ein Athlon 2000 sollte (?) doch geringfügig schneller laufen, als ein Celeron 850 - oder?

Hallo Kilroy

"Ubuntu" - die fährt doch hier irgendwo rum ... muss nomml suchen.

Also wenn ein "XP 2500" bei Dir ne große Kiste ist, dann sollten wir noch ein paar Details vergleichen. Ich dachte, die 90000 würde ein 64bitter mit >3000MHz erbringen.

Mein Barton sitzt in einem MSI-board mit nforce2 Chipsatz und aktivem dual-Channel.
Im Testboard sitzt ein 1800er mit kastriertem nforce2 Chipsatz von Asus, also ohne dual-Channel.
Im Server werkelt ein 2000er mit K266er Chipsatz von MSI.

Was mir aber so garnicht einleuchtet - bei laufendem netio-Test war der Rechner zu max. 5% ausgelastet, d.h. die CPU hätte mehr bringen können.
Allerdings war ein rel. hoher wait-Anteil dabei - und das gefällt mir garnicht.
Beim Server habe ich inzwischen herausgefunden, dass ich den wait-Anteil bei Kopier-Aktionen durch Ausschalten von "CONFIG_IDEPCI_SHARE_IRQ=y" deutlich reduzieren konnte. Dieser Punkt läßt sich vielleicht nicht verallgemeinern, da ich im Server rel. viele Platten an vielen Controllern laufen habe.

Hast Du "CONFIG_PACKET_MMAP=y" aktiv?

... und für die Intelkarte:
CONFIG_E1000=y
CONFIG_E1000_NAPI=y

Mehr fällt mir im Moment nicht ein, was man noch vergleichen könnte.

Hi kilroy,

danke für die ausführliche Info.
So ganz spontantan fällt mir auf, dass Du ne neuere Version von netio hast. Werd ich mal suchen müssen.

Wenn's bei Dir ohne NAPI so abgeht, werd ich wohl mal wieder kernel backen gehen
... das wäre doch gelacht, wenn wir das nicht rausfinden.

Hm, gefällt mir garnicht.
Du schreibst, die Rate von und zu Server wären gleich? - und das bei unterschiedlicher CPU und MB? So ein Mist. Bei mir sieht das alles andere als gleich aus:

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel


TCP connection established.
Packet size  1k bytes:  50601 KByte/s Tx,  19655 KByte/s Rx.
Packet size  2k bytes:  50074 KByte/s Tx,  19267 KByte/s Rx.
Packet size  4k bytes:  49146 KByte/s Tx,  19035 KByte/s Rx.
Packet size  8k bytes:  48764 KByte/s Tx,  18913 KByte/s Rx.
Packet size 16k bytes:  48632 KByte/s Tx,  18985 KByte/s Rx.
Packet size 32k bytes:  48828 KByte/s Tx,  19275 KByte/s Rx.
Done.

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel


UDP connection established.
Packet size  1k bytes:  56711 KByte/s (32%) Tx,  20795 KByte/s (0%) Rx.
Packet size  2k bytes:  44621 KByte/s (48%) Tx,  18541 KByte/s (0%) Rx.
Packet size  4k bytes:  13222 KByte/s (86%) Tx,  19526 KByte/s (1%) Rx.
Packet size  8k bytes:  3452 KByte/s (96%) Tx,  19697 KByte/s (0%) Rx.
Packet size 16k bytes:  796 KByte/s (99%) Tx,  20088 KByte/s (0%) Rx.
Packet size 32k bytes:  159 KByte/s (99%) Tx,  20410 KByte/s (0%) Rx.
Done.

Interessant finde ich den UDP-Wert bei 32k - das entspricht ungefär der nfs-Rate, die ich in schlimmsten Zeiten hatte. Zu der Zeit meinte ethereal was von "fragment", d.h. die "Päckchen" paßten wohl nicht durch den Schornstein, sodass der Nikolaus an der Türe klingeln musste...

Zitat

Soviele Tests sind gar nicht gut.

... dann habe ich noch etwas Salz für die Wunden:
Auf dem Server lief jeweils netio -s.

Die Variante ohne NAPI-Support:

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel


TCP connection established.
Packet size  1k bytes:  43627 KByte/s Tx,  17961 KByte/s Rx.
Packet size  2k bytes:  43603 KByte/s Tx,  17934 KByte/s Rx.
Packet size  4k bytes:  43403 KByte/s Tx,  17736 KByte/s Rx.
Packet size  8k bytes:  43398 KByte/s Tx,  17559 KByte/s Rx.
Packet size 16k bytes:  42353 KByte/s Tx,  17840 KByte/s Rx.
Packet size 32k bytes:  44092 KByte/s Tx,  18269 KByte/s Rx.
Done.

... bloß den Server neu gebootet und jetzt mit NAPI-Support:

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel


TCP connection established.
Packet size  1k bytes:  50379 KByte/s Tx,  19378 KByte/s Rx.
Packet size  2k bytes:  48565 KByte/s Tx,  19039 KByte/s Rx.
Packet size  4k bytes:  47869 KByte/s Tx,  18919 KByte/s Rx.
Packet size  8k bytes:  47746 KByte/s Tx,  18899 KByte/s Rx.
Packet size 16k bytes:  47880 KByte/s Tx,  18921 KByte/s Rx.
Packet size 32k bytes:  48377 KByte/s Tx,  19038 KByte/s Rx.
Done.

und das ganze als UDP:

NETIO - Network Throughput Benchmark, Version 1.23
(C) 1997-2003 Kai Uwe Rommel


UDP connection established.
Packet size  1k bytes:  60120 KByte/s (35%) Tx,  20173 KByte/s (0%) Rx.
Packet size  2k bytes:  41225 KByte/s (54%) Tx,  18304 KByte/s (0%) Rx.
Packet size  4k bytes:  11034 KByte/s (88%) Tx,  19509 KByte/s (0%) Rx.
Packet size  8k bytes:  2257 KByte/s (97%) Tx,  19448 KByte/s (0%) Rx.
Packet size 16k bytes:  455 KByte/s (99%) Tx,  19710 KByte/s (0%) Rx.
Packet size 32k bytes:  101 KByte/s (99%) Tx,  20063 KByte/s (0%) Rx.
Done.

Also die UDP-Werte sind für mich doch ziemlich neu, zumindest der Verlauf auf client-Seite. Krass!
Hm, UDP-Werte unter den TCP-Werten würden mich auch nervös machen. Das könnte auf Kollisionen bzw. Übertragungsfehler hindeuten, denn der Protokoll-Overhead ist bei TCP doch deutlich höher, somit entsprechen meine Werte zumindest relativ meinem Erwartungshorizont.
Gibt ifconfig bei Dir irgendwelche Fehler aus?

Was hast Du denn für MB's, bzw. Chipsätze im Einsatz?

Zitat

Sachte, sachte, wusstest du, dass bei UDP unter Linux Pakete schon verworfen werden können, bevor sie die Netzwerkkarte verlassen haben?

Schon - nur werden *imho* Pakete nicht ohne Grund verworfen.
Da könnte es durchaus Sinn machen, rauszufinden, warum Paktet verworfen werden.

Meines Wissens ist UDP eine verbindungslose Übertragungsart, die besonders schnell unter falscher Konfiguration, minderwertigen Leitungen oder Übersprechung von parallel verlaufenden 220V Wechselstromkabeln zu leiten hat.
Wenn Du noch mehr Gründe für das Entsorgen von UDP-Paketen kennst, immer her damit.

Bin eh gerade in einer Phase, in der ich alles in Frage stelle

//Edit: so habe ich mich anhand der netio-Ergebnisse gefragt, ob es im PII/400 überhaupt Sinn macht, eine Gigabit-Karte einzubauen. Nachgemessen und bei mir beträgt der Sinn locker Faktor 2