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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
