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

[Hendrixon]

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:

 

 

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:

 

 

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

 

 

[borg]

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?

[Hendrixon]

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

[Hendrixon]

kleiner Nachtrag: Das mit dem Autostart von brickd wahr ein Schnellschuss. Es hat zwar einmal funktioniert, aber ich habe nun zu Testzwecken das raspi nochmals zweimal neugestartet, dabei ist jedoch brickd wieder inaktive geblieben. Siehe Bild

 

[borg]

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

[Hendrixon]

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

 

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,

[borg]

Ich hab es mir auf die TODO-Liste geschrieben da nochmal mit einem Profiler zu schauen wo die CPU-Zeit verloren geht. Eventuell können wir da ein einstellbares Abfrageintervall o.ä. machen für Anwendungen wo kein hoher Durchsatz benötigt wird.

[Gast hotelbravo]

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.

[photron]

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.

[Gast hotelbravo]

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!

 

[photron]

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.

[Hendrixon]

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

 

[photron]

@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.

[borg]

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:

 

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

 

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

 

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

brickd-2.4.1-beta1_armhf.deb

[theo]

Sieht sehr viel besser aus! Von 40 auf 6.x % CPU ohne Bricklet.

 

[photron]

Brick Daemon 2.4.1 mit den Änderungen fürs HAT ist jetzt veröffentlicht.

[Hendrixon]

Hallo,

 

vielen Dank für die Antworten und sorry, wegen meiner sehr verspäteten Rückmeldung. Mit der neuen Brick Daemon 2.4.1 Version sollten meine Probleme (haupstächlich die service Sache) geklöst sein.

 

Danke und Grüße,

Hendrixon