[ntp:questions] clock skew under reatime tests

Jim Cromie jim.cromie at gmail.com
Mon Sep 12 18:40:02 UTC 2005


hi folks,

Im doing some testing of RTAI/Fusion realtime patches against linux-2.6.13
with ipipe-1.0-02, and configured without APIC, ACPI, or HPET
(my geode-586 board doesnt support them).

Im seeing clock-skews pile up while running the testsuite latency
and klatency tests, and have done some work to characterize it.

over a 300 second test, with a rt-sample period of 100 usec,
and a user-load created by dd $from $to, the skew is highly dependent upon
what the $from is:

using /dev/zero, my ide0 interrupt rate is low, and skew is close to zero.

[jimc at harpo 050912]$ grep ntpdate no-ntp-devnull*|cut -d: -f2-
12 Sep 07:20:46 ntpdate[1803]: adjust time server 192.168.42.1 offset 
-0.402003 sec
12 Sep 07:31:06 ntpdate[2081]: adjust time server 192.168.42.1 offset 
-0.283713 sec
12 Sep 07:41:03 ntpdate[2421]: adjust time server 192.168.42.1 offset 
-0.003998 sec
12 Sep 07:51:40 ntpdate[2704]: step time server 192.168.42.1 offset 
-1.301703 sec
12 Sep 08:01:55 ntpdate[3046]: adjust time server 192.168.42.1 offset 
0.000091 sec
12 Sep 08:12:40 ntpdate[3328]: step time server 192.168.42.1 offset 
-1.021879 sec
[jimc at harpo 050912]$

using /dev/hda1, my interrupt rate is much higher, and I get a skew of 
up to 30 sec

[jimc at harpo 050912]$ grep ntpdate no-ntp-devhda*|cut -d: -f2-
12 Sep 07:31:08 ntpdate[2115]: adjust time server 192.168.42.1 offset 
-0.282644 sec
12 Sep 07:41:00 ntpdate[2393]: step time server 192.168.42.1 offset 
-35.841458 sec
12 Sep 07:51:43 ntpdate[2738]: adjust time server 192.168.42.1 offset 
-0.000014 sec
12 Sep 08:01:54 ntpdate[3018]: step time server 192.168.42.1 offset 
-22.068787 sec
12 Sep 08:12:42 ntpdate[3362]: adjust time server 192.168.42.1 offset 
0.000048 sec
12 Sep 08:23:24 ntpdate[3649]: step time server 192.168.42.1 offset 
-17.200955 sec


heres same, with ntpq -p, which corroborates the above:


[jimc at harpo 050912]$ grep harpo ntp-devnull*|cut -d: -f2-
 harpo           64.113.215.94    3 u    -   64    1    0.601    0.100   
0.004
*harpo           64.113.215.94    3 u   40   64  377    0.770  -238.36  
90.052
 harpo           64.113.215.94    3 u    -   64    1    4.155    4.738   
0.004
*harpo           64.113.215.94    3 u   47   64  377    0.779  -363.39  
97.437
 harpo           64.113.215.94    3 u    -   64    1    0.706    0.180   
0.004
*harpo           64.113.215.94    3 u   64   64  377    0.826  -1060.9 
292.516


[jimc at harpo 050912]$ grep harpo ntp-devhda*|cut -d: -f2-
 harpo           64.113.215.94    3 u    -   64    1    0.572  -244.07   
0.004
 harpo           64.113.215.94    3 u   41   64  377    0.787  -38397. 
11330.0
 harpo           64.113.215.94    3 u    -   64    1    8.135  -358.96   
0.004
 harpo           64.113.215.94    3 u   66   64  377    0.617  -20307. 
6126.75
 harpo           64.113.215.94    3 u    -   64    1    0.603    0.181   
0.004
 harpo           64.113.215.94    3 u    4   64  377    0.861  -12608. 
2891.19


Now I recognize that the 'bug' here is not likely in ntpd, I hope that 
responders here
will resist the urge to dismiss me to another list.  Here are some 
limited questions:


1. my ntpdate test-loop calls ntpdate before and after each run.  the 
1st re-zeros offset,
and the 2nd reports new skew created during the test, (and zeros it).
Besides the missing -b (to step it back to zero) is there anything 
glaringly wrong
 with this approach ?

2.  Similarly, between ntp runs, Im shutting off ntpd, calling ntpdate 
to step the
skew back to zero, and restarting ntpd.  Again, I think I need a -b 
there, but Im
concerned that Im possibly running afoul of any ntp-state thats kept in 
the kernel.

This approach is knocking it out of sync, but that should - if anything -
improve its ability to slew the local clock to follow the ref.

3. which way is my clock skewing ?
A naive guess is that Im losing time (falling behind), but it pays to check,
since the implications are vastly different.

4. any WAG at what kind of error to look for ?



More information about the questions mailing list