Pi nicht mehr per Netzwerk erreichbar, aber aktiv


  • unter "Heavy Network loads" verstehe ich eigentlich etwas anderes.

    Dazu fällt mir gerade noch ein: apt-upgrade macht bestimmt das, was man eine "hohe Netzwerklast" nennen könnte, denn es baut viele Verbindungen gleichzeitig auf, um nach Paketen zu suchen. Und gerade bei der Benutzung von apt habe ich bisher die meisten Aussetzer erlebt.

    Siehe Ansturz nach Benutzung von apt-get oder aptitude


    Das gemessene NT ist das bisher stabilste, was ich für den RP in der Hand hatte !

    Welches Netzteil meinst Du damit?

    Einmal editiert, zuletzt von PInguin (4. April 2014 um 12:29)

  • Hallo Pinguin,

    die Sache wird immer verrückter.

    Ich ging bis eben noch davon aus, dass die ganzen Update/Upgrade-Sachen keine so große Netzwerkbelastung darstellen. Dies war nämlich bislang die einzige Gelegenheit, bei der das Mysterium noch NIE auftrat.

    Wir haben allerdings eine 46kB-Anlage (k = kilo - nicht M wie Mega), auf der die Daten gemächlich dahin schlendern können.

    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.

  • NT: Das hier.

    Liefert "nur" 500mA, aber stabil wie ein Stein :)
    Wird (natürlich) bei der Last warm, da das Gehäuse wech ist, sollte aber die Kühlung sogar besser als zuvor sein...

    Da meine RPs damit hinkommen, hab ich die verwendet: Leichter Schlag auf die hohe Kante des Gehäuses und die Plastikschalen fallen auseinander, die Innereien dann verbaut...

    iqcbvwzz.jpg

    Wie schon gesagt: Mit diesem NT dran hab ich schon Dauerbetrieb der RPs über mehr als 3 Wochen gehabt, ohne einen einzigen Aufhänger (war eine Langzeit-Temperaturüberwachung, wo ich per WLAN auf den internen Web-Server zugreifen und die Temperaturkurven ansehen konnte...)


  • Ich ging bis eben noch davon aus, dass die ganzen Update/Upgrade-Sachen keine so große Netzwerkbelastung darstellen.


    Da wäre ich nicht so sicher: apt baut viele Verbindungen gleichzeitig auf, um die Pakete herunterzuladen, und zwar, wenn ich das richtig erkenne, abhängig davon, wie schnell sie eintrudeln. Mit anderen Worten: apt versucht, die zur Verfügung stehende Bandbreite voll auszunutzen. Ist ein Server nur mit 128kB zu erreichen, werden halt mehrere Server angesprochen, bis die Leitung ausgenutzt ist.

    Zitat

    Dies war nämlich bislang die einzige Gelegenheit, bei der das Mysterium noch NIE auftrat.

    Für alles gibt's ein erstes mal. :D

    Zitat

    Wir haben allerdings eine 46kB-Anlage (k = kilo - nicht M wie Mega), auf der die Daten gemächlich dahin schlendern können.


    Ja, dann hast Du genau den Fall, daß apt die Netzlast gar nicht höher schrauben kann. Das ist dann aber bestimmt eine Ausnahme, ich glaube nicht, daß es viele Benutzer gibt, die eine solch kleine Leitung ins Netz benutzen. Und auch, wenn jetzt hier spontan 10 Leute aufschreien und sagen "Stimmt nicht: ich habe weniger als 100kb", sind das trotzdem nicht viel gemessen an der Gesamtzahl der Pi-Benutzer!

    Zentris: schönes Netzteil! Wie hoch ist denn laut Deinen Messungen die Dauerstromaufnahme des Pi?

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

  • Zitat

    Zentris: schönes Netzteil! Wie hoch ist denn laut Deinen Messungen die Dauerstromaufnahme des Pi?

    Ok, dann hau ich mal ein paar Bilder ein:
    Vorweg zum Messaufbau:
    * Der Shunt hat 0,12 Ohm, liegt in der (+) Leitung vom Netzteil, der Strom wird dann über einen der GPIO-Pins in den Raspi eingespeist.
    * Der Oszi kann so konfiguriert werden, dass man das Strom/Spannungsverhältnis eingibt, also bei mir hier: Bei 1A fallen 0,12V am Shunt ab (der Shunt ist ein 5% Typ, ich habe ihn nicht extra vermessen) ... das stellt man ein. Dann kann man mit dem Cursoren direkt den aufgezeichneten Kurvenverlauf vermessen.

    Für alle Bilder gilt: RasPi im "Leerlauf", ssh-Connection per WLAN, "top" auf dem Terminal aktiv mit 1s Refreshzeit, mysql-DB gestartet, web-server gestartet, aber keine Abrufe.

    Bild 1: (unten)
    Links die [1] ==> y1 stellt die Nullinie des Stromes dar.
    y2 steht auf dem "Grundwert des Stromes, hier also bei rund 307mA.

    ithuf5bl.png

    Bild 2: (unten)
    Links die [1] ==> y1 stellt die Nullinie des Stromes dar.
    y2 steht auf der höchsten momentanen Stromspitze, hier ca. 780mA

    sul5xmfy.png

    Bild 3 und 4: (unten)
    Hier die Zeitmessung der Impulse:
    Dazu muss gesagt werden, dass die beobachteten Impulse mit beiden Impulsabständen auftraten, jedoch nicht determiniert. Ich habe keinen Plan, woher diese Impulsbelastung kommt....

    Bild 3:
    Pulsabstand ca. 31,4 microsek. (ca. 31,85kHz)

    Bild 4:
    Pulsabstand ca. 17,7 microsek (ca. 56,6kHz)

    7uy7q2zw.png
    ggtsc5ml.png


    So, das sind so die 1. Messungen, die ich gemacht habe. :)
    Was fehlt ist die Spannungsmessung parallel zur Strommessung. Diese Bilder hab ich noch nicht vom Gerät runtergenommen, kommt dann später mal... :thumbs1:

    Ich vermute mal, dass diese herben Stromspitzen Handynetzteile durchaus "ins Schlingern" bringen können, wenn die Pufferkondensatoren das nicht abfedern. Normale Elkos dürften bei diesen Frequenzen schon nicht mehr so wirksam sein, oder? :denker:

    Nun, ich würde mich jetzt mal über Statements zu diesen Strom-Spitzen freuen, mir sind sie nämlich derzeit noch etwas mysteriös... :s

  • Der Aussage "NT mit xyz mA reicht" möchte ich an dieser Stelle (erneut) vehement widersprechen:

    Es kommt einerseits sicherlich auf den maximalen Strom an, den das NT überhaupt in der Lage ist, zu liefern.

    Andererseits aber auch auf die Spannunghöhe, die bei dem Strom, den der RPi in seinem "stromhungrigsten" Betriebszustand benötigt, noch von NT aufrechterhalten wird.
    Manche (auch 2A Handynetzteile) brechen gerne bei ihrer Nennlast oder eher auf unter 4,5V ein - was für das Laden eines Handys reicht, für den RPi aber definitiv nicht mehr)

    Weiterhin auf die Schaltungsauslegung des NT's "an sich": Wenn die Ripplespannung zu groß ist, wird der zuverlässige Betrieb des RPs natürlich auch in Frage gestelle sein...
    Überhaupt: ist das NT pulsstromfest? Wie oben zu sehen ist, liegt da quasi periodisch ein ca.400mA Stromimpuls alle paar Microsekunden auf der Leitung - wenn der Spannungswandler NT dadurch "ausser Tritt" (Stichwort Resonanz) gerät, ist auch Essig mit Strom :(

    M.M. nach scheint nach den oben dargestellten Messergebnissen das Thema Netzteil noch lange nicht gegessen zu sein.

    Die "0815" "1A....1,5A...2A" Handynetzteile können funktionieren, müssen es aber nicht, definitiv.
    Das hat übrigens auch nix mit irgendwelcher "Chinaware" tu tun, die Teile kommen vermutlich zu >90% aus Fernost...!

  • Ich habe mir vor einiger Zeit einen Akku von Anker gekauft, um bei meinen Fahrradtouren meinen Taschenandroiden als Navi nutzen zu können, ohne daß mir das GPS den Akku leer saugt. Dieses Teil hier:

    http://www.amazon.de/13000mAh-Externer-Ladeger%C3%A4t-Smartphones-Android/dp/B00BQ5KHJW/ref=sr_1_7?ie=UTF8&qid=1396814118&sr=8-7&keywords=anker+akku&tag=psblog-21 [Anzeige]

    Dieser Akku tut seinen Dienst unterwegs hervorragend! Und er hat noch ein gewaltigen Vorteil: auf dem Campingplatz kann ich Abends den Akku an der Kasse zum Laden abgeben, und muss keine Sorgen um mein 10x so teures Telefon haben!

    Aber zurück zum Thema:

    Eine der USB-Buchsen ist mit "2A out" beschriftet. Was wäre denn wohl, wenn man so einen Akku als Puffer benutzen würde? Also den Pi an den Akku anschließen, und den Akku immer am Ladegerät lassen.

    Eigentlich müsste das Ladegerät doch zwischendurch immer mal wieder genügend Zeit haben, um mehr Strom in den Akku zu laden, als der Pi in Spitzenzeiten rausziehen kann. Oder was meinst Du als Fachmann dazu?

  • Stromtechnisch ist ein Akku natürlich toll, wenn die eingebauten Wandler mitspielen: hier gilt das gleiche wie bei den NT, weil ja in den Akkus aus der LiPo-Spannung von 3,2...4,1V die 5V Ausgangsspannung erzeugt werden müssen, das wird, wie in den modernen NT (auch) mit einem Schaltregler gemacht... wenn der nix taugt.... kritisch wird es, wenn der LiPo-Akku fast leer ist...

    Ich habe einen ähnlichen Akku gleicher Kapazität. :)
    Allerdings lässt mein Akku es nicht zu, gleichzeitig an seinen USB Buchsen Strom abzugeben, wenn der Ladestecker (Micro-USB) mit Strom zum Aufladen versorgt wird.... vielleicht ist das bei deinem anders. :s

    Mein Akku hat bei einem Test (nur Test, kein regulärer Betrieb) mal so ca. +9h durchgehalten, um einen (schwach belasteten) RPi zu versorgen. :thumbs1:

    Ergänzung:
    Ja, wenn die Energiebalance stimmt, sollte es reichen. Musst du ausrechnen, ich würde von einem Wandelwirkungsgrad von 80% ausgehen.


  • Allerdings lässt mein Akku es nicht zu, gleichzeitig an seinen USB Buchsen Strom abzugeben, wenn der Ladestecker (Micro-USB) mit Strom zum Aufladen versorgt wird.... vielleicht ist das bei deinem anders. :s

    Habe ich auch noch nicht ausprobiert. Bisher hat der Akku entweder mein Navi unterwegs versorgt, oder er hing nachts am Ladegerät. Aber jetzt, da Du es erwähnst, glaube ich, etwas derartiges in der Anleitung gelesen zu haben.

    Aber man könnte sich doch auch einen Pufferakku selber basteln. Für den Modellbaubereich gibt es doch bestimmt Akkus, die 5V liefern und auch einen Entladestrom von über 1A nicht mit Rauch quittieren. Oder man nimmt ein paar große Gold-Caps.

    Hey! Das wäre doch mal ein Projekt für den nächsten Urlaub: ein gutes gepuffertes Netzteil für den Pi basteln. :cool:

  • Mir würde ja so ein Multi-Input-Power-System vorschweben (nein, ich will nicht das USV-Modul für den RP für 30 Öcken kaufen!)

    Also ein Modul mit verschiedene Eingänge ((Mini/Micro)USB, (einfache)Klemmen, Klinkenbuchse(n)), die Eingangsspannungen von 1,5 - 30V vertragen und das dann die Spannung natürlich auf die 5V für den RP umsetzen kann (und, wenn konfiguriert, Akkus (Pb/NMh/LiPo) an den Eingangsklemmen läd, sofern vorhanden).

    Hintergrund:
    Einerseits USV-Funktionalität, andererseits "outdoor" Anwendungen, wo z.B. eine Solarzelle tagsüber versorgt und die Akkus läd, nachts dann Versorgung über Akku.

    Ich weiss, dass es dafür Interessenten gibt. Allerdings habe ich derzeit keine Zeit, da was zu entwickeln... =(

  • Um mal auf das eigentliche Thema zurückzukommen: ich habe gerade versucht, exim4 zu installieren, und da ging plötzlich gar nichts mehr! Das Netzwerk ist alle paar Sekunden zusammengebrochen und der Pi war nicht mehr erreichbar. Nur jeweils für ein paar Sekunden, nachdem mein Wachhund-Skript das Netzwerk neu gestartet hat. Mit Mühe konnte ich in einem dieser kurzen Zeitfenster den Befehl "apt-get remove --purge exim4 -y" eintippen.

    Danach läuft das Netzwerk wieder viel stabiler. Es scheint so, als wenn exim4 einer der Kandidaten ist, der "heavy netloads" verursacht, die das Netzwerk zum Zusammenbrechen bringen.

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

  • Nachdem gestern die Installation von "exim" völlig aus dem Ruder gelaufen ist (s.o.) habe ich danach Postfix installiert und habe seit dem keinen Ausfall des Netzwerkes mehr erlebt.

    Es scheint wirklich Anwendungen zu geben, die das Netzwerk vom Pi leichter zusammenbrechen lassen, als andere. Nach meinen Erfahrungen gehören "apt" und "exim" dazu.

  • Solange der Mechanismus des Zusammenbrechens des USB Subsystems nicht geklärt ist, ist das Spekulation. :s

    Warum z.B. hast du diese Probleme, ich (und viele andere vermutlich auch) können diese Programme vollkommen stressfrei benutzen?
    Gerade apt-get ist ja nun schon ein häufig verwendetes Tool... :huh:

    Für mich hört sich das immer noch nach Symptome an, nicht nach Ursache.
    Spannend wäre z.B., wenn man deinen RPi z.B. in meiner Umgebung laufen lassen könnte... (also Stromversorgung, Luftdruck, Höhenlage, Mondstand...) :lol::lol:

    Das Problem ist doch, dass ich das hier nicht nachstellen kann, insofern ist die Indizienlage schlecht. Ich weiss so aus der Hüfte auch keinen Weg.

    Aber mal ein Wort an die Schweigenden Mitleser: :lol::lol:
    Postet doch mal bitte, ob es die hier beschrieben Probleme auch bei euch gibt.
    :danke_ATDE:

  • Hmmm, ich hätte da noch so eine wilde Spekulatius. :D

    Ist wirklich sichergestellt, daß jeder verkaufte Pi (Model B) exakt diegleiche Hardware aufweist?

    Ich habe im Laufe meines IT-Lebens schon mehrfach erlebt, daß zwei anscheinend identische Stücke Hardware sich unterschiedlich verhielten. Ich erinnere mich noch an zwei "gleiche" Grafikkarten, die sogar unterschiedliche Treiberversionen verlangten!

    Der Grund dafür war: sie stammten aus verschiedenen Chargen aus verschiedenen Auftrags-Fabriken, und eine der Fabriken hat einen der Chips von einem anderen Dritt-Hersteller bezogen, der sich minimal anders verhielt. Diese Abweichung war vom Hersteller abgesegnet, weil sie noch innerhalb der Spezifikationen lag, und normalerweise hätte kein Kunde den Unterschied bemerkt, weil (fast) niemand gleichzeitig mehrere GraKa desselben Typs kauft.

    Ein weiteres, sehr prominentes Beispiel sind die Onboard-Sound-Karten vom Typ "Intel-HDA": der eine braucht diesen Parameter beim Laden des Moduls, der andere einen anderen Parameter. Falls jemand von den Treiber-Programmierern für Linux hier mitliest, der weiß, wovon ich rede. :rolleyes:

    Könnte es vielleicht so etwas sein? Ich kann mir vorstellen, daß der Netzwerk-Chip vielleicht nicht immer exakt derselbe ist. Vielleicht sollten wir in dieser Richtung mal nachforschen.

    Selbst passive Bauteile wie Kondensatoren können ein unterschiedliches Verhalten auslösen, wenn sie nicht 100% gleich sind.

    Einmal editiert, zuletzt von PInguin (8. April 2014 um 15:12)

  • Also erstens würde mich wirklich mal interessieren, warum sich so schrecklich wenig Leute in diesem Thema mitreden, wo doch andererseits dieser Fehler weit verbreitet zu sein scheint.

    Zweitens ist mir gerade dieses aufgefallen:

    Code
    root@raspberrypi:~# mii-tool -v eth0
    eth0: negotiated 1000baseT-HD flow-control, link ok
      product info: vendor 00:01:f0, model 12 rev 3
      basic mode:   autonegotiation enabled
      basic status: autonegotiation complete, link ok
      capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
      advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
      link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

    Das seltsame daran ist, daß meine Fritzbox nur 100MB hergibt, ich habe den "Power-Modus" mit 1GBit extra manuell deaktiviert, weil ich kein einziges Gerät habe, daß (außer dem Pi?) 1GBit schafft. Außerdem ist meine Leitung nach draußen (DSL) noch nicht einmal 100MBit schnell.

    Trotzdem behauptet mein Pi, er habe 1GBit ausgehandelt. Wie kann das denn sein?

    Einmal editiert, zuletzt von PInguin (12. April 2014 um 19:17)

  • Sieht bei mir genauso aus, obwohl der Pi auch nur an einem 100Mbit-Switch hängt. Der Netzwerkchip kann auch garkein Gbit, maximal 100Mbit Vollduplex. Scheint ein Fehler in der Anzeige von mii-tool zu sein, bei ethtool wird es richtig angezeigt:


    Wie kommst du darauf dass genau dieser Fehler weit verbreitet ist? Ich sehe das hier zum ersten Mal.

    Sollte es wirklich an der Auslastung liegen, kannst du das vielleicht mit einem solchen Tool simulieren:
    http://www.protocog.com/trgen.html
    Weiß aber nicht welcher da was taugt bzw. vielleicht auch in den Repos ist.


  • Also erstens würde mich wirklich mal interessieren, warum sich so schrecklich wenig Leute in diesem Thema mitreden, wo doch andererseits dieser Fehler weit verbreitet zu sein scheint.

    Das Thema Pi Fehlverhalten wg schlechter Stromversorgung ist hier schon zu Hauf diskutiert worden.

    Zitat

    ... weil ich kein einziges Gerät habe, daß (außer dem Pi?) 1GBit schafft.

    Die Pi kann nur 100Mb

    Zitat

    Trotzdem behauptet mein Pi, er habe 1GBit ausgehandelt. Wie kann das denn sein?


    So sieht meine Ausgabe von ethtool aus


  • Scheint ein Fehler in der Anzeige von mii-tool zu sein, bei ethtool wird es richtig angezeigt:


    Ja, sieht so aus.

    Zitat

    Wie kommst du darauf dass genau dieser Fehler weit verbreitet ist? Ich sehe das hier zum ersten Mal.


    Naja, in der Erklärung zur Rasbian-Minimal-Distri steht, daß ein Fehler behoben wurde, der den Pi bei hoher Netzlast lahmlegt. Also scheint es ja schon bei den Entwicklern der Distri angekommen zu sein.

    Zitat

    Sollte es wirklich an der Auslastung liegen, kannst du das vielleicht mit einem solchen Tool simulieren:
    http://www.protocog.com/trgen.html
    Weiß aber nicht welcher da was taugt bzw. vielleicht auch in den Repos ist.


    Danke, werde ich mal ausprobieren.

  • Das Thema Pi Fehlverhalten wg schlechter Stromversorgung ist hier schon zu Hauf diskutiert worden.

    Ja, aber m.E. (PInguin ist offenbar der gleichen Meinung) wird das Thema (Stromversorgung) zwar häufig diskutiert aber nur an den Symptomen rumgedoktert, das geht dann über den Ersatz des eingebauten Linearreglers für die 3,3V durch einen Schaltregler (an sich keine schlechte Idee bzgl. der Energiebilanz (!), aber nicht wirklich zielführend bzgl. Stabilität) bis hin zum Einsatz von Netzteilen der 3A Klasse, was ja doch am Thema vorbei geht... :wallbash:

    Ich war auch etwas erstaunt, dass sich keiner der Leser hier (und vor allem keiner der Experten) zu den Oszillogrammaufnahmen von mir geäußert hat. Entweder hat das keiner weiter gesehen oder die Ratlosigkeit der versammelten Community schlägt uns hier beinhart ins Gesicht. :s

    Und:
    Offenbar ist es "Mode", sein Problem erstmal als Frage in das Forum zu kippen als zuvor mal zu suchen, ob das Thema nicht schon mal behandelt wurde (manchmal kam das gleiche Problem innerhalb von 2 Tagen "neu" rein) :mad_GREEN:

Jetzt mitmachen!

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