Comment by snvzz

Comment by snvzz 10 months ago

>My requirement is to be able to wake up on a timer with an interval of less than 350 us and do some work with low jitter.

Cyclictest (from rt-test) is a tool to test exactly this. It will set an alarm and sleep on it. Then measure the offset between the time the alarm was set to, and the time the process gets the CPU.

With SCHED_FIFO (refer to sched(7)), the system is supposed to drop what it is doing the instant such a task becomes runnable, and not preempt it at all; CPU will only be released when the program voluntarily yields it by entering wait state.

Look at the max column; the unit is microseconds. There's a huge difference between behaviour of a standard voluntary preempt kernel and one with PREEMPT_RT enabled.

jovial_cavalier 10 months ago

I'm not claiming that there's no difference - just that with the limited tests I ran, preempt_rt is not nearly as good as xenomai.

Reply View 1 reply

snvzz 10 months ago

That is not too surprising.
Linux is still Linux, and having Linux as a whole be preemptable by a separate RTOS kernel is always going to perform better in the realtime front, relative to trusting Linux to satisfy realtime for the user tasks it runs.
Incidentally, seL4[0] can pull off that trick, and do it even better: It can support mixed criticality (MCS), where hard realtime is guaranteed by proofs despite less important tasks, such as a Linux kernel under VMM, running on the same system.
0. https://sel4.systems/About/seL4-whitepaper.pdf

Reply View | 0 replies