Measuring period jitters of PeriodicComponents

Hi all,

I have strong issues with my periodic components that seems to provide real
periods that are from 0 to 200% from the configured period which makes the
system unusable. FYI, the period is set to 10ms.

I'm currently measuring the time with :
clock_gettime(CLOCK_MONOTONIC, &now);
But I'm afraid this is disrupting the period. I'm using a linux Preempt-RT
patched kernel, is there any better solution to compute time ?

I know that the perfect jitter measure would be with GPIO but I'm not able
to do that. being a +/-10% (meaning between 9 and 11ms) would be ok at a
first try.

Should I use the Timer component of OCL for this kind of periods or should
the RTT::PeriodicActivity be acceptable ?

Measuring period jitters of PeriodicComponents

On Mar 31, 2014, at 13:25 , Willy Lambert <lambert [dot] willy [..] ...> wrote:

> Hi all,
>
> I have strong issues with my periodic components that seems to provide real periods that are from 0 to 200% from the configured period which makes the system unusable. FYI, the period is set to 10ms.
>
> I'm currently measuring the time with :
> clock_gettime(CLOCK_MONOTONIC, &now);
> But I'm afraid this is disrupting the period. I'm using a linux Preempt-RT patched kernel, is there any better solution to compute time ?
>
> I know that the perfect jitter measure would be with GPIO but I'm not able to do that. being a +/-10% (meaning between 9 and 11ms) would be ok at a first try.
>
> Should I use the Timer component of OCL for this kind of periods or should the RTT::PeriodicActivity be acceptable ?

The RTT activity should be fine, as should the OCL::TimerComponent. In v1 at least (no numbers from us for v2 yet, but the implementation is very similar IIRC) we make 2ms deadlines +/-5% on bog standard x86 Dell's with 2.6.31-rt kernel.

You might examine priorities, scheduling class, whether you're getting bounced off the CPU, etc.

We use clock_gettime() for our timing also - it's completely fine.

HTH
S