🚀 go-pugleaf

In article <1992Dec23.015924.19111@shearson.com>,
pmetzger@snark.shearson.com (Perry E. Metzger) writes:
> Unfortunately, xntp3 has a bug that prevents the local clock as time
> source option from working, and no one out there seems to have a fix.

It works for me, after some small modifications (which I have reported
to Dave Mills).  Take the following explanation with a grain of salt,
because I am really not an expert on NTP.  It would be nice if somebody
who knows what he is talking about could confirm or refute this.

The problem is that the test for (peer->synch <= NTP_MAXDISTANCE) in
ntp_proto.c fails.

For local clocks, in which the peer->delay and peer->rootdelay are zero,
peer->synch ends up being approximately equal to (peer->rootdispersion
+ peer->dispersion).  It's only approximately equal because of the
difference between sys_clock and sys_lastselect.

In both xntp2 and xntp3, the local clock's dispersion is 1 second and
the rootdispersion is 5 seconds, making the synch distance approximately
6 seconds.  In xntp2, NTP_MAXDISTANCE was 16 seconds, so the local
clock worked.  In xntp3, NTP_MAXDISTANCE is 1 seconds, so it doesn't work.

To make synchronisation from the local clock work again in xntp3,
one could either increase NTP_MAXDISTANCE (in ntp.h) or decrease the
LCLDISPERSION and LCLROOTDISPERSION in refclock_local.c.  I have done
both: I increased NTP_MAXDISTANCE back to the 16 seconds that was used in
xntp2, and I added a couple of fudge factors to control the LCLDISPERSION
and LCLROOTDISPERSION at run time instead of at compile time.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett