Netzwerkschnittstelle verabschiedet sich bei Langzeitzugriffen

[volker]

J.G. schrieb an den Support folgende Email:

Wir habe das erste Test-/Demonstrationssystem unter Verwendung des Revolution Pi fertiggestellt. Bevor wir es an den Kunden ausliefern, lief es die letzten Tag im Dauertest. Dabei stellte sich leider heraus, dass der Revolution Pi nicht langzeitstabil ist.
Mit zusätzlichen Debug-Ausgaben konnten wir nun erkennen, dass sich die (in der Applikation intensiv genutzte) Netzwerkschnittstelle des Revolution Pi nach 3...10 h verabschiedet. In diversen *RaspberryPi* Foren haben wir viele ähnliche Hinweise gefunden, dass ein stabiler 24/7 Betrieb nicht möglich ist, weil das Netzwerk Probleme macht. Es wird oft auf eine instabile Stromversorgung verwiesen, die ich bei dem Revolution Pi (mit seiner 24V Versorgung) wohl ausschließen kann. (Wir powern das System von einem 60 W Hutschienen-Netzteil der Fa. Deutronic).
Sind Ihnen die Netzwerk-Probleme bekannt? Was gibt es für Korrekturmassnahmen? Welche Vorschläge haben Sie für's weitere Vorgehen?

[volker]

Hallo J.G.,
gerade die Ethernetschittstelle verwenden wir hier in der Entwicklung und beim testen im 24/7 Betrieb. Es gab noch nie irgendwelche Probleme. Darum müssen wir zunächst einmal festhalten, dass Euer Test keinesfalls das Ergebnis hatte, (Zitat:) "dass der Revolution Pi nicht langzeitstabil ist". Die korrekte Schlussfolgerung ist vielmehr, dass ein Langzeitbetrieb Eures Testaufbaus auf Probleme gestoßen ist. Um hier näher analysieren zu können brauchen wir etwas genauere Aussagen als ""zusätzliche Debug-Ausgaben" oder "hat sich verabschiedet". Bitte beschreibe doch einmal genau, welche Soft- und Hardwarekonfiguration eingesetzt wird, was genau auf der Ethernetschnittstelle an Protokollen läuft und welche exakten Fehler dort auftreten. Wenn wir diese Basisinformation haben, dann können wir exakter nachhaken und ggf. auch versuchen, das Problem zu reproduzieren.
Die angesprochenen Forenbeiträge im Internet beschäftigen sich mit dem Raspberry Pi und nicht mit dem Revolution Pi. Die Hardware ist eine gänzlich andere und somit auch die möglichen Ursachen für Netzwerkzugriffsprobleme. Gerade die Tatsache, dass sehr viele User eines Raspi einfach ihr Gerät an eine USB Stromversorgung mit vielleicht gerade mal 500 mA Belastbarkeit anschließen, statt das ausdrücklich vorgesehene Originalnetzteil zu verwenden, führt beim Raspi zu sehr vielen Problemen. Darunter fallen mit Sicherheit auch Netzwerkzugriffsprobleme. Aber genau wegen solcher Dinge gibt es ja unseren Revolution Pi. Jedes 24 V Hutschienennetzteil ab 10 Watt kann den RevPi Core voll versorgen.
Die Ursachen liegen höchst wahrscheinlich in ganz anderen Bereichen. Viele User haben zum Beispiel mit selbst geschriebener Software Probleme bekommen, weil ihre Software zu Analysezwecken sehr viele Log-Einträge geschrieben hat. Bei 24/7 Betrieb kann es da schon sehr bald zu einer vollen eMMC kommen... und dann geht wenig bis gar nichts mehr. Aber natürlich spielt auch der Netzwerkpartner (switch???) eine Rolle bei der Frage, warum sich Probleme im 24/7 Betrieb ergeben. DHCP??? lease-Time??? Es gibt so viele Ursachen, die alle systematisch analysiert werden müssen.
Aber wir können das gerne hier im Forum gemeinsam versuchen in den Griff zu bekommen. Vielleicht können sich ja auch andere user mal zu Wort melden, die Ihre RevPi Geräte ebenfalls 24/7 betreiben und keine Netzwerkprobleme haben. Ich weiß zum Beispiel, dass in der Schweiz Solaranlagen remote überwacht werden und 24/7 dafür am Netz hängen. Die laufen inzwischen fast 2 Monate fehlerfrei...

[jdg]

Hallo allerseits,
ich mache gerne weitere Angaben zum System: Also es handelt sich um einen der ersten Revolution Pi Controller, die letztes Jahr auf den Markt kamen. Wir wollen damit mittelfristig ein System ablösen, das auf Basis eines Kontron Think-I/O IPC Hutschienensystems digitale Fernsehsender überwacht (DVB-T Sender). Als I/O Module sind Digital-Input und Digital-Output Module der Wago 750 Serie verbaut. Der Kontron IPC hat eine direkte KBus Schnittstelle zum Aufstecken der 750-xxx Module. Da der bisherige (Kontron) IPC abgekündigt ist, soll der Revolution Pi die Linux-PC Aufgabe übernehmen. Als Interface zu den 750-xxx Modulen fungiert nun ein Wago 750-352 Modbus Interface. -- Die Mess-Applikation ist in C++ geschrieben und läuft seit 2007/2008 auf einigen hundert installierten Anlagen im Dauerbetrieb 24/7/265. Die Applikation wurde jetzt um die Bibliothek 'libmodbus v3.0.6' erweitert, um die Kommunikation zum Wago Controller herzustellen -- Soviel zur Vorgeschichte.
Die ersten Dauertests der auf dem RevPi laufenden Applikation haben gezeigt, dass immer wieder ein paar Stunden nach dem Start/Boot die Funktionalität der Digital-Ein/Ausgänge nicht mehr gewährleistet war. Da das System 'headless' läuft, wussten wir zuerst nicht, was die Ursache war. Deshalb haben wir die Applikation mit zusätzlichen Debug-Ausgaben für den Fehlerfall ausgerüstet. Das hat gezeigt, dass die Digital-I/Os deshalb nicht mehr bedient werden (können), weil der Revolution Pi das Wago 750-352 Modbus Interface nicht mehr erreicht. Es zeigt sich, dass genau zu dem Zeitpunkt, wenn die Netzwerk-Kommunikation ausfällt ein Eintrag der Form
smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
in 'dmesg' zu finden ist und danach ist das Netzwerk des Revolution Pi "tot". Ein 'ip addr show' zeigt, dass 'eth0' weder eine IPv4 noch eine IPv6 Addresse haben. Auch ein 'sudo ifdown eth0' und 'sudo ifup eth0' kuriert das Problem nicht mehr, es hilft nur ein Reboot. Probleme an unserem Firmennetz kann ich ausschließen. Die DHCP Infrastruktur wird von einem Ubuntu 16.04 Server bereitgestellt, den wir seit langem betreiben und selbst administrieren. Das Problem ist sicher auch kein DHCP Leasetime Problem. Es stellt sich die Frage, warum das Netzwerk des Revolution Pi nach ein paar Stunden Betrieb seine komplette Konfiguration verliert und welche Möglichkeiten es gibt, dem Problem auf die Spur zu kommen. Auch wenn ich annehme, dass ein Revolution Pi nicht eins-zu-eins einem Raspberry Pi entspricht, so treffen doch die Beschreibungen der Google Suche
https://www.google.de/search?q=smsc95xx ... LTUc3ZpOgI
voll auf unser Problem zu.
Hat jemand weitere Ideen...?

[volker]

Bitte sieh vorsichtshalber mal in der crontab nach, ob da irgendwelche Jobs aufgerufen werden, die vielleicht zyklisch das Netzwerk überwachen (network watchdog).
Ist die Zeit des Zugriffsverlustes exakt vorhersagbar und reproduzierbar oder eher zufällig?
Welche und wie viele USB Geräte laufen parallel auf dem Gerät?
Welche Distribution läuft auf dem System? Die original von KUNBUS installierte Wheezy oder eine andere?
Könntest Du auf unser aktuelles Jessie Image umsteigen? Wheezy wird von uns nur noch sehr eingeschränkt aktualisiert.

[volker]

NACHTRAG:
Ich würde gerne mal etwas ausprobieren. Könntest Du testweise bitte mal in der cmdline.txt (/boot/) diesen Eintrag hinzufügen und testen, ob sich irgendetwas verändert:
sms95xx.turbo_mode=N dwc_otg.speed=1
Die Einträge fahren die USB auf USB1.1 speed zurück und drosseln das Netzwerk auf 10 Mbit.
Wir können damit dann ggf. eine Interferenz der USB-Schnittstelle ausschließen oder als Ursache festmachen.

[jdg]

pi@RevPi100102:~ $ sudo crontab -l
no crontab for root
pi@RevPi100102:~ $ crontab -l
no crontab for pi

Auf dem System läuft:
pi@RevPi100102:~ $ uname -a
Linux RevPi100102 4.4.50-rt66+ #1 PREEMPT RT Wed, 31 May 2017 09:42:59 +0200 armv6l GNU/Linux

Die Zeitspanne, bis das Netzwerk "ausfällt" (du nennst es Zugriffsverlust ) würde ich als zufällig bezeichnen; irgendwas zwischen 1...7 Std. soweit es meine Tests in den letzten Tagen betrifft.

Den Eintrag 'smsc95xx.turbo_mode=N' in der /boot/cmdline.txt habe ich gestern abend schon vorgenommen. Seitdem läuft das System noch ohne Ausfall (immerhin jetzt seit ca. 24 h). Ich hatte aber auch zusätzlich "vm.min_free_kbytes = 16384" in die '/etc/sysctl.conf' eingetragen. Deshalb weiß ich jetzt nicht, welche der "Änderungen" nun eine scheinbare Verbesserung gebracht hat. Ich schreibe deshalb "scheinbar", weil ich auch vorher schon einmal einen Dauertest mit eineinhalb Tagen geschafft hatte...

An den USB Schnittstellen ist momentan nur ein aktiver Industrial USB-Hub (Hutschiene, 24 V versorgt) angeschlossen. Allerdings werden später über weitere kaskadierte USB-Hubs dort bis zu 16 HF-Leistungsmesser des Typs R&S NRP8S
( https://www.rohde-schwarz.com/de/produk ... 99587.html ) laufen müssen, das tun sie an den bisherigen Anlagen auch...! Die USB-Geschwindigkeit möchte ich deshalb eher ungern auf USB1.1 herunterschalten.

Jetzt beobachten wir mal weiter; vielleicht hat ja der abgeschaltete Turbo_mode eine Stabilisierung gebracht...

[volker]

Okay, also einen Schritt nach dem anderen. Aber wenn die 10 Mbit nicht den Erfolg bringen, dann solltest Du um der Ursachensuche willen dennoch auf USB1.1 umstellen. Wenn damit die Probleme weg sind, wissen wir, dass das System USB reconnects (Neustarts) erzwungen hat, welche unter Wheezy leider nicht Ethernet ebenfalls neu starten (Ethernet wird über denselben Controller angefahren). Wenn das dann so ist, würde eine Umstellung auf Jessie wahrscheinlich Abhilfe schaffen.
Übrigens sind die Messgeräte am USB Port dann möglicherweise noch einmal ein sehr viel größeres Problem. Wir mussten unsere Treiber für die Messgeräte in unserer Produktionsanlage, die zyklisch Stromwerte in die Cloud pushen jedenfalls extrem umbauen, damit sie unter Debian stabil laufen und bei einem Reconnect der USB Ports stressfrei und ohne memory leak automatisch neu aufgesetzt werden. Darum sind wir froh, dass wir diesen Umweg mit unseren neuen AIO Modulen nun nicht mehr gehen müssen. Unser Agent für die Cloud Connection über Ethernet ist übrigens "selbstheilend" bei Verlust der Ethernetverbindung. Er lief auch unter Wheezy 24/7 ohne Probleme über viele Wochen.

[jdg]

Was soll durch eine "Umstellung" auf Jessie besser werden? -- Das IST Jessie...!!

Übrigens: Das System läuft immer noch; also schon eineinhalb Tage Hoffentlich bleibt's so.

Was du da über die USB Ports erwähnst, hoffe ich, dass nicht stimmt. Ansonsten wäre der Revolution Pi völlig ungeeignet für Steuerungsaufgaben. Warum sollte ich mir als Anwendungsentwickler über die Funktionsfähigkeit und Stabilität der USB Schnittstellen der Hardware-Plattform Gedanken machen?! Die vorhandenen USB Ports HABEN einfach zu funktionieren. Wenn sie das nicht tun, ist das System eben unbrauchbar...

[volker]

Entschuldigung, Du hattest gesagt, dass Du das Original RevPi Core 1 (erste Generation) einsetzt. Dieser hat Wheezy und kein Jessie. Also hast Du ein Jessie nachträglich aufgespielt? War es das Jessie von unserem Server oder welche Quelle hast Du dabei verwendet?

Das ist Deine persönliche Auffassung zu dem Thema USB. Ich habe das Gefühl, dass Du weniger im Bereich industrieller Steuerungen unterwegs bist, als im Bereich Messtechnik. Eine klassische PLC hat gar keine USB Schnittstellen und generell werden in der industriellen Automatisation auch USB Schnittstellen eher sehr kritisch gesehen - eben weil es ein Standard aus dem Consumerbereich ist und die in der Industrie geforderte Robustheit oft vermissen lässt. Der revPi Core ist ein Zwitter, der sich zwischen der Welt der IPCs und der PLCs bewegt. dabei werden in beide Richtungen Kompromisse gemacht. Für Anwendungen, in denen diese Kompromisse nicht akzeptabel sind, sollte dann eben eine klassische PLC oder ein klassischer IPC eingesetzt werden.

[jdg]

Da hast du Recht. Ein klassischer IPC wurde ja auch jahrelang verwendet. Aber was machst du, wenn's den nicht mehr gibt? Du suchst nach Alternativen. Und RevPi ist (wäre?) so eine Alternative... -- ...da er u. a. auch USB Schnittstellen anbietet. Und die Rechenpower des RevPi würde für die Applikation auch locker reichen. Was allerdings nicht geht, ist, einerseits USB Schnittstellen anzubieten und dann zu sagen, so richtig nutzen darf man sie aber nicht. Dann wären die USB Schnittstellen nämlich eine Mogelpackung...!