Forum: PC Hard- und Software Narkoleptischer Ethernetport


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Hab' hier einen (Linux)PC mit eigenartigem Verhalten an einem 
Ethernetport:
Wenn ich mich von einem anderen PC aus auf diesen PC per ssh oder telnet 
verbinde und anfang' in der Konsole zu werkeln, ist's als ob irgendwer 
alle paar Sekunden den Stecker zieht - d.h. die getipperten Zeichen 
erscheinen nicht, die Konsole sieht eingefroren aus. nach ein paar 
Sekunden laeuft dann wieder alles, die zwischenzeitlich getipperten 
Zeichen erscheinen.

Link-LEDs an der Netzwerkbuchse sehen derweilen normal aus. iperf3 zeigt 
in beide Richtungen > 100MBytes Transfer und 0 Retries an. Auch 
Riesendateien per scp kopieren sieht unverdaechtig aus.
Wireshark zeigt mir waehrend den ssh/telnet konsolenproblemen 
tcp-retransmissions an.

Was laeuft da schief?

Gruss
WK

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Was laeuft da schief?

Die Kontakte in der Buchse hast du dir schon mal angesehen? Es gibt 
Spassvögel (nicht du, sondern evtl. Vorbesitzer), die solche Buchsen mit 
USB verwechseln und damit die Federchen verbiegen. Ansonsten würde ich 
die Stromversorgung des Tranceivers in Verdacht haben.
Auch mal schauen, ob ifconfig alles gut findet.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Hab' hier einen (Linux)PC mit eigenartigem Verhalten an einem
> Ethernetport:
> Wenn ich mich von einem anderen PC aus auf diesen PC per ssh oder telnet
> verbinde und anfang' in der Konsole zu werkeln, ist's als ob irgendwer
> alle paar Sekunden den Stecker zieht - d.h. die getipperten Zeichen
> erscheinen nicht, die Konsole sieht eingefroren aus. nach ein paar
> Sekunden laeuft dann wieder alles, die zwischenzeitlich getipperten
> Zeichen erscheinen.
> [...]
> Was laeuft da schief?

Geschieht das Ganze bei allen Gegenstellen, oder nur bei bestimmten? 
Gibt es irgendwelche besonderen Einstellungen wie Jumbo Frames? Was 
sagen dmesg, ethtool und die Logdateien in /var/log dazu? Was für eine 
NIC ist das, und welchen Treiber (Kernelmodul) verwendest Du? 
Irgendwelche speziellen Settings beim Laden des Kernelmoduls -- oder 
vielleicht auch mal das Kernelmodul mit aktiviertem Debugging laden? 
Benutzt das Netzwerk einen Hub statt eines Switch und ist möglicherweise 
der Promiscuous-Modus aktiviert? Laufen da anderweitig größere oher 
höher priorisierte Datentransfers über die NIC?

von Michael X. (Firma: vyuxc) (der-michl)


Bewertung
0 lesenswert
nicht lesenswert
Mach den iperf-Test mit UDP. Dann siehst du was.
Hört sich an als würde irgendwo ein Buffer überlaufen. Hast du mal auf 
100MBit/s runtergebremst?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Buchsenkontakte optisch OK, Link-LEDs geben auch keinen Hinweis in die 
Richtung. Transceiver Stromversorgung muss ich mal guggen, ob ich da 
mit'm Scope was sehen kann.
Tritt bei 3 von 3 getesteten verschiedenen Gegenstellen auf, die sich 
alle untereinander bestens verstehen. Keine Jumboframes, etc. Nix 
verdaechtiges in dmesg, ethtool oder den logs.
Kernel 4.12.7, Teiber igb, kein Modul, fest im Kernel drinnen. Hardware: 
Intel i210.
Switch, kein Hub (Gibts sowas ueberhaupt bei GBit Ethernet?). Keine 
parallelen wahnsinns-Netzwerktransfers. (Wireshark: 160 "Fremd"pakete / 
10 sec.)
Bei iperf mit udp und Datenraten ueber 100MBit leichte ca. 0.1% 
Paketverluste in eine Richtung. Wird aber wohl eher der "andere" PC 
sein, denn der ist nicht mehr ganz so taufrisch.
Unter 100MBit/sec keine Paketverluste in beide Richtungen bei 
iperf(udp).
Aber so schnell tipp' ich nicht in einer Konsole.
Hab' den Link grad mal auf 100MBit/sec gesetzt (Link-LEDs haben auch 
Farbe gewechselt), koennte sein, dass es jetzt geht. Ist immer bisschen 
schwierig das sicher zu sagen.
Wenns eines sicher nicht ist, dann Pufferueberlaeufe. Ich weiss nicht, 
wie schnell andere Leut' tippen koennen, aber bei mir reichen 9600 baud 
locker.
Aber mit der Linkspeed koennts schon zu tun haben...hmm...

Gruss
WK

von Thomas M. (langhaarrocker)


Bewertung
1 lesenswert
nicht lesenswert
Liest sich für mich wie ein typisches Verhalten eines gepufferten 
Datenstroms, wo nicht nach jedem Tastendruck der Puffer geflushed wird.

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> leichte ca. 0.1% Paketverluste in eine Richtung.

Der übliche ping benutzt nur kleine Pakete. Manche Fehler treten er bei 
größerer Paketlänge auf. ping -?

von Icke ®. (49636b65)


Bewertung
0 lesenswert
nicht lesenswert
1. Sparsamer mit Apostrophen umgehen, liest sich grauenvoll.

2. Woraus schließt du, daß das Verhalten auf die Netzwerkschnittstelle 
zurückzuführen ist? Vielleicht hängt einfach nur die Session. Laß 
zeitgleich einen Dauerping laufen und beobachte, ob Paketet verloren 
gehen. Wenn nicht, liegt die Ursache eher woanders.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Liest sich für mich wie ein typisches Verhalten eines gepufferten
> Datenstroms, wo nicht nach jedem Tastendruck der Puffer geflushed wird.

war auch mein erster gedanke.
insbesondere das Nachreichen und keine Daten verlieren spricht dafür.
eventuell auch ein zu langes timout für den zyklischen flush.
Abhilfe: fifo off
Namaste

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas M. schrieb:
> Liest sich für mich wie ein typisches Verhalten eines gepufferten
> Datenstroms, wo nicht nach jedem Tastendruck der Puffer geflushed wird.

war auch mein erster gedanke.
insbesondere das Nachreichen und keine Daten verlieren spricht dafür.
eventuell auch ein zu langes timout für den zyklischen flush.
Analyseschritt, temporäre Abhilfe: fifo off
Namaste

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
Evtl. kaputtes Interrupt-Handling/Routing. Die Reaktion erfolgt erst 
dann, wenn ein anderes Gerät einen Interrupt bekommt und daher alle 
potentiellen Handler aufgerufen werden.

Müsste man mit /proc/interrupts rausfinden können.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Tja. Am Freitag trat der Effekt auch noch mit 100MBit/sec Link auf. 
Heute bis jetzt noch nicht bei 1GBit/sec Link.
Das sind die Fehler die ich liebe...


Winfried J. schrieb:
> Abhilfe: fifo off

Wo kann ich das einstellen?


Icke ®. schrieb:
> Woraus schließt du, daß das Verhalten auf die Netzwerkschnittstelle
> zurückzuführen ist? Vielleicht hängt einfach nur die Session.

Das schloss ich aus der Tatsache, dass ich bevor ich hier einen Schrett 
aufmache, diverse Male den sshd neustarte, das Problem auch mit dem 
busybox telnetd auftrat statt sshd, und ich im Wireshark die dazu 
zeitlich korrespondierenden tcp-retransmissions sah.

Gruss
WK

von X2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ASPM für den Ethernet Controller aktiviert?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

X2 schrieb:
> ASPM für den Ethernet Controller aktiviert?

Nicht das ich wuesste. Wo mach ich denn das im Zweifelsfall? Dagegen, 
dass es mit so Energiespargedoens zu tun hat, spricht, dass es mir ja 
aufgefallen ist, waehrend ich in der Konsole so vor mich hin tipperte. 
Also mittendrinnen, nicht "immer nachdem ich einen Kaffee holen war" 
oder so. Auch die Link-LEDs sehen im Fehlerfall ja "normal" aus, nicht 
eingepennt.

Gruss
WK

von X2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Nicht das ich wuesste. Wo mach ich denn das im Zweifelsfall? Dagegen,
> dass es mit so Energiespargedoens zu tun hat, spricht, dass es mir ja
> aufgefallen ist, waehrend ich in der Konsole so vor mich hin tipperte.
> Also mittendrinnen, nicht "immer nachdem ich einen Kaffee holen war"
> oder so. Auch die Link-LEDs sehen im Fehlerfall ja "normal" aus, nicht
> eingepennt.
>
> Gruss
> WK

Ist meist eine Option im Bios Setup.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Namaste

Dergute W. schrieb:
> Winfried J. schrieb:
>> Abhilfe: fifo off
>
> Wo kann ich das einstellen?

zum Thema Fifo und telnet:

Kommandozeile von telnet

http://www.osnews.com/story/10929/Command-line_interactive_programs_in_UNIX_shell-scripts/page3/

Namaste

: Bearbeitet durch User
von syslog (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Beobachte mal die Files in /var/log/*

Was sagt 'ethtool -S  eth0'?

von Conny G. (conny_g)


Bewertung
0 lesenswert
nicht lesenswert
So ein Verhalten kenne ich von alten Windows-Gurken, die zuwenig 
Speicher haben und zuviel Paging betreiben.
Laufen hungrige Programme und RAM ist knapp?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Paketverluste sieht man recht gut mit flood-ping, also "ping -f". Root 
nötig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.