https://bugzilla.novell.com/show_bug.cgi?id=337075
User martin.burnicki@meinberg.de added comment
https://bugzilla.novell.com/show_bug.cgi?id=337075#c23
--- Comment #23 from Martin Burnicki 2008-01-09 09:41:17 MST ---
I've made some more tests today and here are some additional notes:
1.) The "local clock" (127.127.1.0) should not be in the configuration file by
default. If it is then ntpd selects it as system peer if no upstream servers
are reachable (in ntp-dev this takes just a few seconds). Once this has
happened it takes a very long time until ntpd synchronizes to the upstream
servers when they become reachable.
If the initial time offset then exceeds ntpd's so called sanity limit ntpd
stops itself. Checking the sanity limit can be disabled by a "tinker panic 0"
entry in ntp.conf, but this would not solve all problems.
If the "local clock" had been selected as system peer before and the initial
time offset would require the system clock to be stepped then the step happens
only after the "reach" of the upstream server has increased to "77", i.e. after
6 or 7 polling cycles. Unfortunately ntpd increases the polling interval in
this case quickly up to 1024, so it might take up to ~7000 seconds until the
system time would initially be set correctly. This is not acceptable.
So, since the "local clock" entry is not required in most cases, it should not
be there by default. The "local clock" makes sense only if the machine shall
also act as a NTP time server. Normally such machines have a continuous network
connection, so the proplems discussed here don't apply in that case.
2.) Notifying ntpd using "ntpdc -c ifreload" whenever a new network interface
has become available or unavailable works very well. However, this requires
symmetric key authentication for ntpdc and should only be used as a workaround
as long as ntpd does not support the routing socket under Linux. Anyway, this
eliminates the delay until ntpd would detect the new interface automatically.
3.) Once the first network interface has become available the DNS service
should be useable to resolve the host names of the upstream servers. Ntpd runs
a resolver thread which waits until DNS is ready to resolve those names.
Unfortunately the retry interval for the resolver starts at 60 seconds and
increases by doubling (i.e. 120, 240, ...) every time an unsuccessful DNS
lookup has been made.
This is really ugly since this means the longer it takes after system boot
until the network becomes available, the longer it takes _after_ the network
has become available until ntpd can start querying the upstream servers.
Fixing this requires a patch for ntpd which triggers a DNS retry whenever a new
interface has been detected. I'm going to contact some of the NTP developers to
see how this can be implemented properly.
Martin
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.