Real-Time Kernel Package

My apologies if this may be a very basic question, I am new to real-time programming and looking to get started on a Jetson. In the developer guide for R35.1, I see that under Kernal Customization there are two subsections relating to real-time kernels, these being “To Build the Real-Time Kernel” and “Using the Jetson Linux Real-Time Kernel Package”. From what I understand, the former applies the PREEMPT_RT patch to the Jetson Linux kernel, but I am not sure what the latter does.

I would greatly appreciate if someone could explain the difference, and which set of instructions I should follow.

Using the Jetson Linux Real-Time Kernel Package is not supported on Jetpack 5.0.2(r35.1). We will remove it. Sorry for any confusion.

Please apply RT kernel patch and manually build kernel image.

1 Like

Thank you for clearing this up! What exactly does the real-time kernel package do compared to the kernel patch. Does it just do what the patch does without needing to rebuild the kernel image? Are there any performance differences between the two?

Also, do you know if the RT kernel package will be available on Jetpack 5.0.2 in the future?

It is a prebuilt kernel image, same as built from default kernel source + RT patch. On Jetpack 5, we don’t offer prebuilt image since these are open source and anyone can build it from source code.

1 Like

Something to note about an RT kernel, and how it differs from the “stock” kernel, is how the scheduler can be customized. In any kernel one has a scheduler to prioritize which hardware or software interrupt will run when there are more interrupts than CPU cores available. A default kernel might schedule for average throughput, e.g., to take advantage of cache hits might mean putting off running another process even though it has waited. The concept of hard realtime is that the prioritized thread or process must always be able to run exactly with its defined time. Should this higher priority process be able to execute within some defined time, then it will wait for another thread/process to finish before running. However, if the lower priority process would stop the higher priority from running within some defined time, then no matter what, this other process would be preempted and the higher priority would run.

In a true hard realtime system there won’t be cache. Average throughput from cache tends to be thrown out since although cache hits can improve speed, a miss causes harm to the timing of execution no longer being predictable. On a system where you have cache (including any PC architecture, or ARMv8-a, a Cortex-A series, of the Orin) this cannot be guaranteed, and so a scheduling algorithm for attempting realtime becomes “soft realtime”. There is actually more than one level of hard realtime, e.g., guarantees of a shadow core taking over in case of a hardware failure (think of a fighter jet’s control system or a spacecraft…it isn’t good enough at mach 1.2 to throw out the aircraft and pilot because an inexpensive part failed).

The most basic hard realtime for ARM would be the Cortex-M series. This has no hardware backup though, and isn’t necessarily hard realtime unless software is set up correctly. The ARM Cortex-R series is capable of true hard realtime. A Cortex-R has hardware-based aids in scheduling which the Cortex-M does not. Scheduling difficulty goes up exponentially with number of processes being managed, and probably four processes or fewer could be managed easily with a Cortex-M. As the environment becomes more complex, one needs the Cortex-R to avoid the scheduler itself becoming a liability to performance (predictability). Cortex-R, when multicore, also has the ability to choose either shadow cores which will automatically take over without the software ever knowing about the failure via hardware, or else simply choosing to use each core and not using shadow cores.

Very very few consumer or average computers have hard realtime capability. The CPU cores you know about on Jetsons are also only capable of soft realtime (if the software is patched for it). An exception is that the Image Signal Processor (ISP) and Audio Processing Engine (APE) have a low powered Cortex-R processor to deal with audio and video to some extent where hard realtime is needed. There are cases where people will custom program the APE to take advantage of this (at the cost of lost audio).

Once the RT kernel runs on a Jetson it won’t necessarily be some “automatic it just improves” thing. What RT scheduling does is to allow processes to be classified, and have priorities set for various classes. If you’ve not set up a priority, then you won’t necessarily see any benefit of this. Even if you do set this up, it can still fail to operate priorities in a required time due to cache hit/miss latencies. This is a software algorithm which can only operate within the hardware capabilities.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.