[ntp:questions] Odd behaviour in a multicast setting (bug in ntpd???)

[Harlan Stenn]

Marco wrote:
> Il 30/08/2011 10:35, Harlan Stenn ha scritto:
> >> That could be. The point is: if I install a newer version on clients,
> >> > I'll have to restart ntpd, and once I restart it, it will probably
> >> > work (like all the other times we restarted them) and tell us nothing
> >> > about the problem.
> > It is interesting that the problem solves itself after a reboot.
> 
> Not actually a reboot, but a restart of ntpd.

My typo - sorry...

> > I did notice that the system that has the problem you mentioned with the
> > host that does unicast is an outlier...
> 
> That's not always the case, e.g., on one machine it is currently a
> candidate:
> 
> >      remote           refid      st t when poll reach   delay   offset  jit
> ter
> > ===========================================================================
> ===
> > +s51            69.25.96.13      2 m  283 1024  377    0.276    4.844   0.0
> 11
> > +s11            128.9.176.30     2 m   41   64  377    0.203   -1.618   0.0
> 61
> > *s12            204.123.2.5      2 m   56   64  376    0.001   -2.596   0.0
> 47
> > -s52            204.9.54.119     2 m   22   64  376    0.001  -12.454   0.0
> 58

s51 has a 1024 poll time but it's not unicast...

> What you can notice, anyway, is that on those machines that show the
> problem, the peer is "flapping" a lot:
> 
> > Aug 30 05:04:43 XXX ntpd[3989]: synchronized to <s51's address>, stratum 2
> > Aug 30 05:10:39 XXX ntpd[3989]: synchronized to <s12's address>, stratum 2
> > Aug 30 05:56:12 XXX ntpd[3989]: synchronized to <s51's address>, stratum 2
> > Aug 30 06:05:21 XXX ntpd[3989]: synchronized to <s12's address>, stratum 2
> > Aug 30 07:23:01 XXX ntpd[3989]: synchronized to <s51's address>, stratum 2
> > Aug 30 07:44:32 XXX ntpd[3989]: synchronized to <s12's address>, stratum 2

I think we removed these messages because they were too noisy and did
not really offer useful information

> Does this add any useful information?

Yes, and I still think it would be Interesting to see if you can
replicate the problem with a recent -stable release (or -dev even, as we
are close to starting the release cycle for 4.2.8).

H