Pi nicht mehr per Netzwerk erreichbar, aber aktiv

  • Vorgestern hatte ich übrigens einen "Platten-Crash": das Dateisystem auf der SD-Karte war korrupt, es gab Lesefehler und es befanden sich angeblich mehrere Terrabyte große Dateien auf der Karte. Zum Glück konnte ich das reparieren, aber nachdem mir das jetzt auch zum zweiten mal passiert ist, beginne ich zu glauben, daß das ebenfalls ein Symptom der schlechten Stromversorgung ist.

    Hast Du damit schon mal Last gehabt?

  • Hallo zusammen,

    ich habe mir gerade die ganzen Beiträge der vergangenen Tage durchgelesen.

    Ich habe letztes Jahr in den englischsprachigen Foren gesucht, als bei mir das Mysterium mehr oder weniger regelmäßig - aber nicht oft pro Tag - auftrat, mich aber zu nerven begann.

    Der Wissensstand der einzelner Anwender ist verständlicherweise sehr unterschiedich.

    Die einen können nur feststellen, dass deren Anwendung (z.B. Midori) keine Seiten aufrufen kann. Die anderen arbeiten in der Konsole und empfangen dann die Fehlermeldung "cannot resolve hostname".

    Zahlreiche User bringen sehr nebulöse Fehlerbeschreibungen.

    Wenn man sich all diese Berichte (zig-weise in den RaspberryPi-Foren vorhanden) anschaut, drängt sich eine Gemeinsamkeit auf - unabhängig, ob der Anwender
    - LAN/ WLAN einsetzt,
    - eine feste IP- oder eine dynamische IP-Adresse verwendet,
    - ob Raspbian Wheezy, OpenELEC, RaspBMC oder sonstwas eingesetzt wird,

    Allem gemeinsam sind folgende Punkte, die entweder direkt oder deren Folge beobachtet werden können:

    1. Aus den Oszillogrammen von Zentris :danke_ATDE: folgt, dass in periodischen Abständen der Stromverbrauch extrem ansteigt und dann wieder abfällt. Es ist wohl noch vollkommen unklar, was da im Einzelnen passiert. Ist hierfür ein periodischer Prozess verantwortlich? Gibt es vielleicht mehrere Prozesse, die um Strom "buhlen" und sich gegenseitig mit immer mehr Strom versorgen lassen, bis es "knallt"?

    2 . Wenn dem Raspberry Pi der zur Verfügung gestellte Strom nicht auszureichen droht, schaltet er einfach irgendwas ab, um Strom zu sparen. Die meisten derart abgeschalteter Stromfresser erholen sich wieder - werden vom Betriebssystem wieder vollkommen reaktiviert.
    3. Das Stromeinsparen betrifft wohl auch mal den USB-Bus, der zusammen mit LAN von einem Bauteil (LAN 9512, LAN9513 oder LAN9514) gesteuert wird. Meistens geht dieser Ablauf reibungslos über die Bühne. Der USB-Teil wird automatisch wieder reaktiviert - gelegentlich aber bleibt seitens des Betriebssystems eine Reaktivierung des LAN / WLAN aus.

    FRAGE an Euch: Welches Modell des LAN951x ist bei Euch verbaut? Und wie häufig beobachtet Ihr das Mysterium?

    Bei mir läuft seit mehreren Monaten ein selbstgeschriebenes Programm mit, dass kaum Ressourcen benötigt - aber regelmäßig die Netzwerkseite prüft. Wenn die Tastatur / Maus kurzzeitig "hakt", dann ist dies ein Hinweis darauf, dass das Mysterium wieder zugeschlagen hat. Manchmal zählt dann dieses Programm den erfolgreichen Abschluss einer weiteren Korrekturaktion. Dieses Programm habe ich mal so eingestellt, dass es im Sekundentakt arbeitet- aber auch mal nur jede Stunde eingreift - oder auch gar nicht, außer ich drücke im Fehlerfall einen Button.
    Auf diese Weise wollte ich feststellen, ob Versuche, das Mysterium festzustellen, dieses auch hervorrufen kann. Nach meinen Beobachtungen kann ich dieses auschließen. Ob mein Programm im Sekundentakt, im Minuten- oder Stundentakt prüft und ggf. korrigiert - oder ob das Programm nur auf einen Anwenderklick wartet, die Prüfung zu starten, hat keinen signifikanten Einfluss auf die Häufigkeit des Auftretens des Mysteriums.

    Ich bin Anwendungsprogrammierer und verstehe von dem dem, was die Hardware im Detail hinter den Kulissen treibt, nur sehr wenig. Wenn mich irgendeine Macke des Betriebssystems stört, dann schreibe ich ein Programm, dass deren Auftreten feststellt - bevor ich es bemerke. Da alles in Linux dateibasiert ist, ist es in der Regel nicht schwierig, die betreffenden Dateien so zu "gestalten", dass man störungsfrei arbeiten kann.

    Der Raspberry Pi ist und bleibt ein Bastelcomputer, der vielen Zeitgenossen den Horizont ganz gewaltig erweitert hat.

    Ich glaube nicht, dass die Deinstallation irgendwelcher nichtaktiver Pakete Einfluss auf das Mysterium hat.

    Für mich persönlich ist die Frage, die Ursache hinter dem Symptom "Mysterium" zu kennen, mittlerweile nahezu belanglos geworden, da ich kein angemessenenes Zeit/Nutzen-Verhältnis erkennen kann. Ich befürchte, wir können hier noch Dutzende an Ideen und Erkenntnissen austauschen.

    Ich bleibe skeptisch, dass es einem von uns gelingen wird, DEN EINEN Prozess bzw. die enstsprechende Prozesskette zu identifizieren, der / die für das Mysterium zu 100% ursächlich ist - und dann durch eine Anpassung zu einem besseren Verhalten führt.

    Aber trotzdem noch viel Erfolg!

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Hallo Andreas,
    Respekt! Imho super recherchiert :thumbs1:

    Sollte m.E. Pflichtlektüre für RPi-Benutzer sein, vor allem der Satz


    Der Raspberry Pi ist und bleibt ein Bastelcomputer, der vielen Zeitgenossen den Horizont ganz gewaltig erweitert hat.

    trifft imho den Nagel auf den Kopf.

    Wie wär's ps915 ... dieser Beitrag ist es doch wert irgendwo angepinnt zu werden, damit er nicht versandelt, meinst Du nicht?

    Wie gesagt, ich finde den Beitrag wirklich super
    wenn Du so weitermachst, dann wirst Du noch zur absoluten RasPi-Koryphäe.

    Grüsse aus der Dunkelheit,
    -ds-

  • Hallo Dreamshader,

    :blush:

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Schöne Zusammenfassung von Andreas (!) :bravo2:
    ABER:
    Der RPi ist zwar als Bastelcomputer gestartet, jedoch bei so einigen (vielen?) inzwischen zu einem ernsthaften Einsatzgerät geworden, sei es als Media-Viewer, kleiner NAS / Cloudspeicher, als Zentralrechner in der Heimautomation u.v.m.

    Bei einigen Anwendungsfällen ist ein gelegendliches (auch kurzzeitiges) Ausfallen von Grundfunktionen wie dem Netzwerk nicht tolerabel (Wenn ich so ein Gerät z.B. in der Heimautomation in Zusammenarbeit mit Brand/Wasser/Leakagemeldern betreibe, möchte ich mich auch drauf verlassen können).

    Jetzt kann man sich hinstellen und sagen: "Wer noch bei Trost ist, setzt so einen Spielzeugcomputer doch nicht für sowas (sicherheitsrelevantes) ein..." )
    Hm, ja. Kann man so sehen, wird aber gemacht. :)
    Und: Warum denn nicht ? Man muss es nur können :lol:

    (Wenn man sich die z.B. Brandmeldertechnik (z.B. aus dem Baumarkt) mal drinnen ansieht, und weiß, das sich das die Leute in die Wohnung hängen und drauf verlassen, relativiert sich so einiges...) :s

    Insofern (Zuverlässigkeit) hat es durchaus eine Berechtigung zu ergründen, woher diese diffus auftretenden Probleme herkommen.
    Natürlich kann man sich einen ByPass in Form eines Programmes wie Andreas bauen. Nennt sich Patch - z.dt. "Flicken" ... und das ist es auch: Ein Flicken zum Überdecken eines Problems... ;)

    Nun habe ich genau dieses Problem auf meinen RPs nicht, dennoch interessiert es mich und ich verfolge die Threads mit den entsprechenden Problemmeldungen.
    Allerdings beschleicht mich öfters das Gefühl, das Problem sitzt vor der Hardware (Layer 8 Problem) :lol:

    Nun ja. Vielleicht kommen noch andere Beiträge/Indizien, die uns hier bei der Lüftung dieses Phänomens weiterhelfen...

  • Hey Andreas: gute Arbeit!



    1. Aus den Oszillogrammen von Zentris :danke_ATDE: folgt, dass in periodischen Abständen der Stromverbrauch extrem ansteigt und dann wieder abfällt. Es ist wohl noch vollkommen unklar, was da im Einzelnen passiert. Ist hierfür ein periodischer Prozess verantwortlich? Gibt es vielleicht mehrere Prozesse, die um Strom "buhlen" und sich gegenseitig mit immer mehr Strom versorgen lassen, bis es "knallt"?

    Was mir jetzt gerade so ganz spontan einfällt ist der ntpd. Wenn ich dessen Funktionsweise richtig in Erinnerung habe, baut der regelmäßig zu mehreren Servern gleichzeitig (hohe Netzlast?) eine Verbindung auf, und nimmt als Referenz die Zeit vom ersten, der antwortet.


    Zitat


    3. Das Stromeinsparen betrifft wohl auch mal den USB-Bus, der zusammen mit LAN von einem Bauteil (LAN 9512, LAN9513 oder LAN9514) gesteuert wird. Meistens geht dieser Ablauf reibungslos über die Bühne. Der USB-Teil wird automatisch wieder reaktiviert - gelegentlich aber bleibt seitens des Betriebssystems eine Reaktivierung des LAN / WLAN aus.

    Zu der Sache mit dem Nichtwiederaufwecken passt übrigens diese Meldung aus dem Syslog:

    Code
    Apr 11 13:56:29 raspberrypi kernel: [   27.417315] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup


    Zitat


    FRAGE an Euch: Welches Modell des LAN951x ist bei Euch verbaut? Und wie häufig beobachtet Ihr das Mysterium?

    In meinem Syslog steht ab und zu diese Meldung:

    Der letzte Eintrag ist interessant. Sehe ich das richtig: haben die einen USB2Ethernet-Adapter verbaut?

    Und das angeblich 5 Ports gefunden werden, verstehe ich auch nicht: der Pi hat nur 2 USB-Ports. :s



    Nun habe ich genau dieses Problem auf meinen RPs nicht, dennoch interessiert es mich und ich verfolge die Threads mit den entsprechenden Problemmeldungen.
    Allerdings beschleicht mich öfters das Gefühl, das Problem sitzt vor der Hardware (Layer 8 Problem) :lol:


    Ein Layer8-Problem würde aber bedeuten, daß die Entwickler der Hardware und/oder des Betriebssystems für diesen Fehler verantwortlich sind. Würde es sich um einen Fehler "von außen" handeln, müssten ihn alle der betroffenen Anwender provoziert haben, z.B. durch die Installation eines bestimmten Programms oder durch Basteln an der Harware.

    Aber es scheint keine solche Gemeinsamkeit zu geben.

    Einmal editiert, zuletzt von PInguin (13. April 2014 um 00:00)

  • Hallo Zentris,


    ...
    Der RPi ist zwar als Bastelcomputer gestartet, jedoch bei so einigen (vielen?) inzwischen zu einem ernsthaften Einsatzgerät geworden, sei es als Media-Viewer, kleiner NAS / Cloudspeicher, als Zentralrechner in der Heimautomation u.v.m.
    ...

    Da der RPi weder in der Lage ist, sich selbstständig weiter zu entwickeln noch etwas an der Hardware geändert wurde, ist er immer noch das, als was er gestartet ist ... oder seh ich das falsch?
    Dass der eine oder andere den RPi zweckentfremdet, und damit zufrieden ist, erscheint mir aufgrund des Preises zwar logisch, aber imho ist da der Frust schon vorprogrammiert - oder würdest Du ein iPhone der ersten Generation, und nichts anderes ist der RPi, als Mediacenter einsetzen?
    Deshalb empfinde ich auch solche Schoten wie "Hochverfügbarkeit" durch USVs als absoluten Blödsinn.
    Und wenn ich ein Mediacenter brauche, dann kaufe ich mir eins - aber sicher keinen RPi. Wenn ich beim einen oder anderen mal die Peripheriekosten, mal ganz abgesehen vom Arbeitsaufwand, aufsummiere, dann komme ich auf ein stattliches Sümmchen, für das ich ein z.B. speziell als Mediacenter zugeschnittenes Gerät bekomme. Wenn ich dann noch die, für mich eher zweifelhafte, Qualität und Zuverlässigkeit einbeziehe ... naja.
    Dasselbe gilt imho genauso für z.B. den Einsatz als produktiver NAS, Steuerungsrechner, ...
    Du kaufst Dir ja schliesslich auch keinen Traktor, wenn Du jeden Morgen 50 km zur Arbeit fahren musst, auch wenn Du ihn sicher irgendwie auf 120 km/h trimmen kannst. ;)

    Wie gesagt: Lernfaktor phänomenal :thumbs1:
    Alles andere ist und bleibt für mich Zweckentfremdung. Das ist allerdings meine persönliche Meinung.

    cu,
    -ds-

  • Hallo Zentris,

    meine Aussage

    Zitat

    Der Raspberry Pi ist und bleibt ein Bastelcomputer, der vielen Zeitgenossen den Horizont ganz gewaltig erweitert hat.

    bitte ich nicht falsch zu verstehen :D .

    Ich habe letztes Jahr einen Welt-Marktführer der Medizintechnik beraten. Ich sollte ein von diesem Unternehmen erworbenes Gerät qualifizieren und damit den Nachweis erbringen, dass die von diesem Gerät erzeugten Produkte für den US-amerikanischen Markt geeignet sind und das Gerät den Anforderungen der US-amerikanischen Lebensmittelbehörde FDA genügt.

    Das erste Gerät fiel kurz vor Test-Ende durch - Gerät kaputt.

    Ersatzgerät wurde bereitgestelt - gleiches Ergebnis. Test an der gleichen Stelle - Gerät kaputt

    Dann habe ich meinen Testplan mit dem Hersteller ausgetauscht.. Die konnten keine "bösen" Tests erkennen.

    Dann haben wir ein anderes - robusteres - Gerät bekommen. Das war dann so robust, dass es kein CE-Kennzeichen hatte - und somit schon mal gar nicht eingesetzt werden durfte. Auch war der Hersteller nicht in der Lage, eine EG-Konformitätserklärung beizubringen.

    Im Scherz habe ich angeboten, dass ich so ein Teil auch selbst entwickeln könne.

    Ich habe tatsächlich einen Entwicklungsauftrag erhalten, als Berater (!) Hard- und Software zu entwickeln.

    Da ich keine Vorgaben über die Umsetzung hatte, habe ich mich natürlich für einen Raspberry Pi als zentrales Element entschieden. Die restliche Hardware basierend auf einem Raspberry Pi selber war schnell beisammen - die Software zum Steuern der Maschine lief nach 2 Stunden soweit, dass man erkennen konnte, dass da keine großen Hürden auftauchen werden.

    Irgendwann war die Entwicklung des Gesamtpaketes bis zur vollständigen Funktionalität abgeschlossen. Aber mein Gerät wurde nicht mehr als einfache Produktionsmaschine qualfiziert, sondern musste den wesentlich höheren Anforderungen eines Computersystems genügen. Tests, die ich an den ersten drei kommerziellen Geräten nicht durchführen durfte, um Schäden zu vermeiden, wurden bei meinem Gerät zu Standard-Tests. Meine Software musste Fehlbedienungen erkennen und darauf reagieren, bevor die Hardware geschädigt wird - und im Fehlerfall den Fehler sebständig beheben.

    Ich bin mir sicher, wenn ich solche haarsträubenden Tests an den ersten drei Geräten durchgeführt hätte, hätte ich seitens des Herstellers wegen "Missbrauch" die Garantieansprüche verloren.

    Für mich ist der Raspberry Pi zwar ein Bastelcomputer, der aber - wenn richtig eingesetzt - Nischen besetzen kann, wozu preislich und vom Platzbedarf her kaum Alternativen bestehen.

    Nach diesem Entwicklungsprojekt weiß ich, dass der Raspberry Pi industriell volltauglich ist - und höchsten Ansprüchen gerecht wird.


    ABER:

    Bei sicherheitskritischen Anwendungen würde ich es nicht wagen, mich nur auf einen einzigen Raspberry Pi zu stützen. Durch diesen und andere Threads wissen wir, dass das Netzwerk bei nicht vollkommen verstandenen Umständen unterbrochen wird. Da der Raspberry inkl. Sensoren nicht sonderlich viel kostet, würde ich hier immer mit einer ordentlichen Redundanz der Systeme arbeiten. Zum Glück gibt es auch Alarmsysteme, die bei Wasserrohrbruch / Feuer auch ohne einen Raspberry Pi in der Lage sind, Alarm zu geben.

    In der Luftfahrt ist es auch üblich, mehrere Boardcomputersysteme einzusetzen, die sich gegenseitig überwachen und Störungen melden, sobald einer aus der Reihe tanzt.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Da der RPi weder in der Lage ist, sich selbstständig weiter zu entwickeln noch etwas an der Hardware geändert wurde, ist er immer noch das, als was er gestartet ist ... oder seh ich das falsch?

    Das war so gemeint, dass der ursächlich Zweck des RPs ja dafür gedacht war, (junge) Leute die MC-Programmierung näher zu bringen.. so in der Art.

    Nun hat sich der RP (natürlich) :lol: nicht selbst weiterentwickelt, aber die Zielgruppe ist breiter geworden...


    Deshalb empfinde ich auch solche Schoten wie "Hochverfügbarkeit" durch USVs als absoluten Blödsinn.


    Nope:
    Wie schon geschrieben wird der RP auch in komplexeren Geräteschaften eingesetzt, die ein brutales Ausschalten nicht sonderlich gut finden.
    Sinnvolle Anwendungsfälle für eine USV gibt es viele, sei es zu verhindern, dass eine unvollendete Schreiboperation das FS ruiniert oder das "einfache" Umschalten zwischen verschiedenen, zeitlich verfügbare Stromquellen (Solarstrom, Windstrom usw. auf Akku und zurück).

    Eine USV ist (kann) ein Baustein bzgl. HV sein... aber da gehört noch sehr viel mehr dazu...! :thumbs1:


    Und wenn ich ein Mediacenter brauche, dann kaufe ich mir eins - aber sicher keinen RPi. Wenn ich beim einen oder anderen mal die Peripheriekosten, mal ganz abgesehen vom Arbeitsaufwand, aufsummiere, dann komme ich auf ein stattliches Sümmchen, für das ich ein z.B. speziell als Mediacenter zugeschnittenes Gerät bekomme. Wenn ich dann noch die, für mich eher zweifelhafte, Qualität und Zuverlässigkeit einbeziehe ... naja.


    *unterschreib*


    Dasselbe gilt imho genauso für z.B. den Einsatz als produktiver NAS, Steuerungsrechner, ...


    Hm, da zittert der Stift :lol:
    NAS: Naja, mit dem RP eher eine Spielerei, da bin ich bei dir,
    aber Steuerrechner? Nö, Nö... :lol:
    Ich "bastle" gerade an einer Steuerung und kann dir sagen, sowas gibt es nicht für Geld zu kaufen, jedenfalls nicht dreistellig... und nicht mit den Eigenschaften... :)


    Wie gesagt: Lernfaktor phänomenal :thumbs1:
    Alles andere ist und bleibt für mich Zweckentfremdung. Das ist allerdings meine persönliche Meinung.


    Yupp, der Lern/Motivationsschub ist genial.
    Das Schönste ist, man muss ja nicht immer einer Meinung sein und kann sich trotzdem austauschen :thumbs1::thumbs1:


    ABER:
    Bei sicherheitskritischen Anwendungen würde ich es nicht wagen, mich nur auf einen einzigen Raspberry Pi zu stützen. Durch diesen und andere Threads wissen wir, dass das Netzwerk bei nicht vollkommen verstandenen Umständen unterbrochen wird. Da der Raspberry inkl. Sensoren nicht sonderlich viel kostet, würde ich hier immer mit einer ordentlichen Redundanz der Systeme arbeiten. Zum Glück gibt es auch Alarmsysteme, die bei Wasserrohrbruch / Feuer auch ohne einen Raspberry Pi in der Lage sind, Alarm zu geben.

    In der Luftfahrt ist es auch üblich, mehrere Boardcomputersysteme einzusetzen, die sich gegenseitig überwachen und Störungen melden, sobald einer aus der Reihe tanzt.

    Da bin ich absolut bei dir !!!
    (Obwohl, die (Decken-)Feuermelder die ich schon gesehen habe.... oO..)

    Und: Gratulation zu dem Projekt, das du da gestemmt hast *Hut ab* :thumbs1::thumbs1:

  • Hai oder so ;),

    ja, schöne Sache ... macht total Spass und das schönste Spielzeug seit den Matchbox-Autos aus meiner Kindheit :) ...

    Ein Aspekt contra den produktiven Einsatz, den ich persönlich wichtig finde, fehlt imho noch:
    Für produktive Industrie-Computer wird afaik sehr lange Support geleistet - das gilt für Ersatzteile, Tauschgeräte und Reparaturen aber auch für die Software.
    Wie das beim RPi aussieht, kann ich nicht beurteilen - deshalb ist allein das schon ein k.o.-Kriterium.

    Ein ganz dickes pro ist m.E. die Open-Source Plattform. Zwar gehe ich mal davon aus, dass die meisten End-Benutzer/-Kunden keine Fehler im Linux reparieren können ... aber das ist egal.

    Wie gesagt - im Prinzip ist m.E. jeder Einsatz ok. Allerdings finde ich, dass es dann nicht angebracht ist zu jammern oder fluchen, wenn irgendwas nicht so tut wie man wollte.

    Aber ich glaube, jetzt wird es hier langsam zu sehr OT ... nicht dass einer der Mods jetzt schimpft ... :daumendreh2:


    cheerio,
    -ds-

  • Jo, wir sind echt schon sehr OT :lol:
    (aber gut, dass wir mal drüber gesprochen haben :thumbs1:=

    Mal back to the roots:
    Ich würde das mit den Oszi-Bildern (bzgl. den Strom-Peaks) gerne mal vertiefen und suche ein Progrämmchen, das mir den Prozessor möglichst gut auslastet (was reproduzierbares, vielleicht auch den Grafikchip bei Bedarf mit auslastet...)

    Was könnt ihr da empfehlen?

  • Also Du bist der Meinung, dass diese Peaks für dieses Fehlverhalten verantwortlich oder zumindest daran beteiligt sind sind?
    Und was suchst Du jetzt genau: Last auf die CPU, Last auf (Funk-)Netz, Last auf angeschlossene Peripherie, Last auf eigene Komponenten (SD-Karte, USB, ...)?

    Ich denke, da gibts Progrämmchen wie Sand am Meer, mir fallen da ad hoc die fork-bomb und die Berechnung von Pi ein - die hätte sogar Bezug zur Hardware. :lol:
    Wichtig ist imho nur, dass es möglichst Programme sind, die auf/für den RPi übersetzbar sind, also Sourcen.

    Ich werde auf so was mal verstärkt achten, wenn ich mal wieder unterwegs bin.

    bis denne dann,
    -ds-

  • Hallo Zentris, hallo Dreamshader,

    ein Programm zur Berechnung von Pi könnte ich beisteuern. Ich habe da mal was programmiert, das pi auf tausende von Nachommastellen berechnet - basierend auf Large Integer Arithmetik. Das verbraucht auch ordentlich viel Speicher, je mehr Stellen zu berechnen sind.

    Ein Graphik-Programm habe ich auch geschrieben. Dort werden 15 Fenster geöffnet. Auf jedem Fenster werden zufällig alle möglichen Objekte in zufälligen Farben gezeichnet bzw. ausgefüllt.

    Beide Programme lasten die CPU des Raspberry Pi zu 100 % aus.

    Zitat

    Ein Aspekt contra den produktiven Einsatz, den ich persönlich wichtig finde, fehlt imho noch:
    Für produktive Industrie-Computer wird afaik sehr lange Support geleistet - das gilt für Ersatzteile, Tauschgeräte und Reparaturen aber auch für die Software.
    Wie das beim RPi aussieht, kann ich nicht beurteilen - deshalb ist allein das schon ein k.o.-Kriterium.

    Wie gesagt, mein Projekt letztes Jahr war in der Medizintechnik. Die tun sich ganz schwer mit Updates jeglicher Art. Der Raspberry Pi, der in einer grauen Kiste eingefangen ist, wird ganz sicher bis zur Verschrottung kein einziges Update des Betriebssystems oder der Anwendung erfahren, weil die Anwendung innerhalb einer definierten Umgebung validiert wurde. Validierung bedeutet, dass sie in dieser Umgebung für alle Zukunft - ohne Änderung - zuverlässig arbeiten wird. Somit ist es keine Kundenforderung, noch in Jahren Updates erhalten zu können.

    Das Ganze war sogar so absurd, dass ich das Entwicklungssystem mit dem brandaktuellen Raspbian Wheezy 2013-07-26 aufgesetzt habe. Als es dann an die Erstellung der Validierungsdokumente und dem Sammeln der Validierungsnachweise und Dateien ging, gab es diese Raspbian Wheezy-Version nicht mehr. Es war ein Riesenakt, von irgendwoher noch eine entsprechende Datei zu erhalten.

    Aber Du hast Recht, "normalerweise" sollte ein Support seitens des Herstellers über Jahre hinweg gesichrt sein.

    Wenn wir irgendwelche Geräte zur Herstellerwartung einschicken - oder Servicetecniker vorbeikommen - legen wir immer Wert darauf, dass an der Firmware nichts geändert wird.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (13. April 2014 um 02:05)

  • Hallo ihr beiden:
    Ja, ich folge derzeit mal der Arbeitsannahme (oder auch Wahnvorstellung :lol:), dass die Peaks mit den Ausfällen etwas zu tun haben - in Zusammenhang mit einem "schwachen" NT...

    Ich habe "auf die schnelle" sysbench gefunden, damit kann man die CPU und/oder das Filesystem schonmal unter Dampf setzten.

    Hab das auch gerade mal versucht:

    Code
    sysbench --test=cpu --cpu-max-prime=20000 run


    bringt eine fast 100%tige CPU-Auslastung.
    Der Part lief ca. 10min bei mir ohne Befund (kein hängen, kein WLAN-Verlust, kein Hitzeschaden) habe leider aktuell keine Messgeräte am RP, mach ich morgen...

    Dann habe ich mit

    Code
    sysbench --test=fileio --file-total-size=2G --file-num=16 prepare


    auf einem Netzlaufwerk (!) 16 Files a 128k anlegen lassen (dauerte knapp 10 min)
    und dann mit

    Code
    sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 --file-num=16 run


    den Random-RW Test gestartet (läuft 5min)

    Dieser Test verursacht nun, da die Files remote auf dem NAS liegen, massive Netzlast über WLAN.
    Der Test lief sauber durch:

    Spoiler anzeigen


    So, der WLAN-Stick (edimax) hat sich, nun ja , etwas erwärmt (ca. 50°C) Gehäusetemperatur.

    Warum hab ich das gemacht: Es wurde auf Abstürze bei erhöhter Netzlast hingewiesen... könnt ihr das mal nachmachen, ob eure PRs bei einem solchen Test ebenfalls stabil bleiben oder da schon einbrechen? :huh:

    Ich mache morgen (Abend) die Tests nochmal mit Messung Stromaufnahme/Spannungsverlauf.

  • Hallo Zentris,

    weiterhin vielen Dank für Deinen Einsatz,

    Die kürzeste Zeitspanne, innerhalb der sich beim mir das Mysterium wiederholt ereignet hat, war ca. 1 Stunde. Daher halte ich einen 5- oder 10 minütigen Test für zu kurz. Ich glaube auch nicht, dass das Mysterium durch DEN Test schlechthin zu 100 % reproduzierbar wird.

    Als Test-Szenario würde ich mir etwas wie
    - Download vieler kleiner oder großer Dateien vorstellen: Hier habe ich ein Programm, das über wget Verzeichnisse aus dem Internet herunterlädt.
    - Parallel dazu kopiert ein anderes Programm diese oder andere Dateien über LAN auf USB-Medien, von USB-Medium auf andere USB-Medien
    - Midori sollte parallel laufen und im Rahmen der Möglichkeiten bedient werden (Midori ist mein Favorit für die Software, die am ehesten schwächelt und dieser Fehelr zur Geltung kommt)
    - Wenn dann noch ein Virenscanner ein USB-Medium durchsucht, kann ich mir vorstellen, dass LAN-/USB maximal gestresst ist und das Mysterium gehäuft - vielleicht sogar innerhalb Minuten redproduzierbar auftritt.
    - um einen Einfluss (?) der GPU auszuschließen, zeichnet ein Graphik-Programm bunte Bildchen auf den Bildschirm

    vorstellen.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (13. April 2014 um 10:22)

  • Hallo!

    Darf ich noch mal kurz auf meinen Beitrag (#46) hinweisen? Ich würde gerne wissen, ob ich das richtig interpretiere: besteht der Netzwerkadapter in Wirklichkeit aus einen USB2Ethernet Adapter? Würde Sinn ergeben, wenn, wie bereits hier erwähnt wurde, der Controller für USB und Netzadapter derselbe ist.

    Und wieso werden 5 Ports gefunden, wenn der Pi nur 2 Anschlüssen hat?

    Und letztlich: kann der Fehler damit zusammenhängen? Ist vielleicht das USB-System fehlerhaft?

    Das würde für mich diese Meldung erklären:

    Code
    smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup


    Auslastungs-Tests:

    Ich hatte vor einiger Zeit aus Spaß ein rekursives Shell-Skript zur Lösung der Türme von Hanoi geschrieben. Mit 100 Steinen sollte den Pi auf alle Fälle "etwas" belasten. Ich suchs mal raus und schreibe es hier rein.

  • Hallo Pinguin,


    Zitat

    Darf ich noch mal kurz auf meinen Beitrag (#46) hinweisen? Ich würde gerne wissen, ob ich das richtig interpretiere: besteht der Netzwerkadapter in Wirklichkeit aus einen USB2Ethernet Adapter? Würde Sinn ergeben, wenn, wie bereits hier erwähnt wurde, der Controller für USB und Netzadapter derselbe ist.

    Die beiden USB-Buchsen und die LAN-Buchse werden von einem einzigen Baustein (LAN951x), das ist der zweitgrößte quadratische Chip auf der Platine, gespeist. Das ist auch der Grund weshalb die Übertragungsraten so gering sind, weil eben alles über einen Baustein geht und sich die maximal mögliche Übertragungsrate auf mehrere Anschlüsse aufteilt.


    Zitat

    Und wieso werden 5 Ports gefunden, wenn der Pi nur 2 Anschlüssen hat?


    Dass Dir 5 USB-Ports gemeldet werden, hat mit der Anzahl der (2) USB-Buchsen gar nichts zu tun.

    Jedes Teil, das am USB angeschlossen ist, wird als solches erkannt.

    - 2 Buchsen hast Du eh...
    - eine Maus vielleicht
    - eine Tastatur vielleicht
    - ein Y-Kabel für Maus und Tastatur, damit eine USB-Buchse für einen aktiven USB-Hub frei bleibt

    Da werden aus 2 ganz schnell mal 5 und mehr...

    Zitat

    Und letztlich: kann der Fehler damit zusammenhängen? Ist vielleicht das USB-System fehlerhaft?

    Diesen Gedanken streue ich seit geraumer Zeit hier ein. Aus einem noch zu identifizierenden Grund wild nicht reproduzierbar USB & LAN abgeschaltet. USB wird erfolgreich zurückgesetzt, bei LAN bleibt es aus. Schlimmer noch, gelegentlich "verliert" der Raspberry Pi seine IP-Adresse und noch seltener auch die des Routers / Gateways.

    Die Reaktivierung ist eigentlich ein Zweizeiler (s. mein Programm), wird aber seitens des Betriebssystems nicht angestoßen. Und wir diskutieren hier, ob ein Patch wie meiner nun "schicklich" ist - oder wir viel Zeit investieren wollen, um das Mysterium zu verstehen - um dann gezielt etwas zu anzustoßen.

    Mit den Türmen von Hanoi lastest Du den Prozessor aus - aber weder LAN- noch USB-Verkehr.

    Sollte Bedarf bestehen, würde ich mich anbieten, ein Stresstest-Programm zu schreiben, wie ich es vorhin als Test-Szenario beschrieben habe. Ein Programm, das alles parallel macht und die CPU, die GPU, LAN- und USB maximal stresst.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • ...
    besteht der Netzwerkadapter in Wirklichkeit aus einen USB2Ethernet Adapter?
    ...

    Das ist wohl so. Der RPi greift wohl über USB auf das LAN zu. Das ist mit ein Grund für den grottenschechten Durchsatz. Bei Slashdot hatte ich -> das hier <- mal gefunden.


    ...
    Und wieso werden 5 Ports gefunden, wenn der Pi nur 2 Anschlüssen hat?
    ...

    Da hab' ich noch was im Hinterkopf, dass der RPi ja einen internen Hub hat von dem aber nur zwei Ports nach aussen geführt wurden. Die anderen Ports verwendet die CPU selbst ( z.B. für diesen USB2Ethernet Adapter ).


    ...
    Und letztlich: kann der Fehler damit zusammenhängen? Ist vielleicht das USB-System fehlerhaft?
    ...

    Das war ja Zentris Idee, wenn ich ihn richtig verstanden habe, und erscheint auch irgendwie logisch.
    ifplugd war bei mir scheinbar der Übeltäter. Seit ich den deinstalliert habe laufen die RPi mittlerweile 40 Tage und mehr im Dauerbetrieb.

    bis dann mal,
    -ds-


  • Das ist wohl so. Der RPi greift wohl über USB auf das LAN zu. Das ist mit ein Grund für den grottenschechten Durchsatz.


    Also der Durchsatz würde mich nicht wirklich stören, wenn er nicht abstürzen wäre. Zumal ich sowieso nicht mehr als 10 MBit nach draußen bekomme.

    Zitat


    Bei Slashdot hatte ich -> das hier <- mal gefunden.

    Oh man, die Beiträge sind mehr als 1,5 Jahre alt. Und seit dem hat sich noch niemand genügend dafür interessiert, um das Problem zu lösen. :(

    Zitat


    Das war ja Zentris Idee, wenn ich ihn richtig verstanden habe, und erscheint auch irgendwie logisch.
    ifplugd war bei mir scheinbar der Übeltäter. Seit ich den deinstalliert habe laufen die RPi mittlerweile 40 Tage und mehr im Dauerbetrieb.

    Der kann es aber nicht alleine sein, denn den habe ich schon lange deinstalliert, und trotzdem habe ich manchmal Stillstand.

    Aber die Idee mit dem USB->Netzwerk Adapter bringt mich auf eine Idee: ich werde jetzt doch mal angehen, mir den Kernel selber zu übersetzen und dabei die Unterstützung für USB2 und/oder USB3 rauszunehmen. Zumindest werde ich aber sehr genau prüfen, welche Optionen für USB überhaupt aktiviert sind.

    Diesen Beitrag hier von der oben genannten Adresse bei SlashDot finde ich schon irgend wie sehr sarkastisch:

    Zitat

    Slightly exaggerated I feel (4, Insightful)
    Anonymous Coward | about a year and a half ago | (#41116499)

    A buggy driver (which can be fixed) is hardly a "serious problem" - give it time, distros and drivers are still progressing on the RasPi

    "Irgendwer wird's irgendwann schon mal geradebiegen."

    Was für eine Einstellung! Wie kann man so durch's Leben gehen?

    Und auch das Argument, daß der Pi nur 35Dollar/50Euro kostet und man dafür nicht mehr als einen Experimentierbaukasten erwarten darf, lasse ich überhaupt nicht gelten! Ein Experimentierbaukasten, den ich für meinen Sohn kaufen würde, muss auch funktionieren. Wenn die Hälfte der Experimente nicht funktionieren würde wegen fehlerhafter Zutaten, dann könnte mich der Verkäufer oder der Hersteller auch nicht mit dem Satz vertrösten "Was haben Sie für 50 Euro erwartet?"

    Nebenbei: ich möchte mal wissen, wie viele Benutzer des Pi sich schon gewundert haben, warum ein bestimmtes Experiment oder ein selbstgeschriebenes Programm nicht funktioniert.

    Da ist der Hinweis auf den niedrigen Preis doch kein Argument! Jedes Gerät, das verkauft wird, hat einwandfrei zu funktionieren, egal ob es 5, 50 oder 50.000 Euro kostet! ::mad_GREEN:

    Einmal editiert, zuletzt von PInguin (13. April 2014 um 13:11)

  • Mahlzeit PInguin ...

    prinzipiell kann ich Dir da nur zustimmen.


    ...
    "Irgendwer wird's irgendwann schon mal geradebiegen."

    Was für eine Einstellung! Wie kann man so durch's Leben gehen?
    ...


    Guck mal nach Bärlin - da ist das bei Mutti an der Tagesordnung :fies:

    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!