[ntp:questions] Re: ntp performance, jitter, etc and its implications for test/verification of a timing source
jim.cromie at gmail.com
Mon May 8 06:01:25 UTC 2006
Richard B. Gilbert wrote:
> Jim Cromie wrote:
wrt linux kernel patch
>> Ive been logging its 'performance' thru a dumb little script:
>> while true; do
>> ntpq -p
having read some recent posts, Ive changed that to -pcrv
>> 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 ?
> Your offset and jitter fields are recalculated at each poll interval.
> You are polling every 1024 seconds so it takes about 17 minutes to get
> new values. The fact that you are polling at 1024 second intervals
> suggests that ntpd is very satisfied with its selected soure(s).
>> In addition, Id like to use the /var/lib/ntp/ntp.drift
>> to compute a correction for the free-running frequency Ive told the
>> about the crystal. Is that possible / sensible / wise ?
> Ntpd will correct the frequency as long as it's running. If it loses
> contact with its time source(s) it will continue to use the last value
> it calculated.
Let me re-explain what Im after.
I could shutdown ntpd, and let the hardware timer free-run.
Id expect the frequency to go its natural way, so without the correction
it would end up with a different time, and I could compute PPM error
from the duration and the diff.
Ive told the clocksource driver that the hardware is a hires timer at
1.000000 Mhz, which is
somewhat inaccurate. I want to add/subtract some tiny amt so that when
hardware timer, driven by a crystal, rolls over, its treated as
not just X
Id rather not wait 12 hrs to get a reasonably accurate number,
so Id like to take some number (the 'correction') from ntpd itself and
compute the free-run freq
from it. One of the numbers in the ntpd state represents the frequency
22:27:49 up 44 min, 2 users, load average: 0.00, 0.00, 0.00
remote refid st t when poll reach delay offset
*harpo 22.214.171.124 3 u 22 128 377 0.865 10.913
+ns2.pulsation.f 126.96.36.199 3 u 73 128 277 114.431 -0.829
LOCAL(0) LOCAL(0) 13 l 21 64 377 0.000 0.000
assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0a at 1:4.2.0a+stable-8-r Fri Oct 28 15:39:49 CEST 2005
processor="i586", system="Linux/2.6.17-rc3-mm1-hrt-clksrc-sk", leap=00,
stratum=4, precision=-18, rootdelay=96.293, rootdispersion=325.746,
reftime=c809553f.94e9c454 Sun, May 7 2006 22:27:27.581, poll=7,
clock=0xc8095555.ec17ebaf, state=4, offset=3.527, frequency=0.352,
noise=18.505, jitter=15.091, stability=555.907
and I just found this.
>> cat /var/lib/ntp/ntp.drift
>> 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 ?
> The jitter, as I understand it, is a measure of the phase noise in the
> time received from the server. Think of sending packets over the
> internet at EXACT 1 second intervals. Do you think that those packets
> will arrive at their destination at the same EXACT 1 second intervals
> at which they were sent? (If you do, I want some of whatever you're
> smoking) :-)
Ive never been that stoned ;-) hence the previous msg comment
"show a large jump in the jitter from the distant source.
This probably doesnt mean anything, since its subject to the vagaries of
across unknowable routes"
I would however expect much better timing jitter from a
without any other nodes, switches, just some traffic between the 1 boxes.
More information about the questions