Jump to content

Raspberry Zero W: Hohe CPU-Auslatung durch brickd service ( mit HAT zero Brick)


Recommended Posts

Hallo Allerseits,

 

ích haben im Forum schon gesehen, dass jemand ein ähnliches Problem hatte. Ich habe folgendes Problem mit dem HAT Zero Brick und brickd:

 

Vorgehensweise bei der Installation:

Wie nach der Beschreibung auf der Hompage. Keine Probleme dabei

PROBLEM 1: brickd startet nich bei Neustart des Raspis.

 

Manueller Start und CPU-Auslastung:

 

Dann habe ich manuel den Service gestartet:

 

sudo systemctl start brickd

 

Das sieht dann wie folgt aus:

 

Services_Status.PNG

 

Mir scheint so, dass der service zweimal gestartet wird.

 

Wenn ich mir das mit htop anschaue, scheint es auch so zu sein.  Der Service taucht zweimal mit einer hohen CPU-Auslatungs auf. Hier ein Bild:

 

htop_cpu.PNG

 

Das Problem ist, dass das Raspi Zero schon vollständig ausgelastet ist.

 

Hat jemand eine Idee, wie ich das gelöst bekomme, sodass die Auslastung geringer und der Autostart aktiv ist.

 

Vielen Dank und beste Grüße,

Hendrixon

 

 

Services_Status.PNG.5d98724732a4988ebde302b9e0b9492b.PNG

htop_cpu.PNG.7c52c30b041e48ba849e8babae4f6895.PNG

Link zu diesem Kommentar
Share on other sites

Wir haben das gerade nochmal getestet, bei uns startet der brickd automatisch wenn wir es nach Anleitung machen. Sehr komisch.

 

Falls das irgendwie nicht funktioniert hat kannst du den Autostart auf jeden Fall mit

sudo systemctl enable brickd

aktivieren.

 

Ich glaube der Service taucht da auch nicht zweimal auf, du siehst da  nur zwei Threads.

 

Ansonsten hat der RPi Zero halt nur einen Kern mit 1GHz, da kann der brickd schon schnell viel CPU ziehen.

 

Welche Bricklets hast du denn angeschlossen und was machst du mit diesen/hast du mit diesen vor?

Link zu diesem Kommentar
Share on other sites

Hallo Borg,

 

vielen Dank für deinen Tipp. Ich habe es nun hinbekommen, dass brickd sich von selbst aktiviert.

 

Zu meinem Vorhaben:

 

Eigentlich wollte ich kleinere Python Programme/Packages darauf lauf lassen, d.h.

 

- u.a. wissenschaftliche Berechnungen (numpy,scipy, etc.).

 

- MQQT (Clients und evtl. Broker)

 

- kl. Webserver

 

 

Ich denke, dass ich Abstriche machen muss....

 

Meinst du, dass MQQT und ein kl. Webserver stabil darauf laufen kann?

 

Ich wundere mich nur, dass es einen Zero HAT gibt, bei dessen Verwendung jedoch nahezu 100% CPU ausgenutzt ist.

 

Oder ist es ganz normal, dass erstmal von brickd 100% belegt und je nach Bedarf von anderen Anwendungen entsprechend CPU freigegeben wird.

 

** kl. Anmerkung: Ich bin kein IT-Spezi, also ich bitte inhaltliche Fehler zu entschuldigen.

 

Grüße

Hendrixon

Link zu diesem Kommentar
Share on other sites

Steht irgendetwas in der /var/log/brickd.log?

 

Zum Thema CPU-Auslastung: Kann es sein dass der brickd gerade so wenig CPU zieht das der RPi sich heruntertaktet und dann eine relativ hohe Auslastung anzeigt?

 

Um das zu testen kannst du einmal probeweise den Linux Governor auf "performance" stellen: https://www.tinkerforge.com/de/doc/Hardware/Bricks/HAT_Brick.html#konfiguration-fur-verbesserten-durchsatz

Link zu diesem Kommentar
Share on other sites

log file steht bisher nichts besonders, ich werde es weiter beobachten, momentan läuft es wieder :D

 

Hinsichtlich der CPU-Auslastung: Ich habe den Linux Governor auf "performance" gestellt, wie auf dem Link bschrieben.

 

Leider keinen Unterschied bei der Auslastung, wenn ich mit htop nachschaue, hat sich leider nichts geändert,

Link zu diesem Kommentar
Share on other sites

Hallo Hendrixon,

 

das Problem mit dem "nicht startenden" Brickd hatte ich auch (Raspi Zero mit Zero HAT). Wenn ich mich per SSH auf den Raspi verbunden und nachgeschaut habe, wurde der Brickd als gestartet angezeigt, war jedoch nicht erreichbar.

 

Nach einer ganzen Weile Herumprobieren und leichter Verzweiflung kam ich auf die Idee, dass beim Starten des Daemons vielleicht die Netzwerkverbindung mittels WLAN beim Raspi Zero noch nicht verfügbar ist und deshalb das Binding scheitert.

 

Gelöst habe ich es dann ganz einfach, indem ich wie folgt eine Zeitverzögerung für den Startvorgang von Brickd eingefügt habe:

 

Initfile für den Brickd Daemon öffnen

sudo nano /etc/systemd/system/multi-user.target.wants/brickd.service

 

Dort unter [service] einen Delay einfügen (ich habe 15 Sekunden gewählt, vermutlich genügt auch weniger)

ExecStartPre=/bin/sleep 15

 

Die ganze Datei sieht damit so aus

[unit]
Description=Brick Daemon


[service]
User=root
Type=forking
ExecStartPre=/bin/sleep 15
ExecStart=/usr/bin/brickd --daemon

[install]
WantedBy=multi-user.target

 

Dies hat das Problem bei mir gelöst, der Brickd Daemon ist seither zuverlässig nach einem Reboot verfügbar.

 

@borg: Kannst du das bestätigen und ggfs. mit in die Doku aufnehmen ("falls Brickd nach einem Neustart beim Raspi Zero nicht verfügbar ist, fügt einen Delay ein")? Ich bin in Linux relativer N00b und musste mir vieles zusammensuchen bis ich das hatte, vielleicht geht das anderen ähnlich.

Link zu diesem Kommentar
Share on other sites

Teste mal bitte diese brickd.service Datei:

 

[unit]
Description=Brick Daemon
After=network.target

[service]
Type=forking
ExecStart=/usr/bin/brickd --daemon

[install]
WantedBy=multi-user.target

 

Es könnte sein, dass systemd brickd startet bevor das Netzwerksubsystem läuft. Dann kann brickd keinen Socket öffnen und beendet sich wieder.

 

Neu in dieser brickd.service Datei ist die After=network.target Zeile.

 

Zeig auch mal bitte die /var/log/brickd.log Datei vor. Ich erwarte, dass brickd sagt, dass kein Socket gebunden werden kann und sich dann wieder beendet.

Link zu diesem Kommentar
Share on other sites

Dieser Eintrag erscheint im brickd.log, wenn ich den 15-sekündigen Delay entferne:

2019-07-31 21:50:12.141120 <I> <main_linux.c:334> Brick Daemon 2.4.0 started (pid: 239, daemonized: 1)
2019-07-31 21:50:12.250777 <E> <bricklet_stack.c:702> Could not open /dev/spidev0.0: : ENOENT (2)
2019-07-31 21:50:12.293936 <I> <main_linux.c:538> Brick Daemon 2.4.0 stopped

 

Mit deiner zusätzlichen Zeile "After=network.target" funktioniert es ebenfalls problemlos (habe allerdings nur kurz getestet), vielen Dank!

 

Link zu diesem Kommentar
Share on other sites

Okay, systemd startet brickd also noch bevor die /dev/ Einträge angelegt sind. Ein Service kann Abhängigkeiten auf /dev/ Einträge haben. Das würde die allgemeine brickd ARM Installation aber spezifisch für's Raspberry Pi machen.

 

Ich habe jetzt erstmal für die nächste brickd Version das After=network.target eingefügt. Das hat eh gefehlt und abhängig von dem /dev/ Problem. Und wenn das auch das /dev/ Problem behebt, um so besser.

Link zu diesem Kommentar
Share on other sites

Hallo,

 

vielen Dank für Eure Beiträge. Sorry wegen der späten Rückmeldung. Zu den Themen:

 

@photron: neue Version brickd

Bedeutet deine Antwort, dass ich brickd nur updaten muss, dann ist das Problem gelöst? Oder muss ich die Zeile noch manuell einfügen.

 

@alle: CPU-Auslastung

Könntet ihr bitte mal schauen, welchen Auslastung ihr auf eurem Raspi zero beim Ausführen von brickd habt? Es würde mich einfach mal interessieren.

 

Besten Dank.

 

Grüße

Hendrixon

 

Link zu diesem Kommentar
Share on other sites

@photron: neue Version brickd

Bedeutet deine Antwort, dass ich brickd nur updaten muss, dann ist das Problem gelöst? Oder muss ich die Zeile noch manuell einfügen.

 

In brickd 2.4.1 wird "After=network.target" enthalten sein. Version 2.4.1 ist aber noch nicht veröffentlicht und aktuell kann ich dir auch noch keinen Termin dafür nennen. Sprich, bei 2.4.0 musst du die Zeile händisch hinzufügen. Ab 2.4.1 dann nicht mehr.

Link zu diesem Kommentar
Share on other sites

Ich bin jetzt dazu gekommen mir das einmal mit dem Profiler anzuschauen. Einen kleinen Flaschenhals hab ich bei den SPI Chip Selects gefunden, die konnten ohne großen Aufwand effizienter gemacht werden. Das hat sowas wie ~15% eingespart.

 

Zusätzlich hab ich eine "sleep_between_read"-Option pro Bricklet in die /etc/brickd.conf hinzugefügt. Damit kann jetzt eingestellt werden wie lange der Brick Daemon mindestens warten soll zwischen zwei "Reads" von einem Bricklet. Der Wert ist in us und war damals per Default 200us.

 

Die Default-Konfiguration sieht mit der neuen brickd Version jetzt so aus:

 

bricklet.portA.sleep_between_reads = 200
bricklet.portB.sleep_between_reads = 200
bricklet.portC.sleep_between_reads = 200
bricklet.portD.sleep_between_reads = 200
bricklet.portHAT.sleep_between_reads = 2000

 

Die Default-Einstellung vom HAT selbst hab ich von 200us auf 2ms erhöht, da das HAT selbst sowieso nie große Datenmengen übertragen muss.

 

Wenn am Bricklet nichts angeschlossen ist was große Datenmengen überträgt kann aber auch z.B. alles auf 5ms gesetzt werden und es funktioniert immernoch gut:

 

bricklet.portA.sleep_between_reads = 5000
bricklet.portB.sleep_between_reads = 5000
bricklet.portC.sleep_between_reads = 5000
bricklet.portD.sleep_between_reads = 5000
bricklet.portHAT.sleep_between_reads = 5000

 

Meine Ergebnisse nach den Änderungen:

 

HAT mit Defaultkonfiguration, keine Bricklets angeschlossen:

PsmciqA.png

 

HAT mit Defaultkonfiguration, Thermal Imaging Bricklet an port B streamt mit vollem Durchsatz Bild über WIFI:

prGEgGw.png

 

HAT mit 5ms-Konfiguration, Rotary Encoder an Port B:

CIb2CPd.png

 

Anbei die Beta-Version des neuen Brickd mit den Änderungen.

brickd-2.4.1-beta1_armhf.deb

Link zu diesem Kommentar
Share on other sites

  • 1 month later...
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...