[ntp:questions] Re: xntpd crash on solaris 8

David Woolley david at djwhome.demon.co.uk
Tue Jul 25 06:56:16 UTC 2006


In article <1153790786.409182 at slbhw0>, kk at girard.org wrote:

> When startup the xntpd on 3 boxes, all time are syncronized. If I adjusted

xntpd is obsolete.  One vendor misnames the current ntpd as xntpd,
but I don't believe that that is Sun.  However, I think the following
is still essentially true.

> the time of client 10 min forward, xntpd could sync it by about 4 poll

This is not a reasonable thing to do to an NTP system.  Having a system
without UTC traceable sources is somewhat borderline, at best, although
rather commonly done, but having time sources that don't behave like
UTC (i.e. don't advance at almost exactly 1 second per second give or
take measurement errors) is well outside the intended normal use of
NTP.

> interval, but when I adjusted the client time about 2 hours forward, the
> xntpd daemon crashed after about 4 poll interval!

Already noted that this is by design.

Also, although not directly relevant to the original question.

> server 127.127.1.0 prefer
> fudge 127.127.1.0 stratum 0

This is considered very bad practice.  Local clocks as references should be
set as close to stratum 16 as possible, consistent with the network
topology, so that there is no chance that they will ever be confused
with a properly traceable time source.

> peer BJWSS_sam_1_6_1

Peering machines using local reference clocks isn't a good idea.
It's just possible that having only two machines involved and your use
of prefer mitigates the instabilities that this can cause, but the right
way of providing redundancy is to establish a client server relationship
and make the local clock stratum on the combined client/server be at
least two larger than that on the server.  Or maybe that's why you
had to comment out the server on 1_6_1.

> server BJWSS_sam_1_5_1  prefer
> peer BJWSS_sam_1_5_1 minpoll 6

peer and server are mutually exclusive.

> server BJWSS_sam_1_5_1 prefer minpoll 6 maxpoll 7

Using the default minpoll and maxpoll is strongly reccommended.  Note.
I believe that maxpoll doesn't limit the loop time constant, in which
case, it will not make the client as responsive to phase variations
in the server as I suspect you are trying to achieve.  As already 
noted, deliberately introducing phase variations is not an intended
use case for NTP.

It may make it more responsive in terms of the error recovery when
exceeding the 128ms step out limit, but, as noted above, that is not
intended to be used in normal operation.  Note, though, that there
is still a long confirmation delay before stepping.




More information about the questions mailing list