[Rtai] Variation using nano2count

Graeme Foot GraemeF at touchcut.com
Fri Mar 2 00:11:27 CET 2012

Hi Paolo,

I ran /usr/realtime/calibration/run (after changing the test to -c,

The result was (after 1680 seconds):
*** '#define CPU_FREQ 1000035663', IN USE 999868000 ***

I'm using Linux kernel, is this value likely to be reasonably
accurate?  (I was hoping for a value closer to 999905000, but that is
assuming my EtherCAT slaves have an accurate time base.)

The result above recommends defining CPU_FREQ, is this still valid?
Looking at the patched Linux source it looks like
RTAI_CALIBRATED_CPU_FREQ might be a better option.

If I instead wanted to make this adjustment dynamic, can I just set
"tuned.cpu_freq" directly, or should I be setting one of the Linux
values before starting up the RTAI modules?

If I wanted to implement drift compensation (where the RTAI period is
adjusted based on an external time source) what would be the best way to
go about it?  Is there an example in the showroom samples?


-----Original Message-----
From: Paolo Mantegazza [mailto:mantegazza at aero.polimi.it] 
Sent: Tuesday, 28 February 2012 21:17
To: Graeme Foot
Cc: rtai at rtai.org
Subject: Re: [Rtai] Variation using nano2count

Graeme Foot wrote:
> Hi Paolo,
> I have been having a look through the RTAI and Linux source code.
> The nano2count and time functions (eg: rt_get_cpu_time_ns) use the
> tuned.cpu_freq value in oneshot mode.
> - The tuned.cpu_freq is ultimately set using the ipipe_cpu_freq()
> - The ipipe_cpu_freq() macro is defined in
> arch/x86/include/asm/ipipe_32.h and uses cpu_khz.
> - cpu_khz is set in arch/x86/kernel/tsc.c tsc_init(), eg:
>     tsc_khz = calibrate_tsc();
>     cpu_khz = tsc_khz;
> - calibrate_tsc is defined as native_calibrate_tsc()
> - native_calibrate_tsc() calls quick_pit_calibrate()
> quick_pit_calibrate() seems to be the culprit.  Its job it to detect
> cpu frequency, but only to within 500 parts per million (2^11).  This
> can give an error of up to +-0.0488%.  Obviously this is the worst
> and it will often be better but given the values I've been getting I'm
> consistently getting +-0.015% and sometimes worse, which is too high
> my system to be stable.
> If I disable the quick_pit_calibrate() function it will fail over to
> using a slower and in theory more accurate calibration test.  With
> I'm seeing approx +0 to -0.0041% (assuming the cpu is exactly
> which is probably usable but still not desireable.
> Do you know of any other calibration methods that could be used (even
> they take longer) that are a lot more accurate?
> Of course I could just set the value manually (with a compiler define
> something) but I would probably rather not.
> Regards,
> Graeme.

Ok, I see I missed you point, which now should be clear to me too.
A finer calibration is available in RTAI, in the support program 
calibrate available in any distribution. With it we should be able to 
calibrate much more finely than Linux, provided you let it run for quite

a time. I recall that to stabilize to the last figure it took hours.
The problem is that all the present tenses above should likely be past 
tenses nowadays. In fact it is likely that the program will not work 
anymore, because of the new Linux timing that makes it difficult to grab

to 8254 timer, with its reference freq, in periodic mode for a long
So, with respect to calibrating our time base precisely, the situation 
is worse now that it was before. That is partly my fault and partly 
related to the fact that for years none has complaint about it.
Refurbishing it should not be difficult though.


> -----Original Message-----
> From: rtai-bounces at rtai.org [mailto:rtai-bounces at rtai.org] On Behalf
> Graeme Foot
> Sent: Tuesday, 28 February 2012 10:33
> To: rtai at rtai.org
> Subject: Re: [Rtai] Variation using nano2count
> Hi Paolo,
> I already have "Support for Posix CLOCK_REALTIME APIs" selected in the
> RTAI config (under: Base system / Supported services).  Is this the
> you mean?
> Just to clarify a bit (hopefully).  The time value resetting to zero
> reboot is not the problem.  The problem is that after each reboot the
> "TimeBase freq" value is different.
> Regards,
> Graeme.
> -----Original Message-----
> From: Paolo Mantegazza [mailto:mantegazza at aero.polimi.it] 
> Sent: Monday, 27 February 2012 23:27
> To: Graeme Foot
> Cc: rtai at rtai.org
> Subject: Re: [Rtai] Variation using nano2count
> Graeme Foot wrote:
>> Hi,
>> I'm using RTAI 3.8.1 with Linux
>> I have a Beckhoff CX1020 PC that I'm running with a user space hard
>> realtime thread at 1ms in oneshot mode.
>> The problem that I am having is that the nano2count call is returning
>> different values every time I reboot the system.  If I restart the
>> without rebooting the nano2count values stay the same.  Note: the
>> variation occurs on rebooting whether I cycle the power or not.
>> The application is reporting 2-3us jitter and no drift, but it is
>> communicating with an EtherCAT network and it is reporting various
>> drifts depending on the nano2count value.  eg drifts after a few
>> reboots:
>> drift vs nano2count(1000000)
>> -562	 999848
>> -452	 999860
>> -255	 999879
>> 1885	 1000093
>> -127	 999891
>> This results in quite a linear correlation.  Using a fixed value of
>> 999904 results in approximately no drift, but then the times reported
>> from rt_get_cpu_time_ns do not match.
>> The scheduler is reporting the following (from dmesg) when it is
> loaded:
>> RTAI[sched]: loaded (IMMEDIATE, UP, USER/KERNEL SPACE: <without RTAI
>> KTASKs>, <uses LINUX SYSCALLs>, kstacks pool size = 524288 bytes.
>> RTAI[sched]: hard timer type/freq = 8254-PIT/1193180(Hz); default
>> timing: periodic; linear timed lists.
>> RTAI[sched]: Linux timer freq = 1000 (Hz), TimeBase freq = 999891000
> hz.
>> RTAI[sched]: timer setup = 2010 ns, resched latency = 2689 ns.
>> The TimeBase freq value changes each time matching the nano2count
> value.
>> Nothing else seems to change.
>> What should I be looking at to figure out why this variation is
>> occurring?
> Nowhere, if I got it right what's happening to you. Any default timing

> in RTAI is related to the base CPU timing, or an emulation thereof for

> 486s, so it is resumed from zero at any reboot.
> So, if you see the drift while converting times got from various forms

> of rt_get_time you should enable the real time Posix option when 
> configuring RTAI. Than try and see what happens using rt_get_real_time

> and rt_get_real_time_ns.
> paolo
>> Regards,
>> Graeme Foot.
>> _______________________________________________
>> Rtai mailing list
>> Rtai at rtai.org
>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
> _______________________________________________
> Rtai mailing list
> Rtai at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai

More information about the Rtai mailing list