Performance issue on RPI3

[leoceto]

Hi

After having successfully run the program on a RPI4 without any issue except that RPI4 cannot run OpenGL in a headless mode, I have now switched to a RPI3 B+.

The problem of headless mode is now solved and everything is working without an HDMI output however I experienced some annoying flickering. I am a bit suprised as the RPI3 B+ is not that much less powerful than the RPI4 and you seem to run it successfully on a RPI2 !!!

I tried to play with runtime.gpio_slowdown, but the best parameter seems to be 4 like on the RPI4.

The only thing I did not try vs you is to reserve an entire CPU core to the task. First of all, I should reserve at least 2 as i have a quad core right ? Secondly I understand to do so we need to put isolcpus=3 in /boot/cmdline.txt but then how can we associate the task to this cpu ?

Furthermore, may I ask you what kind of option you use to run automatically the program at launch ? You put sudo /home/pi/cpu-stats-gl & in /etc/rc.local ?

Thanks !

PS : I use rasbian lite with nothing else than the program

[Staacks]

The first question is not really an issue of the cube code, but concerns the rpi-rgb-led-matrix library. Anyways, here is what I remember: Reserving a core is only for the matrix update process because its timing is crucial to avoid flickering. This is not so much about giving it enough processing power but to make sure that it can run uninterrupted without another thread messing up its timing. According to this, the library is hardcoded to use CPU 3, so you do not have to tell the library anything, but need to make sure to reserve the correct one. This also answers whether to reserve multiple cores as this thread would still only use CPU 3 (the Pi2 also has four cores BTW). In any case, if this update thread works as I suspect it does (again, this is the library part which is not my work), it is a single-thread process anyway and it will probably always hog the entire core.

About the second question: Exactly. Just before "exit 0". Simple, but effective :)

[leoceto]

Thanks so much. I tried it but it changes nothing for me, still the same proble.

Anyhow, I succeeed to make it almost work by giving the process high priority : sudo nice -n -20 ./cpu-stats-gl

and adding new parameters for the RPI3B+ :

    defaults.pwm_dither_bits = 2;
    defaults.limit_refresh_rate_hz=120;
    runtime.gpio_slowdown = 2;

defaults.pwm_dither_bits resolves quite well the problem of flickering but reduces significanlty the brightness which is a bummer. i don't understand why I can't find parameters to get something smooth like your RPI2 or my previous tests with the RPI4. Any ideas ?

[leoceto]

Last but not least, it seems to not be mono thread as if you type Top 1 H, you can see that the process is taking two threads, see below, so there might be additonal ways to optimize it I guess

[Staacks]

Sorry, it probably was not clear. The matrix-driving process is only a single thread. It of course forks from the main process, so you would see two in total, both named after the original binary but doing quite different things.

[leoceto]

ok thanks but then is it normal to get 100% on the cpu3 ? do you have the same ? On the bonnet description they say that the graphic part is more about 50 to 60% max.

[Staacks]

I definitely also have 100% on core 3. I am not entirely sure if that would be different for a smaller matrix or a much faster core...