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

Oxy Hazard 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.

b.r.

oxy


"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
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