Re: ONE_SHOT_MODE vs. PERIODIC_MODE

On Friday 08 April 2005 17:12, Vandenbroucke Sander wrote:
> Hello,
>
> I kinda remimber asking a question like this before...
>
> Anyway:
> What is the benefit of using the rtai timer in one shot mode and not in
> periodic mode?

Flexibility. In periodic mode, in order to get reasonable jitter/latencies, 
all threads must be 1) started at a time which is a multiple of the PIC 
(Programmable INterrupt Controller) period and 2) be a multiple of the timer 
period. Thus it needs carefull programming of start times and periods of your 
thread. In oneshot, the next runnable thread wakeup time is programmed into 
the PIC, and then the current thread is run. The reprogramming can take 1000 
to 2000 clock cycles, which is thus overhead, but you buy flexibility for it.

With well crafted threads, periodic mode might be not that bad. The Orocos 
PeriodicThread does not take a 'start time' argument yet ( in start() ), but 
this may easily be added in the current implementation. Also, the hardcoded
oneshot mode might then be made configurable (even at startup-time).

>
> Something else:
> I've extended the interface of the TimerService class with a getNSecs() and
> getNSecs(nsecs relativeTime) function. It does the same as getTicks() but
> returns nsecs instead of ticks using the rt_get_cpu_time_ns() call. This
> gives the time in ns regardless of the type of timer mode that is used. I
> could send a patch, but it will have to wait until monday.

You could also have used TimeService::ticks2nano( ts->getTicks() ), but a 
native getNSecs() is indeed more efficient, avoiding a syscall, so I'll 
possitively accept it ! :-)

Peter