[ntp:hackers] Does ntpd need to whine more ?

Mark Martinec Mark.Martinec at ijs.si
Sun Oct 2 21:32:26 UTC 2005


From Poul-Henning Kamp :
> I examined the client population of my public NTP server today and one
> of the things I noticed is that people don't seem to notice when their
> time sync stops working and falls back to localclock or bogusly
> configured refclocks:
>...
> 80.163.104.246     123 no   4 3 11  7 -17 -861.909907751 [LOCALCLOCK#0]
> 84.252.140.74      123 no   4 3 11 10 -17 -656.351917002 [LOCALCLOCK#0]
> 195.137.236.98     123 no   4 3 11 10 -16 -552.525271231 [LOCALCLOCK#0]

I believe there are two main culprits which make people put the LOCAL clock
driver in their ntpd configuration:

- some packages or Unix distributions place it in the default config file,
  quite unresponsively, and people are reluctant to remove what
  looks like it's been provided to their best interest;

- some people believe that during a network outage ntpd will not keep
  adjusting the system clock according to the last determined holdover
  frequency, unless the LOCAL is present - which is a big misunderstanding.

For end-node hosts which do not redistribute time to further clients the
LOCAL is in most cases useless.

For host which *do* redistribute time to their local clients, LOCAL *might* be 
useful in rare circumstances, although I believe that in most cases it is 
best even for the clients to loose their site-local reference when it looses 
its external time sources.

As far as Unix distributions are concerned - are there any channels through
which the removal of LOCAL from a default /etc/ntp.conf could be suggested?

As for the second, it doesn't hurt to say it more than once in the docs that
the use of LOCAL should not be considered without a good understanding
of implications - and certainly not casually, i.e. "just in case".

  Mark


More information about the hackers mailing list