[Xenomai-help] accuracy of system clock

[Xenomai-help] accuracy of system clock

[Theo Veenker]

Hi all,

I'm using clock_gettime(REALTIME,&t) in a kernel module (posix skin) to
timestamp something. I know accessing this clock from user space yields
values different from those returned by the xenomai posix skin due to
ntpdate. But my concern is that the difference in pace is too much.
On one system it is about 90us/s wrong on another it is 160us/s.

I assume the speed of the ntp corrected clock is more or less correct.
Is there some calibration procedure I can run to tweak xenomai to make
sure in xenomai I get 1e9 ticks per *true* second?
I have enabled CONFIG_X86_UP_APIC.

Theo

Re: [Xenomai-help] accuracy of system clock

[Gilles Chanteperdrix]

On Nov 19, 2007 10:29 AM, Theo Veenker <Theo.Veenker@domain.hid> wrote:
> Hi all,
>
> I'm using clock_gettime(REALTIME,&t) in a kernel module (posix skin) to
> timestamp something. I know accessing this clock from user space yields
> values different from those returned by the xenomai posix skin due to
> ntpdate.

Well, you can use the posix skin in user-space as well.

> But my concern is that the difference in pace is too much.
> On one system it is about 90us/s wrong on another it is 160us/s.

>
> I assume the speed of the ntp corrected clock is more or less correct.
> Is there some calibration procedure I can run to tweak xenomai to make
> sure in xenomai I get 1e9 ticks per *true* second?
> I have enabled CONFIG_X86_UP_APIC.

There is currently no way to calibrate Xenomai, but there is a known
issue about the APIC frequency specifically. I do not know if some
quick fixes have been posted, but there is a (rather large) series of
patches fixing it.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] accuracy of system clock

[Theo Veenker]

Gilles Chanteperdrix wrote:
> On Nov 19, 2007 10:29 AM, Theo Veenker <Theo.Veenker@domain.hid> wrote:
>> Hi all,
>>
>> I'm using clock_gettime(REALTIME,&t) in a kernel module (posix skin) to
>> timestamp something. I know accessing this clock from user space yields
>> values different from those returned by the xenomai posix skin due to
>> ntpdate.
> 
> Well, you can use the posix skin in user-space as well.
> 
>> But my concern is that the difference in pace is too much.
>> On one system it is about 90us/s wrong on another it is 160us/s.
> 
>> I assume the speed of the ntp corrected clock is more or less correct.
>> Is there some calibration procedure I can run to tweak xenomai to make
>> sure in xenomai I get 1e9 ticks per *true* second?
>> I have enabled CONFIG_X86_UP_APIC.
> 
> There is currently no way to calibrate Xenomai, but there is a known
> issue about the APIC frequency specifically. I do not know if some
> quick fixes have been posted, but there is a (rather large) series of
> patches fixing it.

Can you suggest a different timing source? I thought using the APIC
was preferred over using the TSC. What do other users do if they want
1 ms to last 1 ms?

If the drift appears to be constant on each system I can problably account
for it and apply a correction. I'll try that.

Theo

Re: [Xenomai-help] accuracy of system clock

[Gilles Chanteperdrix]

Theo Veenker wrote:
 > Gilles Chanteperdrix wrote:
 > > On Nov 19, 2007 10:29 AM, Theo Veenker <Theo.Veenker@domain.hid> wrote:
 > >> Hi all,
 > >>
 > >> I'm using clock_gettime(REALTIME,&t) in a kernel module (posix skin) to
 > >> timestamp something. I know accessing this clock from user space yields
 > >> values different from those returned by the xenomai posix skin due to
 > >> ntpdate.
 > > 
 > > Well, you can use the posix skin in user-space as well.
 > > 
 > >> But my concern is that the difference in pace is too much.
 > >> On one system it is about 90us/s wrong on another it is 160us/s.
 > > 
 > >> I assume the speed of the ntp corrected clock is more or less correct.
 > >> Is there some calibration procedure I can run to tweak xenomai to make
 > >> sure in xenomai I get 1e9 ticks per *true* second?
 > >> I have enabled CONFIG_X86_UP_APIC.
 > > 
 > > There is currently no way to calibrate Xenomai, but there is a known
 > > issue about the APIC frequency specifically. I do not know if some
 > > quick fixes have been posted, but there is a (rather large) series of
 > > patches fixing it.
 > 
 > Can you suggest a different timing source? I thought using the APIC
 > was preferred over using the TSC. What do other users do if they want
 > 1 ms to last 1 ms?

The timing source used by Xenomai is the tsc, not the apic.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] accuracy of system clock

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> On Nov 19, 2007 10:29 AM, Theo Veenker <Theo.Veenker@domain.hid> wrote:
>> Hi all,
>>
>> I'm using clock_gettime(REALTIME,&t) in a kernel module (posix skin) to
>> timestamp something. I know accessing this clock from user space yields
>> values different from those returned by the xenomai posix skin due to
>> ntpdate.
> 
> Well, you can use the posix skin in user-space as well.

BTW, there is a dedicated clocktest in the testsuite to estimate drifts
of Xenomai's clocks from the Linux gettimeofday.

> 
>> But my concern is that the difference in pace is too much.
>> On one system it is about 90us/s wrong on another it is 160us/s.
> 
>> I assume the speed of the ntp corrected clock is more or less correct.
>> Is there some calibration procedure I can run to tweak xenomai to make
>> sure in xenomai I get 1e9 ticks per *true* second?
>> I have enabled CONFIG_X86_UP_APIC.
> 
> There is currently no way to calibrate Xenomai, but there is a known

True. In fact, a generic clock adjustment interface using arbitrary
external sources is on the agenda for the next major Xenomai version
(2.5?) - which will unfortunately take a while to be rolled out. But
inputs/contributions to this effort are always welcome and can
accelerate the development at least of this particular feature.

> issue about the APIC frequency specifically. I do not know if some
> quick fixes have been posted, but there is a (rather large) series of
> patches fixing it.

The APIC issue only impacts the timer, not the clock. And so far I've
seen only too early timer events, basically causing overhead due to
multiple early timer IRQs.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux