In article <1153790786.409182@slbhw0>, kk@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.

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" дÈëÓʼþ
news:T1153810565@djwhome.demon.co.uk...
> In article <1153790786.409182@slbhw0>, kk@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.
>