Ive hacked together a clocksource driver which uses the new GENERIC_TIME
API which is part of linu 2.6.17-rc3-mm1, and Im looking for advice on
how/whether
I can use ntpd to 'test' it.
Ive been running it for past 12 hrs, slaved to my laptop thru a
null-ethernet cable,
and to a stratum 2 clock across a wireless interface.
Ive been logging its 'performance' thru a dumb little script:
while true; do
echo
uptime
ntpq -p
sleep 60
done
heres a tiny chunk:
17:04:37 up 11:52, 1 user, load average: 0.00, 0.00, 0.00
remote refid st t when poll reach delay offset
jitter
==============================================================================
+harpo 216.82.75.146 3 u 948 1024 377 1.315 1.033
3.081
*entry.verboten. 130.149.17.21 2 u 1010 1024 377 119.114 -1.645
0.086
LOCAL(0) LOCAL(0) 13 l 29 64 377 0.000 0.000
0.004
17:05:43 up 11:53, 1 user, load average: 0.00, 0.00, 0.00
remote refid st t when poll reach delay offset
jitter
==============================================================================
+harpo 216.82.75.146 3 u 1014 1024 377 1.315 1.033
3.081
*entry.verboten. 130.149.17.21 2 u 53 1024 377 133.653 -3.814
555.714
LOCAL(0) LOCAL(0) 13 l 24 64 377 0.000 0.000
0.004
Im seeing steps in some of the numbers thats disturbing, and Id like to find
whether its normal, artifacts of sampling or polling rate, or a sign of
something amiss.
the 2 samples above show a large jump in the jitter from the distant source.
This probably doesnt mean anything, since its subject to the vagaries of
the network
across unknowable routes, but Im seeing them elsewhere too.
Forex, heres a grep of the laptop peer sync-data
+harpo 216.82.75.146 3 u 933 1024 377 1.086 4.115
0.610
+harpo 216.82.75.146 3 u 994 1024 377 1.086 4.115
0.610
+harpo 216.82.75.146 3 u 32 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 93 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 154 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 214 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 275 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 336 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 396 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 462 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 523 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 584 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 644 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 705 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 766 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 827 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 888 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 948 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 1014 1024 377 1.315 1.033
3.081
+harpo 216.82.75.146 3 u 52 1024 377 1.435 -0.553
1.586
+harpo 216.82.75.146 3 u 112 1024 377 1.435 -0.553
1.586
+harpo 216.82.75.146 3 u 173 1024 377 1.435 -0.553
1.586
It looks a lot like the offset,jitter fields step only when the when
field rolls over,
thus it looks like an artifact, is that a correct inference ?
In addition, Id like to use the /var/lib/ntp/ntp.drift
to compute a correction for the free-running frequency Ive told the driver
about the crystal. Is that possible / sensible / wise ?
cat /var/lib/ntp/ntp.drift
-46.177
While Im asking, does anyone here know where pics/graphs of rms jitter
energy vs freq
are available for a variety of timing-sources, including those that show
up in PCs
and server boxes.
Does the jitter number on
LOCAL(0) LOCAL(0) 13 l 17 64 377 0.000 0.000
0.004
have a real meaning wrt the frequency noise in the PC's clock ?
Finally, is this slightly cheesy approach to test/verification have any
credibility for
what Im trying to demonstrate (ie that the driver works, or at least
isnt badly broken).
If not, is there another way, without instrumentation, to do so ?
tia
-jimc
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
