Asus A8N-VM CSM & Tyan S2865: Netzwerk bricht zusammen

[PhreakShow]

Servus mitnander,

ich muss nun leider etwas weiter ausholen für die Problembeschreibung:

Es geht um mein Heimnetzwerk (Cat7-Kabel mit Cat6-Dosen und 3com-GBit-Switch), den dort angeschlossenen Server und meinen Desktoprechner.

Der Server (Windows Server 2003 SP2) dient als Router, DNS, DHCP, und ner Menge andrer Serverdienste, dort läuft IPcop (kleine Linuxdisti mit Router-Funktion) in einer virtuellen Maschine und wird per VMware Player als Dienst gestartet (bitte keine Kommentare zum un-IPcop, bin mir dessen bewusst).

Zuerst zum Asus-Board:
Es handelt sich um das A8N-VM CSM mit GeForce6150 und nF4 Chipsatz, der GB-Nic ist direkt im Chipsatz angebunden. Treiber habe ich zig Versionen getestet, zuletzt die 6.86 und 6.70.

Das Problem bestand nun darin:
Der Server dient u.a. auch als Fileserver für Backups, die können auch mal 5-10GB groß sein. Wenn ich nun diesen Brocken übers Lan ziehe, geht das für ca. 10s gut. Danach bricht die Übertragungsrate total ein, von 50-60MB/s auf unter 1kB/s.
Der Explorer am Desktoprechner "friert" ein, auch der Remotedesktop mit dem ich den Server steuer stirbt an einem timeout.
Nach 30-60s geht die Übertragung weiter, wieder wie vorher mit 50MB/s, nur um 10s später wieder auf unter 1kB/s einzubrechen. In der Zwischenzeit sind beide Rechner nicht mehr zu steuern. Das ganze bleibt dann so, bis die Datei fertig kopiert ist, das kann aufgrund der Pausen schon ne Stunde dauern.

Ich vermutete einen Defekt im onboard-Nic des Asus-Boards und kaufte daher ein Tyan S2865 (nForce4 Ultra). Dort wählte ich den zweiten Nic (Broadcom GBit, über PCIe angebunden) für die Verbindung zum Lan und den nForce-Nic für die Verbindung zum Modem.
Ich testete ca. fünf Bios-Versionen und wieder mehrere Treiber, doch auch hier trat das Problem auf. Gleiches Spiel, beim Kopieren von großen Dateien geht nach wenigen Sekunden nichts mehr.

Desktoprechner war in beiden Fällen ein AMD Opteron 146 auf einem Abit KN8-SLI. Dessen Nic ist in Ordnung, ich konnte damit fast 100MB/s übers Lan schieben auch über einen längeren Zeitraum.

So, und jetzt seid ihr dran. Ich bin echt fertig mit meinem Latein...
Ich danke schonmal für hoffentlich zahlreiche Antworten,

Gruß Phreak

Edit:
Das hab ich jetzt noch vergessen. Wenn das netzwerk nicht mehr funktioniert, bricht am Server auch die Verbindung zum Internet zusammen. Der IPcop muss sich neu zum Provider verbinden. Also muss das Problem quasi am Server liegen...

Ich hab nun zwei weitere Sachen getestet.

Zum einen hab ich am Server die Nics vertauscht, also den Broadcom zur Verbindung mit dem Modem verwendet und den nForce fürs Ethernet.
Und oh Wunder, gleiches Problem...

Außerdem hab ich mit dem Asus-Board nen Testrechner aufgebaut, den neuesten Treiber drauf (8.26) und der Fehler tritt nicht auf, weder beim installierten XP noch unter Win2003.

Ich hol den Server die Tage zu mir ins Zimmer und schau wie er sich verhält, wenn er direkt am Switch hängt, also mit Patchkabel und nicht über Cat7-Verlegekabel.

Ideen

 

[MrWeedster]

Hoi.

Aehnliches habe ich vor kurzem mit meinem Server erlebt, als ich diesen gerade evaluierte.

Bei mir verlief das aehnlich wie bei dir - ~40MB/s die ersten paar Sekunden, danach abfall auf <10MB/s.
Der Server war gleichzeitig nicht mehr bedienbar.

Nach kurzer Analyse fand ich heraus dass der RAM an der grenze war - Warum nur?
Tja, weil ich den Controller-Cache auf 100% lesen eingestellt hatte, und somit Schreibvorgaenge auf die Platten nicht mehr gecacht waren, und er somit in den RAM ausgelagert hat.

Jetzt lass mich raten: Dein Server hat ein RAID 5 mit einem onboard Controller?




greetz

 

[PhreakShow]

Hm, dein Post hat mir etwas Mut gemacht, aber nur am Anfang

Der Server hatte ein Raid1 mit dynamischen Datenträgern, weil der onboard-Controller kein "Hardware"-Raid an Pata kann. Im Moment ist das Raid noch nicht eingerichtet, also es hängt ganz normal eine einzelne Platte dran.

Ich geh der Sache mit dem Cache mal nach und schau mir den Ram an (1,5GB).

Edit:
grovel (2628) Eine Anforderung, in die Datei "d:\SIS Common Store\edb.log" ab Offset 406528 (0x0000000000063400) insgesamt 512 (0x00000200) Bytes zu schreiben, war erfolgreich, benötigte aber ungewöhnlich viel Zeit (123 Sekunden) von Seiten des Betriebssystems. Zusätzlich haben 0 andere E/A-Anforderungen an diese Datei ungewöhnlich viel Zeit benötigt, seit die letzte Meldung bezüglich dieses Problems vor 1046 Sekunden gesendet wurde.

Die Ereignisanzeige speichert jedesmal diese Fehlermeldung. Leider scheint die so selten oder speziell zu sein, dass mir Google dazu nichts ausspucken konnte.
Hinzugefügter Post:
Update: Ich kann den Fehler nun reproduzierbar erzeugen.

Das Asus-Board hier im Testrechner zeigte die Symptome zunächst nicht. Erst als ich Win2k3 aufsetzte und einen RIS/WDS-Server installierte, trat das Problem wieder auf.

Es scheint so, dass der Groveler-Dienst schuld dran ist (daher auch der Eintrag im Ereignisprotokoll). Sobald ich den RIS/WDS aktiviere, wars das mit der Netzwerkperformance.

Microsoft hat das dazu auf seiner Homepage, klingt nach meinen Symptomen...

Alelrdings scheint das noch nicht der Weisheit letzter Schluss zu sein, da dieser Hotfix im SP2 enthalten ist, welches ja auf meinem Server mit drauf ist *confused*

 

[PhreakShow]

So, also ich kann den Fehler nun an drei Rechnern reproduzierbar erzeugen.

Ich installiere Windows Server 2003 Standard & Enterprise-Edition, x86 und x64, macht keinen Unterschied. Als nächstes installiere ich Actice Directory/Domain Controller, noch geht alles wunderbar.

Sobald ich dann den WDS (Windows Deployment Services) dazu installiere, tritt der Fehler auf.
Alle OS sind per Windows Update auf dem neuesten Stand...

Was nun?

 

[nate`]

Hatte das Problem auch ... einzige Vernünftige Lösung für mich: Weg mit der Windows-Grütze und ein feines Debian druff

Haste mal geguckt, obs beim Windows-Update unter "Benutzerdefinierter-Suche" -> "Hardware" evtl. Treiber-Updates für deinen Controller gibt, die evtl. direkt von MS angeboten werden und verifiziert sind?

 

[PhreakShow]

Bevor ich da wieder ein Frickel-OS aufspiel, reiß ich mirn Bein aus

Updates unter benutzerdefiniert hab ich nicht gesehen...

Bin grad dran, das an einem Testserver nachzustellen und dort den Fehler zu beheben. Wer noch Ideen hat, immer her damit
Hinzugefügter Post:
Ich krieg hier gleich nen Anfall

Hab in der Woche Win2003 glaub 10³²-mal neu installiert. Jedesmal die gleiche Prozedur, Win drauf, nVidia-Treiberpack drauf, Active Directory, WDS.
Gerätemanager, alles optimal eingestellt, Festplatte-Caches eingeschaltet. Neustart, fertig...

Und dann kam ja das Problem mit den Freezes...
Jetzt schau ich zufällig nachm Neustart in den Gerätemanager, seh den deaktivierten Schreibcache an den Platten. Nix dabei gedacht, eingeschaltet.

Ich start die Kiste nedmal neu... paar Minuten später hab ich einen Eintrag in der Ereignisanzeige, dass der Schreibcache aktiviert wurde und dass evtl Datenverlust droht. Und schwupps deaktiviert Windows den Festplattencache...

Also selbigen nochmal eingeschaltet und mit installiertem WDS getestet. Geht!
Am Testserver und eigentlichen Server, geht an beiden Systemen.

Ich hoffe dass es das nun endgültig war...

 

[jni]

Daß man den WDS auf ein eigenes Laufwerk installieren sollte, wo außer den Images nichts wichtiges drauf ist, hab ich noch so in Erinnerung. Sonst kann's halt zu Problemen kommen mit dem SIS Common Store, wenn der Groveler losarbeitet. Oder den Groveler deaktivieren. Da muß man aber aufpassen, da der immer wieder aktiviert wird, wenn man was am RIS/WDS ändert.

Ist halt blöd gemacht von Microsoft.

Also wenn's geht Umpartitonieren und eine eigene Partiton nur für RIS/WDS-Images machen.

@nate`

Bin mir ziemlich sicher, daß bei komplizierteren Konfigurationen unter Debian auch vergleichbare Probleme unter Debian auftreten, die erst nach längerem Suchen und Probieren lösbar sind.

 

[PhreakShow]

WDS hatte schon ne eigene Partition, bzw teilweise zum Testen sogar ein eigenes Laufwerk- Hilft alles nix wenn Win den Cache wieder deaktiviert, obwohl die Kiste an ner USV hängt...

Also bisher kein Fehler mehr, ich denk das war wirklich der Cache.