Acer H341 - Verbindungsabbruch bei Netzwerkübertragung

[Flycs]

Hallo zusammen,

ich bin ein WHS-Neuling mit untenstehender Konstellation (Signatur). Ich weiß, es gibt schon etliche Threads zu obenstehender Thematik, aber ich habe in den letzten drei Nächten gefühlt alle durchgelesen und die Lösungsvorschläge ausprobiert, ohne zu einem endgültigen Erfolg zu kommen. Ich bin mit jetzt nicht sicher, ob das Thema besser bei "Einsteiger" (bin ja einer) oder bei "Hardware" (Problem ist vermutlich H341-spezifisch) aufgehoben ist, aber da ich Netzwerk-Expertise brauche, habe ich es mal hier platziert.

Ursprünglich hatte ich das Problem, dass die Transferraten nicht über 100MBit-Niveau hinausgingen, bis ich schließlich herausgefunden habe, dass die Standardeinstellungen der Fritz!Box bezüglich EcoModus dafür sorgen, dass der Server nur eine 100MBit-Verbindung aushandelt. Zwingt man den Server-NIC zu 1GBit, kommt einfach gar keine Verbindung mehr zustande - Wahnsinn, was sich AVM da leistet! Und hab ich geschwitzt, ob der Crosslink mit dem PC zustandekommt, damit ich das wieder umstellen konnte. Dank anderer Beiträge hier bin ich auf 'arp -a' gestoßen, das mir dann die ausgehandelte IP angezeigt hat, mit derr ich dann wieder RDP nutzen konnte.
Jetzt läuft die Datenübertragung zwar mit ca. 30MB/s, was noch nicht optimal ist (ich würde 50-60MB/s erwarten), aber ausreichend - allerdings habe ich bei größeren Kopiervorgängen Abbrüche nach ca. 20 Sekunden (also ca. nach 1GB Datenübertragung, manchmal früher, manchmal später). Es kommt eine Fehlermeldung, dass der Share nicht mehr erreichbar sei, was nicht stimmt, da sich in einem weiteren Explorerfenster problemlos dorthin navigieren lässt. Die angebotene Option "Wiederholen" klappt nicht, aber überspringe ich das File, geht der Kopiervorgang weiter - bis zum nächsten Abbruch. Kopiere ich dann die fehlgeschlagenen Dateien nachträglich, klappt der Vorgang (solange die Files nicht allzu groß sind). Auch die Serverkonsole funktioniert weiterhin. Ich vermute, es hat was mit den erweiterten Einstellungen der beteiligten NICs zu tun, aber ich bin ratlos, wo man da schrauben kann.

Was ich bisher alles gemacht habe:

• Vorsichtshalber Einspielung des Firmware-Patches für die Samsung F4 vor dem Einbau.
• Aktualisierung der NIC- und SATA-Controller-Treiber auf die neuesten Versionen, die von den Herstellern verfügbar sind: leicht bessere Übertragungsrate, aber weiterhin Abbrüche.
• Aktivierung der Flusskontrolle (war im NIC-Treiber des Servers deaktiviert): keine Änderung des Verhaltens.
• Kontrolle der SATA-Modi der HDDs: alles i.O., alle vier haben laut HDtune eine gute Performance > 80MB/s
• Überwachung der CPU-Last: bewegt sich bei Kopiervorgängen um die 50%
• Deaktivierung des Windows Search-Dienstes (brauch ich nicht)
• Kontrolle der Ereignisprotokolle: nichts auffälliges, keine Fehler, allerdings gab es in den Ereignisprotokollen Einträge von Februar und November, hab den Server aber erst nach Weihnachten in Betrieb genommen. Der gekaufte Server war günstige B-Ware, die offensichtlich schon zweimal kurz angeschaltet wurde, daher
• Vollständiges Neuaufsetzen des Servers inkl. Formatierung: keine Verbesserung
• Tausch der ebenfalls neuen Fritz!Box mit einem anderen GBit-Switch von D-Link: keine Änderung des Verhaltens

Vor dem Neuaufsetzen hatte ich auch mal Jumboframes ausprobiert, mit 4k. Das hat dazu geführt, dass der Abbruch gefühlt etwas später erfolgte. Erst als ich auch auf dem Client Jumboframes mit 4k aktivierte, waren die Abbrüche scheinbar weg. Allerdings habe ich keine Ahnung, welche Auswirkungen Jumboframes so alles haben können. Ich habe ja noch einen 100MBit-Client im Netz (Media Center), außerdem steht überall, dass man bei Problemen Jumboframes deaktivieren soll. Ich habe das nach dem Neuaufsetzen daher nicht nochmal aktiviert. Außerdem sieht mir mein Problem genau nach etwas aus, das durch Jumboframes verursacht wird. Seltsam.

Hat irgendjemand noch Tipps, was ich ausprobieren könnte? Oder habe ich gar die Lösung für die Problematik überlesen?

[DerDa]

*push*

Guten Morgen,
ich habe exakt das gleiche Problem.
Allerdings habe ich festgestellt, dass der transfer funktioniert, wenn ich die WHS-Konsole und den Tab "System Informationen" mit den CPU Informationen geöffnet habe.

Hat evtl. jemand eine Idee?

Danke

Gruß
Ingo

[sTunTe]

Hallo.

Erst als ich auch auf dem Client Jumboframes mit 4k aktivierte, waren die Abbrüche scheinbar weg.

Was heißt scheinbar?!?

Wie bei vielen anderen Dingen in der Netzwerktechnik gilt auch für Jumboframes: Alle beteiligten Komponente müssen damit umgehen können.
Dazu zählen i.d.R. NICs, Switche und Router.
Spielt eines der Geräte nicht mit, kann es zu sogenanntem "Jabber" kommen, was u.U. das komplette Netzwerk (zeitweise) lahmlegen kann.
Das größte Problem liegt aber darin, dass Jumboframes nicht standardisiert sind und jeder Hersteller (mal wieder ) sein eigenes Süppchen kocht.
Man kann also sagen: Wenn kein homogenes Netzwerkwerk vorliegt, Finger weg von Jumboframes und stattdessen die Standard-MTU von 1500 Byte verwenden.

Wo wir grade beim Thema MTU sind...
Du hast nicht zufällig mit irgendwelche Verschlimmbesserungsprogramme alà Tuneup-Utilities herumgespielt?!?
Führe auf alles Rechnern folgendes Kommando in einer CMD aus und poste die Ergebnisse:

Code: Alles auswählen

netsh interface ipv4 show subinterfaces

Gruß
sTunTe

[Flycs]

Vielen Dank für die Info und den Versuch, mir weiterzuhelfen! Mit "scheinbar" meinte ich: ich habe nur kurz mit 4k Jumboframes getestet und ein paar zig Gigabytes zwischen Client und WHS kopiert, dabei kam es zu keiner Unterbrechung des Datentransfers. Dauertests konnte ich aber nicht machen, da ich wie gesagt davon ausging, dass ein Client nur ein 100MBit-Interface hat und keine Jumboframes unterstützt.

Derzeit läuft sogar alles, weil ich feststellen durfte, dass der HTPC doch ein GBit-Interface hat (war nur ebenfalls das Fritz!Box-Problem mit dem Energiesparmodus) und ich überall 2k als Framegröße eingestellt habe. Aber sobald ich überall auf "deaktiviert" oder im Falle vom WHS auf die kleinste Größe (1514 Bytes) setze, kommt es wieder zu dem Jabber.

Ich bin grad nicht daheim und kann daher die Konfigdaten nicht rauslassen, aber schon alleine die Aussage, vorsichtshalber die Framegröße auf den Standard 1500 Byte zurückzusetzen, stellt das Problem heraus: bei dem Treiber, der auf dem H341 installiert ist, geht das nicht! Ich kann als kleinste Framegröße wie gesagt lediglich 1514 Bytes auswählen. Kann ich die Framegröße auch anders setzen? Wie kann es sein, dass ein NIC-Treiber sich nicht zumindest an diesen Standard hält?!

[sTunTe]

Wie kann es sein, dass ein NIC-Treiber sich nicht zumindest an diesen Standard hält?!

Genau genommen hält sich MS auf den ersten Blick auch nicht an die RFC-Standards.
Die besagen nämlich eine MTU-Größe von 1518 Bytes.
MS rechnet aber einige Dinge nicht mit ein, so dass unterm Strich die 1500 Bytes (unter MS) = 1518 Bytes (RFC) sind.
Vermutlich rechnet also auch der Treiber Deiner NIC etwas anders.
So wie es aussieht werden bei Dir die 4 Bytes für den Framecheck nicht berücksichtigt.

1472 Bytes Transportschicht, wird auch als "Nutzlast" bezeichnet
+ 8 Bytes ICMP-Header
+ 20 BYtes IPv4-Header
-> 1500 Bytes, MS lässt Grüßen...
+ 14 Bytes Header Sicherungsschicht
+ 4 Bytes Framecheck
-> 1518 Bytes

Aber sobald ich überall auf "deaktiviert" oder im Falle vom WHS auf die kleinste Größe (1514 Bytes) setze, kommt es wieder zu dem Jabber.

Das ist merkwürdig.
Normalerweise verhält es sich genau umgekehrt.
Allerdings wurdert mich das bei der verbauten NIC des Acers relativ wenig.
Aber wenn unter 2 bzw. 4k alles läuft, dann lass es so.
Ansonsten kann ich Dir nur empfehlen Dich generell von onboard-NICs zu verabschieden.
Die Dinger taugen einfach nichts.
Und man kann sie bei Defekt nichtmal austauschen...

Gruß
sTunTe