Accuracy of rt_get_time_ns()?
Calin A. Culianu
calin at ajvar.org
Wed Jul 26 19:44:07 CEST 2006
Hmm. I would imagine the rt_get_time_ns value comes from the pentium TSC
in oneshot mode. Perhaps the code that calibrates the clock frequency of
your processor to convert the TSC value to nanos is buggy for your machine
for some reason, hence leading to the drift you have observed? With
really good calibration ideally the timing precision should be <=100 ns
for a 333MHz machine (assuming some generous overhead to read the tsc,
convert to nanos, etc), and the drift shouldn't be nearly even 1 part per
billion, let alone one part in 3000. It really looks like the calibration
somehow failed for your machine... but a real RTAI developer would
probably be able to help you better.
You aren't using any powersaving features are you? Or CPU frequency
PS: how are you measuring the clock drift? Are you comparing it to
linux's own gettimeofday or somesuch? Another possibility is that your
reference time is actually the innacurate time...
On Wed, 26 Jul 2006, John F. Wesseling wrote:
> What is the timing accuracy of rt_get_time_ns() supposed to be?
> Also, what is the preferred way to keep track of timing?
> In my hands - details below - the timer is losing 1 ms every 3 s (1:3000).
> I only need 100 microsecond precision, but I do need much better accuracy,
> i.e. something like 100 microseconds/100 s (1:1E6).
> Details: kernel: 18.104.22.168 patched with rtai 3.1 patch hal7-22.214.171.124.patch
> processor: 333MHz Pentium 2 lxrt (I think)
> one shot mode (I think)
> Apologies if this question is obvious: I am new to Linux and RTAI.
> John F. Wesseling, Ph.D.
> Departamento de Neurociencias
> Centro de Investigación Médica Aplicada (CIMA)
> Pio XII, 55
> 31008 Pamplona
> Phone +34 948 19 47 00 ext. 2005
> (if you don't speak Spanish, when the recording comes on,
> just enter the extension and wait)
> Fax +34 948 19 47 15
> RTAI mailing list
> RTAI at rtai.org
More information about the Rtai