On Sat, 2006-02-11 at 13:07 -0700, Duncan wrote: > Mark Knecht posted > <[EMAIL PROTECTED]>, 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
signature.asc
Description: This is a digitally signed message part
