[ntp:questions] Re: ntp performance, jitter, etc and its implications for test/verification of a timing source

Richard B. Gilbert rgilbert88 at comcast.net
Mon May 8 02:30:31 UTC 2006


Jim Cromie wrote:

> 
> 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 ?
> 
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 driver
> 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.

> 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 ?
> 
>
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) :-)  The network introduces errors by introducing small 
variations in transit times to and from the server and jitter is  a 
measure of that error.  See RFC 1305 for a discussion of the math; as a 
mathematician, I can usually count to twenty with my shoes on. :-)






More information about the questions mailing list