[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