[ntp:questions] Re: xntpd crash on solaris 8
oxy_hazard at hotmail.com
Tue Jul 25 09:09:41 UTC 2006
yes, you are right, it's not a normal case, I just wanna copy the case
happened in our customer's site, I also suspected some administrators
modified the time of client manually (offset>1024s), the xntpd crashed.
I will modify the configuration of strtum and poll interval as you
commended, and check the audit record of sun boxes, thanks for hints from
all of you.
"David Woolley" <david at djwhome.demon.co.uk> Ð´ÈëÓÊ¼þ
news:T1153810565 at djwhome.demon.co.uk...
> In article <1153790786.409182 at slbhw0>, kk at girard.org wrote:
> > When startup the xntpd on 3 boxes, all time are syncronized. If I
> 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
> > 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
> 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