PREEMPT_RT kernel option

[gregtap]

👋🏻 Hello Led lovers,

I did not see any conversation about tunning Kernel for better performance i.e increased refresh rate or less flicker interruption.

Is there some proven benefits around PREEMPT_RT kernel flag?

[hzeller]

There might. I've tried it a couple of years back, but the result was inconclusive with various versions of the Raspberry Pi. It was a pain to compile the kernel back then so given the results I didn't bother to explore further.

Having said that, that was at least 6-7 years ago, so if someone wants to work on newer experiments, that would be great.

[marcmerlin]

@gregtap doesn't dietpi have a RT kernel available as a pre-built kernel option, now?

[kjkent]

@marcmerlin From some cursory googling, it doesn't seem so, though it looks like ~ 2017 they experimented with offering it via the .txt config files: https://dietpi.com/forum/t/rpi-3-v157-rt-kernel-not-updated/1592/2.

For tweaks for rt-sensitive workloads, this is a 5-year-old post (https://dietpi.com/forum/t/dietpi-for-real-time-application/4373) but DietPi project lead Michaelng details scheduler changes that may benefit, as well as adjusting process niceness...

Little article about what is possible: https://www.redhat.com/sysadmin/real-time-kernel

However, lets see what we can do. Nice -20 is already good. But the CPU scheduling policy for the process is probably not optimal: https://manpages.debian.org/stretch/manpages/sched.7.en.html
For real-time processes switch to FIFO (first in-first out) or RR (round-robin). If you run it as systemd service, dietpi-services can change it on service-level. To be true right now I don’t know the command to switch this outside systemd, but should be not difficult to find. The CPU priority can then be set as kinda replacement for nice.

Does your process as well read and/or write to disk? In this case, the same as for CPU scheduler applies for I/O scheduler: https://manpages.debian.org/stretch/util-linux/ionice.1.en.html
Ah, its the ionice command. Use realtime for scheduling class and the I/O scheduling priority, although AFAIK that is raised automatically together with nice.

...Perhaps there are even better options now.

Lastly, there's https://github.com/remusmp/rpi-rt-kernel -- it builds a Raspbian Lite image with a recent kernel with RT patches applied. The build process is painless and uses Docker. For lower-spec devices it also offers 32 bit images -- as per these benchmarks (https://www.sevarg.net/2021/12/18/raspberry-pi-32-bit-vs-64-bit/), 32 bit can offer a modest performance boost over x64 for low-RAM devices. I'm using a RPi Zero 2 W, so worth a shot.

I'll pit the current DietPi I have flashed against this 32bit RT, using the cyclictest benchmark (mentioned on the rpi-rt-kernel repo) while running the D0 demo, and report back with my findings!

[kjkent]

So I reflashed a Pi Zero 2 with Diet-Pi with RT kernel. I haven't had chance to do a full quantitative comparison yet, but, qualitatively, I didn't see a difference in terms of visual quality (stuttering when the refresh rate neared the max the Pi could handle) or the refresh rate itself.

It's entirely possible I'm not looking at the right metrics to judge improvement, in which case I'm happy to be informed! It could also be due to the limited resources on the Pi Zero 2 being the bottleneck, rather than the kernel.

[marcmerlin]

Thanks @kjkent , even if it's not great news, a negative result is still a result.
But for your other comment, I would indeed not use anything less than an rPi3a, especially if you are using more than one output channel (I use all 3 on most of my projects).
I also have 2 bigger displays and calculating enough pixels for that framebuffer cache, seems to overflow a processor cache on rPi3 and causes visible hangs for 1 sec or more of my code updating the FB (while the display is still updating). That problem went away by upgrading to a Pi4, which has a bigger cache.

[marcmerlin]

@kjkent are you able to test again on a Pi3, or better, a Pi4?

[kjkent]

@marcmerlin I have a Pi4 that's been freed up to test with; when I get around to doing so (just redoing some wiring and all the fun that comes with that), I'll be sure to test and will report back :)

[marcmerlin]

I'm going to manually save this bug from the mass closing I'm about to do, but please send an update if you have one, or we'll close it as unresolved.

[marcmerlin]

Assigning to @kjkent for update request. I'd indeed love to hear more of PREMPT is somehow helping but if we don't have anything definitive, I'll resolve this.