On my hardware platform, even with real-time kernel patches, the latency is still very high.
However, after using ‘sudo jetson_clocks’, the latency performance decreased from 400 microseconds to 200 microseconds. Although this delay performance is still problematic
FYI, those CONFIG_... items are just features your kernel was compiled without. Any time you are referring to a file in “/proc” or “/sys” (and most of the time in “/dev”) those are not real files and are actually kernel drivers/features pretending to be a file. If the feature does not exist in the kernel, then the file won’t exist. The configurations shown as “not set” are things you would have to customize if you want them. Some features are mutually exclusive, e.g., you can’t simultaneously poll at 100 Hz and 1000 Hz. Whatever rate you want to pick would need to be enabled in the kernel config.
The RT kernel is not a magic bullet for responsiveness, but it does offer more methods of working with process scheduling. The jetson_clocks is not about scheduling so much as it is for increasing or decreasing clock speeds (increase for lower latency and higher power consumption and higher heat output). jetson_clocks is just a human readable script (find the location of jetson_clocks, cd there, and “less jetson_clocks” to see it). You will find that it echoes strings or numbers to files in “/sys”. If those files exist, then a kernel feature capable of using them has been configured. The changes from changing a clock will speed up or slow down responses, but when you do something similar with an RT kernel feature, then you are changing priorities of competing processes. The clock won’t change from this latter, but the latency of one process can be decreased (to some extent) while the latency of a lower priority process will go up.
Note that part of the clock speed limits are based on heat generation. There are safeties in place which kernel features can’t override. In simpler cases one reduces clocks just to consume less power and/or produce less heat. Once you’ve reached the maximum clocks you can’t go higher.
You can increase clocks to max without the RT kernel. The RT kernel becomes useful when the kernel is trying to be too “fair” (or “nice”) to processes you don’t consider high enough priority to rob time from what you want to run faster.
Take a look at the actual “jetson_clocks” file. It can tell you a lot about what it does.