[ntp:questions] stepping and slewing

David L. Mills mills at udel.edu
Sun May 13 01:13:54 UTC 2007


Serge,

I have no experience with adjtimex(). However, there may be a 
funcamental disconnect about the interaction between ntpd/ntpdate and 
adjtime(). To clear that up, you should see the man page for adjtime(). 
 From the offset argument, it computes the time to reach that offset at 
a rate of 500 PPM. This has nothing to do with the ntpd frequency 
adjustment, which is computed before adjtime() is called.

If using the -gq option, be sure to disable the kernel and set the 
kernel offset and frequency to zero.

Dave

Serge Bets wrote:
> Hello David,
> 
>  On Wednesday, May 9, 2007 at 8:59:36 +0100, David Woolley wrote:
> 
> 
>>This may be a language problem. ntpdate and the part of the kernel
>>that implement the 500ppm limit have no idea what the static error of
>>the clock is
> 
> 
> Yes, I see we violently agree. I confused "static error" with or without
> frequency correction.
> 
> The point I was trying to understand was that the kind of slew
> implemented by ntpdate, ntpd -gq, adjtime(), and adjtimex --singleshot
> always goes at -500 or +500 PPM around the frequency. This slew is
> independant of frequency: whatever frequency value is needed to correct
> a given clock, ntpdate slew still has the full 500 PPM speed in both
> directions.
> 
> This means slew and frequency are cumulative, and the sum can go over
> 500. I experimented on a machine whose driftfile is generally around -2,
> setting frequency to 200 and slewing together:
> 
> | # killall ntpd
> |
> | # ntptime -f +200 > /dev/null			# set frequency = +200 PPM
> | # adjtimex --singleshot +1800000		# slew at +500 PPM during an hour
> | # ntpdate -q 192.168.7.3; sleep 60; ntpdate -q 192.168.7.3
> | 12 May 18:23:55 ntpdate[355]: adjust time server 192.168.7.3 offset -0.001448 sec
> | 12 May 18:24:55 ntpdate[357]: adjust time server 192.168.7.3 offset -0.044440 sec
> |
> | # ntptime -f -200 > /dev/null			# set frequency = -200 PPM
> | # adjtimex --singleshot -1800000		# slew at -500 PPM during an hour
> | # ntpdate -q 192.168.7.3; sleep 60; ntpdate -q 192.168.7.3
> | 12 May 18:24:55 ntpdate[364]: adjust time server 192.168.7.3 offset -0.044966 sec
> | 12 May 18:25:55 ntpdate[366]: adjust time server 192.168.7.3 offset -0.001275 sec
> |
> | # ntptime -f $(cat /var/lib/ntp/ntp.drift) > /dev/null	# restore normal freq
> | # adjtimex --singleshot 0			# interrupt any unfinished slew
> | # ntpd -g
> 
> First, with +200 frequency and a positive slew offset, I queried my main
> stratum 1 server twice with a minute in between. My test machine
> advanced by 43ms in one minute. Roughly +700 PPM.
> 
> With -200 frequency and a negative slew offset, the clock was too slow
> by 43ms in a minute. Roughly -700 PPM.
> 
> Of course the "sleep 60" interval is itself impacted by the slewing
> clock, but the magnitude of the error should be negligable. Note both
> ntpdate and ntpd -gq call adjtime(), which on my system calls adjtimex()
> with ADJ_OFFSET_SINGLESHOT (same as the adjtimex --singleshot command).
> 
> 
> Serge.




More information about the questions mailing list