On 2011-12-19, [email protected] <[email protected]> wrote: > > The default ntp.conf file in RHEL5.7 contains the following lines: > > # Undisciplined Local Clock. This is a fake driver intended for > backup > # and when no outside source of synchronized time is available. > server 127.127.1.0 # local clock > fudge 127.127.1.0 stratum 10
And those lines should be commented out so they are used only by someone who has taken the time to at least read the ntp.conf file. But it is also wrong. It is NOT a backup or useful when no outside source of time is available. It is never useful for time setting. The only purpose is so that ntpd keeps reporting that it is synchronized, and other clocks therefor can depend on it. > > I did not change these lines, hoping that the high stratum number would > prevent use of the local clock by ntpd except when network time servers > are unavailable. Not sure why the existence of a stratum 10 time source > would cause a 20 minute delay before issuing a "time reset", but I > confess I don't know whether the "local clock" is the timer-interrupt > driven system time. the "CMOS" time of day clock (hardware clock) or some > other hardware clock source. > The local clock is the system clock itself that ntpd is trying t odiscipline. It, it is like setting your wristwatch by getting the time from your wristwatch. Loh and behold, it is always exactly on time. >>Is there a reason to not use orphan instead in that case? > I was not aware of it. Apparently orphan is an improved alternative to > the local clock that can be used instead of the local clock when access to > timeservers is lost. So I need to check it out. No, it is a way that a time server can deliver time to others even if it has no good idea what the correct time is. > >>GUI > Thanks for the warning on the Gnome GUI. In this case I control what is > in /etc/ntp.conf for these servers and do not use a GUI. > >>Try running your system 24x7! If you can't do that, try a program >>called "chrony". NTPD was never intended for "off again, on again" > service! > > Well for me 24x7 still means booting once or twice a year, at least to > install software updates. Test systems are booted much more often, but > are less critical (unless the time issue messes up tests). > > I was not aware of chrony since it is not in RHEL5, but I see that it is > now in Fedora, so I can take a look. > > Using the RedHat service script packaging, I added -x to OPTIONS in > /etc/sysconfig/ntpd and sett SYNC_HWCLOCK=yes. This causes the ntpd start > script to run an ntpdate command followed by a hwclock command (to update > the "CMOS" clock), before starting ntpd. This only adds a few seconds to > the boot. Oh well, what can you do. > > Even though the existence of local clock causes ntpd to take 20 minutes to > become confident of the correct time, running ntpdate before ntpd starts > means that when ntpd figures out what time it is, the difference is likely > to be within the skew time so that a "time reset" is not needed. > > Is there any problem with using this approach? > > I agree that systems should not lose time across a boot, but it happens. > Further, the "CMOS" clock's resolution is one second. I'm not sure that > as Linux starts, it waits for a tick before setting the time from that > clock. Not handling that correctly would introduce a 1/2 second error (on > average). _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
