tinkerer Posted January 16, 2018 at 08:57 PM Share Posted January 16, 2018 at 08:57 PM 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 Quote Link to comment Share on other sites More sharing options...
borg Posted January 18, 2018 at 11:07 AM Share Posted January 18, 2018 at 11:07 AM 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? Quote Link to comment Share on other sites More sharing options...
tinkerer Posted January 18, 2018 at 09:00 PM Author Share Posted January 18, 2018 at 09:00 PM 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 Quote Link to comment Share on other sites More sharing options...
borg Posted January 18, 2018 at 11:50 PM Share Posted January 18, 2018 at 11:50 PM Welche Firmware Version hat das NFC/RFID Bricklet? In Version 2.0.1 gab es folgenden Fix: 2014-12-22: 2.0.1 (10b6746) - Asynchronously wait until PN532 is ready (fixes RED Brick incompatibility) Quote Link to comment Share on other sites More sharing options...
FlyingDoc Posted January 19, 2018 at 09:42 AM Share Posted January 19, 2018 at 09:42 AM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted January 19, 2018 at 10:20 AM Share Posted January 19, 2018 at 10:20 AM 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 . Quote Link to comment Share on other sites More sharing options...
tinkerer Posted January 28, 2018 at 02:22 PM Author Share Posted January 28, 2018 at 02:22 PM 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 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 Quote Link to comment Share on other sites More sharing options...
borg Posted March 9, 2018 at 12:13 PM Share Posted March 9, 2018 at 12:13 PM RED Brick Image 1.11 ist jetzt veröffentlicht und bringt die alte Performance wieder zurück (+ ein bisschen mehr ): https://www.tinkerforge.com/de/blog/red-brick-image-111-big-performance-boost/ Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.