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
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
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?
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?
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
Liest sich für mich wie ein typisches Verhalten eines gepufferten Datenstroms, wo nicht nach jedem Tastendruck der Puffer geflushed wird.
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 -?
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.
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
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
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.
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
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
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.
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
So ein Verhalten kenne ich von alten Windows-Gurken, die zuwenig Speicher haben und zuviel Paging betreiben. Laufen hungrige Programme und RAM ist knapp?
Paketverluste sieht man recht gut mit flood-ping, also "ping -f". Root nötig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.