[ntp:questions] Optimal config
Richard B. Gilbert
rgilbert88 at comcast.net
Mon May 5 18:28:07 UTC 2008
Peter Laws wrote:
> Hello, time nerds. :-)
>
> Here's what I want: accurate time to at least a few ms of UTC. Don't
> think I have users that need better than that. I'd like the time to be
> continuous and not jump around, of course.
>
>
> Here's what I have: 3 GPS clocks (two old Datum TymServe 2100s and one
> unknown). Two are fairly close geographically and the third is about 2
> miles away.
>
>
> Currently, I have 4 systems (RHEL 3 on Dell HW) that are peered to each
> other and use all three GPS clocks as references. OK, looks like I have
> two others peered as well - similar to the others but RHEL 5.
>
> I also have another group of 4 servers peered together (RHEL 5 on Dell
> except one that is running an NPAD server on Knoppix) in a similar setup
> with the same three GPS clocks as well as two external Stratum 2 servers.
>
> iburst is on for all (saw that thread and will disable for externals!)
This is probably a "red herring". There is normally no reason NOT to
use iburst. Burst is another story! Several HUNDRED systems starting
up simultaneously and all using iburst could cause problems but this is
something you would have to work very hard to achieve! ;-)
Iburst simply causes ntpd to send eight requests to a server at
intervals of two seconds when it initializes. The eight replies that
will normally result allow ntpd to fill its filter pipeline and make a
pretty good guess at what time it is. Subsequent requests are sent at
the normal poll intervals, ranging from 64 to 1024 seconds.
Burst, OTOH, is a special purpose hack intended for systems getting time
over a dial-up telephone line and where calls might be initiated two to
four times per day and last for only a minute or two.
>
> On my own workstation, using 8 of the ten server mentioned above :-) I
> see messages like this:
>
>
> May 5 09:44:05 toto ntpd[5589]: synchronized to xxx.xxx.xxx.xxx, stratum 2
>
> where my client daemon seems to flip around from one of my servers to
> the others.
>
> I have real servers that use the first 4 I described above as their
> "server" entries and I see similar "synchronized" messages.
>
>
> What can or should I do to make this more robust? Would a "prefer"
> statement help? Should I use more or fewer peers?
Prefer should put a stop to the "clock hopping". OTOH, as long as the
clocks in question have the *same* time, the clock hopping should not
cause problems.
More information about the questions
mailing list