[ntp:questions] ntpdate removal is coming
Chad.Farmer at Bull.com
Chad.Farmer at Bull.com
Mon Dec 19 23:14:40 UTC 2011
Thanks to everyone for the responses, lots of good information and things
to consider, particularly chrony and orphan. In return I think I should
reply to your questions.
>you are using an old version of ntp.
Yes, I'm using RHEL5.3 (ntp-4.2.2p1-9.el5) and in the process of moving to
RHEL5.7 (ntp-4.2.2p1-15.el5). For this thread I would rather not get into
all that.
>Why are you running a LOCAL refclock? This is the reason it is taking
you 20 minutes to sync when you have found another time source.
>You should not be using the Undisciplined Local Clock (127.127.1.x, aka
"LOCAL") unless this ntpd must be able to serve time to others when no
real time sources are available.
Yes, I need to distribute a consistent time (even if somewhat incorrect)
to several systems on a local LAN (without DNS or Internet access).
Timeservers are accessed on the "ntpd system" through a different LAN
(normally they are accessible). The "local LAN" systems do not have
access to the other LAN.
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
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.
>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.
>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.
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).
More information about the questions
mailing list