[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