Framerate drops 50% after random time

[mzdunek92]

I would like to reopen the issue #458, as I have tested your suggested actions.

Disabling throttling and setting nice parameter to -19 did not remove this framerate dropping effect.
Update thread is always marked as RT on htop preview.

Do you have any other suggestions? We have used this software in other projects with smaller displays (like 200-300 px width max instead of 700) and there were no such problems.

[hzeller]

Please don't open or re-open two issues for the same thing as it costs times for the volunteers who look over the issues. Here is what I wrote over there:

The longer the display chain is, the more you are susceptible to the operating system interrupting you creating changes in the time it takes to refresh a whole screen. If in a time period there are less refreshes per second, you see this as a brightness deviation.

A chain of 44 is very long. Typically you start seeing drop in framerate after about 8 or so, so 44 is definitely stretching it (ususally, you'll get a couple of hundred Hz refresh rate with 16 high panels). You are also only using 2 parallel chains. You should consider using all 3 chains as they don't cost any extra CPU to use, but now you only need about 30 panels in each chain, which would definitely help.

There are a few potential reasons why the variations happen:

• Either it is just that the kernel is interrupting the task more often even though it requests not to. There is probably not much that can be done with the generic stock kernel that is optimized for interactive user experience. In that case, I'd suggest to play with a realtime kernel. @russdx found a ready made kernel configuration in https://github.com/guysoft/RealtimePi but I haven't tried that yet. Might be worth an experiment, in particular since you have such a long chain.
• Your display is pretty big, so this means a lot of data. The display works best if the data can be kept in CPU cache, because the RAM is very slow on the Raspberry Pi. Reading data from the RAM alone would not be fast enough to send to the display, so if there is any other process that competes for the CPU cache, you will have issues. So avoid running anything else on the Pi you don't need.
  An example for processes that mess up things: someone found the reason for their brightness glitches every minute because there was a cron running updating the ntp (I guess you read the README for the details).
  Also check if there is anything running in cron: it wakes up every minute to look for things to do, so will also mess with your timing every minute.
  If you use programming languages that use garbage collection, they will have a random impact on the cache.
• It could be some other hardware limitation in the Pi: whenever there is something else using the memory bus (e.g. networking), it might slow down the GPIO.

I don't understand how you run the application from the crontab ? Are you just displaying something shortly and then exit ? I would rather suggest to have the application running all the time, only started at boot time of the Pi and build a way to trigger it showing things you'd like to show. The problem with starting and stopping is that you don't keep the cache warm, which will not work well in your situation (see above).

Finally, you can try to smooth out the framerate fluctuations by setting it to some fixed value; there is an option in a more recent version of the library, FIXED_FRAME_MICROSECONDS in lib/Makefile. It helped people that have seen slight fluctuations in brightness to get an entirely smooth output. However with this procedure you'll fix it at the lowest framerate observed, which is pretty low already because you have a very long chain and only use two parallels.

So suggestions in sequence of difficulty

• Make your application run continuously, not per cron. Start it at boot time (simplest way: put it in /etc/rc.local) Disable anything in cron or stuff that runs regularly. Avoid programming languages that do garbage collection. Preprocess all your image data if calculation takes too long. Maybe even pre-process image data, store on disk and play from there (e.g. using the Content Streamer set of APIs (see example how to use in utils/led-image-viewer.cc)).
• Smooth out irregularities with the FIXED_FRAME_MICROSECONDS setting.
• Try a realtime kernel to run on your Pi.
• Utilize all three chains. They don't cost any extra CPU, but requires to push 30% less data for the same display. This will require you to change the wiring and write some PixelMapper to map the pixels to the same physical layout, but it will be worthwhile.

[hzeller]

Let's close this one and continue on the original #458 .