Jump to content

RED hat permanent hohe CPU Last


Recommended Posts

Hallo,

 

ich verwende den Redbrick in einem kleinen Stapel mit 2 MasterBricks und 8 Bricklets.

Da das mein erster RED Brick ist habe ich eine Frage:

Ist es normal, dass der brickd Prozess zusammen mit einem kworker permanent 50% der CPU verbrauchen?

Es greift kein Programm auf den brickd zu, also quasi im Leerlauf.

 

Ich verwende das aktuelle Image 1.10.

 

Zweite Merkwürdigkeit, vielleicht hat es damit zu tun...

Beim Start findet der Brickd die Slaves nicht. Erst wenn ich den brickd mehrfach neu starte werden irgendwann die Platinen im Stack erkannt.

Das SPI Poll Delay ist auf 50ms (war die Voreinstellung).

 

Liebe Grüße,

    Tinkerer

 

Link to comment
Share on other sites

Du solltest den brickd eigentlich nie neustarten müssen, da ist irgendetwas faul. Funktioniert es wenn du nur einen Master Brick verwendest (oder den anderen)? Funktioniert es ohne die Bricklets?

 

Also die Frage ist: Was ist der kleinste Aufbau mit dem du das Problem noch erzeugen kannst?

Link to comment
Share on other sites

Hallo,

 

ok, habe den Stack auseinander gerupft und nach und nach die Bricks und Bricklets hinzugefügt. Nach gefühlten 20 RED Brick Boots habe ich folgendes Bild:

 

Das Problem scheint aufzutreten sobald der NFC Bricklet angeschlossen ist.

 

Ich habe meine Startkonfiguration als Abbildung angefügt.

Der erste Brick mit allen Bricklets war kein Problem.

Der zweite Brick ohne, mit Rotary, mit Ambient, mit OLED.. kein Problem.

Erst als ich den NFC Bricklet angeschlossen habe, hatte ich reproduzierbar das alte Verhalten. Der brickd meldet sich, findet aber alle angeschlossenen Bricks und Bricklets nicht - es wird nur der RED Brick im Brickv angezeigt.

 

Ich habe dann nur den NFC Bricklet an den zweiten Brick angeschlossen. Und habe das gleiche (fehlerhafte) Verhalten.

 

Ich lasse den NFC Bricklet erst Mal weg...

 

Liebe Grüße,

  Tinkerer

TF_StackConfig.png.1b48565201a5311b6be4322a54cfe84c.png

TF_StackConfig.png.005ba98bc36c7cda464ba8d19a6d4859.png

Link to comment
Share on other sites

Wenn ich auch mal darf.

Arbeite gerade an einem Steuerungsprojekt.

Wollte da das 10 IMG nehmen. Hab aber auch feststellen müssen das da irgend etwas nicht in Ordnung ist. Hab heute Früh mal zwischen einem blankem 10er und 9er Image verglichen. Siehe Bilder. Das 10 hat eine sehr hohe CPU Last. Selbst im Leerlauf.

Die Screens habe ich bei genau der gleichen Hadware gemacht.

Alle Bricks haben die aktuelle Firmware.

Das 10er läuft beim Start bei 100% und pegelt sich bei ~70% ein. Es ist das blanke Image. Auf dem RED steck eine Ethernet Extension mit zugewiesener IP und ist online.

9_Image_CPU_Last.thumb.jpg.e1c9621e859b33f77d81fd0342520d4b.jpg

10_Image_CPU_Last.thumb.jpg.6f46dd59df50c334f4026ef6f2dfb6b5.jpg

10_Image_CPU_Last2.thumb.jpg.08e7fbaaad23d70e0442d9f2abd63a24.jpg

Link to comment
Share on other sites

Bezüglich der CPU Last: Wir haben das gerade nochmal diskutiert und uns die Tests angeguckt die wir gemacht haben etc.

 

Wir sehen da zwei Dinge:

 

1. Der RED Brick mit 1.10 Image nutzt jetzt den Linux CPU frequency scaling governor. D.h. per Default wird die Frequenz runtergetaktet und nur erhöht bei hoher Last. Dadurch zieht der RED Brick weniger Strom und bleibt kälter. Allerdings sieht die CPU Last dadurch höher aus (höhere Auslastung bei niedrigerer Frequenz).

 

2. Wir haben mit 1.10 auf den aktuellen neuesten Linux Mainline Kernel gewechselt. Für unsere Anwendungszwecke ist der SPI Treiber dort leider erheblich ineffizienter geworden. Das liegt soweit wir das verstehen hauptsächlich daran das die Treiber in der Zwischenzeit mehr auf Multiprozessor-Systeme ausgelegt sind, welches wir bei dem RED Brick leider nicht haben. Wir haben dort schon angesetzt und das für unseren Use Case verbessert. Hier sind die ganzen Änderungen die wir im Linux SPI Treiber gemacht haben: https://github.com/Tinkerforge/red-brick-linux/commit/2082ee9458d1bd553fb2c1b933162b3beabc8332

 

Nichtsdestotrotz, wenn wir das 1.9er Image mit dem 1.10er Image per Stress-Test vergleichen können wir sehen dass das 1.9er Image in der Tat immernoch performanter ist. Wir arbeiten aber noch daran, man kann mit bei sowas leider sehr viel Zeit versenken :).

Link to comment
Share on other sites

  • 2 weeks later...

Hallo,

 

ok, der Grund für die CPU Last ist dann klar. Danke sehr!

 

Und ich habe ein NFC Bricklet in der Version 1.1, wenn ich die Aufschrift richtig interpretiere  :D

Also auch da: Grund gefunden.

 

Vielen Dank nochmals. Ich bin gespannt auf die verbesserten SPI Treiber. Ansonsten läuft jetzt alles wie es soll.

 

Liebe Grüße,

  Tinkerer

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...