Am Sonntag, 25. Januar 2015, 23:57:18 schrieb Günther Zinsberger:
Am 2015-01-25 um 19:58 schrieb Jan Ritzerfeld:
Am Samstag, 24. Januar 2015, 22:19:14 schrieb Günther Zinsberger:
Ja, das sollte passen: (...).
Gut, flow control wird von den Switches her deaktiviert, aber das sollte ja nicht schlimm sein.
Guter Ansatzpunkt, glaube ich.
Ich habe mit solchen Problemen auch noch nie zu kämpfen gehabt. Wobei, WLAN ist noch viel schlimmer, glaube ich.
(...).
Zuverlässig? Puh. Vielleicht "ethtool -S eth0"? Oder /sys/class/net/eth0/statistics/*?
Sehr gute Idee!!
Die Idee ist ja auch nicht von mir.
Habe im Sys-Dateisystem einen einzigen verdächtigen Wert gefunden, und das könnte es sein!! # cat /sys/class/net/eth0/statistics/rx_missed_errors 557811
Ja, das passt zu dem Artikel, den du gefunden hast. Allerdings sind diese 140 MBits/s ja eigentlich ein Witz, wie du schon festgestellt hattest.
Und das, obwohl der Server gestern wegen eines anderen Fehlers rebootet werden musste!!
Wie hoch ist denn rx_packets? Es kommt ja ein wenig auf das Verhältnis an.
Komischerweise gibt "ethtool -S eth0" diesen Wert mit dem aktuellen Treiber gar nicht aus. Beim Testserver bekomme ich den da schon ausgegeben.
Komisch. Ich habe eher von Problemen mit Firmware-Updates oder sowas bei dem aktuellen Treiber gelesen. Vielleicht ist es gar keine so schlechte Idee mal tatsächlich den Treiber vom Hersteller selbst zu kompilieren, auch wenn die Version erst einmal kleiner erscheint. Nur, den Treiber auf dem Produktivsystem zu ersetzen ist natürlich auch etwas mutig.
(...).
Also dass es ausgeschaltet ist/wird steht ja in deinem dmesg-Auszug. Ich würde erwarten, dass das dann auch wieder da auftauchen würden, wenn es wieder aktiviert wird. Aber wer weiß das schon ...
Ahhhh, ist das das "EEE"? (Energy-Efficient Ethernet) (...).
Ja.
Habe es mal disabled: # ethtool --set-eee eth0 eee off # ethtool --set-eee eth1 eee off ...mal sehen, ob es was bringt.
Im Readme vom Hersteller-Treiber steht noch: | This version of the tg3 driver supports one module parameter that is | not available in the in-kernel driver. The parameter is named | tg3_disable_eee. | To disable Energy Efficient Ethernet (EEE) support, set this module | parameter to 1.
(...).
Ansonsten, könnten denn die Switches Probleme machen? Denn die wurden ja nicht ersetzt, sondern nur der Server. Und die Probleme sind geblieben. Vielleicht sind liegt die Ursache außerhalb des Servers?
Switch wurde auch schon mal probeweise gegen eine andere Marke getauscht. Hat nichts gebracht, wurde wieder zurückgetauscht.
Okay.
Die beste Erfolgswahrscheinlichkeit sehe ich beim Nachforschen zu den hohen "rx_missed_errors"-Ständen. Nur leider habe ich im Zusammenhang mit "tg3" oder allgemein noch nicht das richtige dazu gefunden...
Leider. Ich habe auch schon Stunden gegoogelt und nichts wirklich erhellenderes gefunden.
Allgemeine Erklärung dazu: /sys/class/<iface>/statistics/rx_missed_errors: Indicates the number of received packets that have been missed due to lack of capacity in the receive side. See the network driver for the exact meaning of this value.
Warum der Server zu wenig "Kapazität" hatte ist dann natürlich die große Frage. Die Flow-Control würde ja nur eine kontrolliert langsame Datenübertragung gewährleisten. Bug-Report auf bugzilla.kernel.org? Oder ein Post auf der LKML? Da lesen wahrscheinlich die wirklichen Profis. Gruß Jan -- It's a real shame that Turing machines are so poor at I/O. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org