On Wed, 12 Aug 2009, Alejandro Redondo wrote:
Well, the first clock set, when ntpd starts, is made in just one step.
This can be a problem when the client host is several seconds different than
the ntp server.
Stepping versus slewing can be configured in ntpd. By default small time
offsets are slewed, and large offsets stepped.
In the example I suffered, I had to sync different flavors clients with the
ntpd servers.
Unluckily some of them had the ntpd daemon stopped for a lot of time and they
had differences, to have an example, about 100secs (ntpdate -d <ntp_serve>
used to know it).
It was not a problem on solaris/hpux boxes to use the "date -a 100.00" and
then restart the ntpd daemon with the right config avoiding a 100secs jump in
time.
How fast does the kernel slew? A 0.5ms/s drift rate will fix 100s error
in around 2.3 days; slewing is inappropriate for large corrections. If
software can't tolerate backward steps in time then perhaps it's better
to halt it while the system clock is fixed. (BTW, leap seconds make
this hard.)
These commands are better suited to altering the frequency of the system
clock:
ntpdate -B
ntpd -g -q -x
adjtimex --singleshot
Cheers,
Phil
