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

Jim Cromie jim.cromie at gmail.com
Mon May 8 06:01:25 UTC 2006


Richard B. Gilbert wrote:

thanks Richard

> Jim Cromie wrote:
>
wrt linux kernel patch
>> Ive been logging its 'performance' thru a dumb little script:
>>
>> while true; do
>>    echo
>>    uptime
>>    ntpq -p
having read some recent posts, Ive changed that to -pcrv

snip
>>
>> 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.
>
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 
under lock,
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 
the free-running
hardware timer, driven by a crystal, rolls over, its treated as 
X+epsilon nanoseconds,
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 
correction.

 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  
jitter
==============================================================================
*harpo           216.82.75.146    3 u   22  128  377    0.865   10.913   
9.481
+ns2.pulsation.f 194.2.0.28       3 u   73  128  277  114.431   -0.829  
66.063
 LOCAL(0)        LOCAL(0)        13 l   21   64  377    0.000    0.000   
0.004
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 
(1)"?,
processor="i586", system="Linux/2.6.17-rc3-mm1-hrt-clksrc-sk", leap=00,
stratum=4, precision=-18, rootdelay=96.293, rootdispersion=325.746,
peer=19036, refid=192.168.42.1,
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.

http://ntp.isc.org/bin/view/Support/HowToCalibrateSystemClockUsingNTP


>> 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) :-)  

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 
the network
across unknowable routes"

I would however expect much better timing jitter from a 
null-ethernet-cable 'network'
without any other nodes, switches, just some traffic between the 1 boxes.


thanks again




More information about the questions mailing list