[H-GEN] TimeZones and Redhat 8.0

[ben.carlyle at invensys.com]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Greg Black <gjb at gbch.net>
Sent by: Majordomo <majordom at caliburn.humbug.org.au>
21/01/03 10:01
Please respond to general

 
        To:     general at lists.humbug.org.au
        cc: 
        Subject:        Re: [H-GEN] TimeZones and Redhat 8.0

| Network Time Protocol.  Running something like ntpd or xntpd is often 
the
| best way to keep a bunch of boxes in time sync.

> ... unless there is a
> high-speed and low-latency connection to a stratum 1 or stratum
> 2 server, the synchronisation to the real time will be lucky to
> average better than 20 to 50 milliseconds.  Of course, this is
> good enough for lots of purposes, but it's much less good than
> the NTP people would have you believe.

Of course, the NTP people recommend that you have at least three 
seperately sourced time servers available to your network to get any kind 
of reliability ;)

> In addition, because the standard NTP software is both flaky and
> subject to regular security exploits, you need to keep it up to
> date and you need to run it under some sort of reliable service
> monitoring tool to ensure that it keeps going.

It's also not very well documented. The documentation is quite good for 
setting up a machine to serve time using, say, a GPS clock being driven 
straight into NTP. It's not so good for describing how to set up a server 
which is recieving time synchronisation into it's local clock via some 
other source[1]. I had a situation in my work environment where another 
person had setup NTP to synchronise three servers, one of which at any 
time would be reciving synchronisation from an alternate source into it's 
local clock. While there was docuementation describing how to setup this 
kind of server, the documentation was wrong. The server would work for 
about 24 hours, then all the client clocks would suddenly refuse to 
synchronise off the main. It turned out that with the documented setting 
the local ntp was notching up it's approximate error count every few 
seconds. Since it hadn't set the local clock, and the time provider app 
had no way of telling ntp that it had set the local clock the ntp server 
eventually estimated that it was up to 1 second off time-synchronisation. 
The clients happily packed up and stopped accepting updates from the 
server and we were left with main/backup machine pairs which were at least 
serveral seconds apart in time synchronisation.

Eventually via much irc help and code grepping I found an undocumented 
version of the same feature which did not notch up the error estimate :)

NTP could be a better product than it is, but I think that it's not the 
kind of work that most people want to get into :) They say that once you 
know sendmail you'll never escape your destiny of supporting it, and 
perhaps NTP has a similar strange attractor effect. That said, it's 
probably still the best thing out there for arbitrary LAN/WAN 
time-synchronisation configurations available. Anything better really 
requires help from the low-level network protocols themselves.

Benjamin.

[1] The documentation essentially recommends hacking your kernel and 
adding extra system calls so that ntp will be notified whenever such a 
synchronisation occurs


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/