[ntp:questions] stepping and slewing

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sat May 12 18:45:11 UTC 2007


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.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list