Re: [gentoo-amd64] Re: Recent clock problems

[Tres Melton]

On Sat, 2006-02-11 at 13:07 -0700, Duncan wrote:
> Mark Knecht posted
> <5bdc1c8b0602110941y446deb24qc519fcb40298136a@××××××××××.com>, excerpted
> below,  on Sat, 11 Feb 2006 09:41:20 -0800:
>
> > Hello,
...
> > QUESTION 4:
> >
> > Does ntpd actually update the system clock, or is it another layer yet
> > on top. If I use ntpd and then do hwclock -w does an accurate time get
> > written to the hardware clock?
>
> I don't like the term "system" clock in this context, because it's
> ambiguous as to whether you are referring to hardware or software.  That's
> why I used system/software clock or the like a couple times above, to make
> it absolutely clear which I was referring to.
>
> That said, "system clock" normally refers to the software clock that the
> system uses while running, and yes, ntpd /does/ update it directly --
> well, sort-of.  <g>  Don't worry, the confusion is normal and under the
> circumstances entirely understandable, but there's a logical explanation
> that makes sense once you understand what's going on.
>
> Here's the deal.  ntpd was developed to be used in situations where
> various running programs might be making critical assumptions about the
> system time -- namely that it always moves forward, never backward.  To
> have the time move backward, if the machine's an online server in some
> applications, would be /very/ /bad/!  Thus, by default and if at all

From the ntpd man page:
This may on occasion cause the clock to be set backwards if the local
clock time is more than 128 s in the future relative  to  the  server.
In some  applications,  this  behavior  may  be unacceptable. If the -x
option is included on the command line, the clock will never be stepped
and only slew corrections will be used.


> possible (if the time isn't off by days or years), ntpd will normally
> choose to /skew/ the time, adjusting how fast the machine advances time by
> a few parts per million, rather than stepping it either forward or
> backward by seconds/minutes/hours/days/whatever at a time.
>
> On Linux, the kernel is actually responsible for keeping time, and has a
> userland API that ntpd uses to skew the time, telling the  kernel to
> measure say 999 998 instead of 1 000 000  ticks if the clock is slightly
> fast, until real time catches up, or 1 000 005 ticks instead of 1 000 000,
> if the clock is slightly slow and needs to catch up to real time.  So,
> yes, ntpd /is/ adjusting the time, but ideally, not fast enough that
> anything can really notice it.
>
> Note also that ntpd keeps track of how far your system has drifted from
> the rest of the world, each time it checks in, and uses that to tweak
> system clock speed accordingly.  If you go adjusting the clock yourself
> while ntpd is running, it's going to think something's drastically wrong
> with the system that it gained or lost so much time so fast, and will
> REALLY put the screws on that skew, thereby REALLY screwing up the system
> for a few days, as ntpd adjusts the clock first one way, then the other,

man ntpd:  ... once the clock  has  been  set,  an  error greater than
1000s will cause ntpd to exit anyway.

> until it figures out the real drift of the system once again.  This is why
> I said turn off ntpd before you go screwing with the clock, even the
> little bit of setting the hardware clock from the software clock and then
> the software clock from the hardware clock, as you do by running
> /etc/init.d/clock restart, because even the 100th of a second leap that
> might happen setting the time between the two, would be enough to screw up
> ntpd's calculations and set your time swinging that much more than it
> should, for a day or two.  Once it knows how accurate your system is on

man ntpd:  ... about 2,000 s for each second the clock is  outside  the
acceptable range.  ... 

In spite of the above precautions, sometimes when large frequency errors
are present the resulting time offsets  stray  outside  the 128-ms
range  and  an  eventual  step or slew time correction is required. If
following such a correction the frequency error is so large that the
first sample is outside the acceptable range, ntpd enters the same state
as when the ntp.drift file is  not  present.  The  intent  of  this
behavior  is  to quickly correct the frequency and restore operation to
the normal tracking mode. In the most extreme cases ( time.ien.it comes
to mind), there may be occasional step/slew corrections and subsequent
frequency  corrections.  It helps in these cases to use the burst
keyword when configuring the server.

------------------------
Just had a couple of issues with that.  :)


> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
Cheers Duncan,
-- 
Tres Melton
IRC & Gentoo: RiverRat