Schedulers

Last edit: Peter Favrholdt on October 14, 2006 22:40 (1426 days, 21 hours and 7 minutes ago) (diff)
Rtai.Dk | RecentChanges | Preferences | DIAPM RTAI

(from the mailinglist archive)

On UP machines the best way to work is clearly to have both Linux and RTAI work UP. Notice however that with a kernel compiled UP you can use all the available RTAI schedulers.

If you have an SMP kernel and want to run it on a UP machine than you have to use rtai_sched_8254.

Paolo.

Q: Is there a specicfied minimum period for an rt_task service? I mean to ask, when we make a task periodic , how fast can I do it?

A: You won't get much better than 20us worst case interrupt latency with RTAI, at 50us minimum period. And then you have to be picky about the motherboard; older designs seem to be better than the current state of the art for realtime response.

Q: When I load the rtai_sched module, the CALIBRATED TIMER-INTERRUPT-TO-SCHEDULER LATENCY is reported as 2240 ns. However, the actual latency for this chip is more like 50us (as reported by latency_calibrate). 1) Why is it reported as 2240 when I load the module, and 2) Do I need to care? I'm not familiar with the repercussions this might have.

A: The "Latency" value you mentioned is used by the scheduler to determine and program the delay for the next timer interrupt:

  $ cat rtai_sched.c
  ...
  delay = (int)(rt_times.intr_time - (now = rdtsc())) - tuned.latency;

It should therefore be adjusted appropriately for your system. On X86 this is done automatically, I think, but on PowerPC it should be set via module parameter:

  $ insmod rtai_sched.o Latency=50000

Q: We have a kernel module that provides some system calls. We used the LXRT method for extending these calls to userspace apps. We have one method which has a critical region, and I would normally use a semaphore to guard it, but I'm unsure about using the rt_sem_wait inside the kernel module - I'm afraid of hanging the system. (I'm thinking that application 1 makes the call, putting the kernel module in the critical region. Application2 then makes the same call, and the kernel module tries to take the semaphore - what happens next?)

Is my fear justified? (We're on dual CPU machine)
What might the consequences be if I use rt_sched_lock() and

rt_sched_unlock() instead?

Q: When I run the latency test I get negative latencies. What do they mean?

A: (from the mailinglist archive)

Negative time is due to the fact that RTAI do some kind of calibration at startup (there is even a tool for fine tuning somewhere in rtai dir) This calibration try to minimize jitter of rt-task and usually it requires to anticipate call of rtai task to recover time delays

In some good cases the time delays are less than expected and rt-task shot before it's time

If you don't like this beavior you can just wait to real fire time with a simple "wait until fire time" as first step in the rt-task routine

Marco Tozzini