[ntp:questions] Large offset problem with xntpd 3.4x, DEC UNIX, and TrueTime NTS-100s
Brad Knowles
brad at stop.mail-abuse.org
Sat Sep 10 11:15:36 UTC 2005
At 1:25 PM -0400 2005-09-09, Spence Green wrote:
> I've read the NTP RFCs and most of Dr. Mills' website.
Keep in mind that Dr. Mills is continuing to update his website
to track the current version of the Reference Implementation of the
NTP protocol, and much of the material there may not be appropriate
for application to the older versions. RFC-1305 would be applicable
to your version, as would any older versions of the official
documentation that date back to that same period.
But be very careful when trying to apply more recent
documentation to ancient code.
> From my
> understanding, the intersection algorithm, if given a sufficient number
> of low stratum samples, should eliminate falsetickers.
That's the way it's supposed to work, yes. However, without
having the source code in front of me to the version you're using,
and without being a talented system programmer, I can't be sure that
the code you've got is actually applying the algorithm correctly.
But from what you've described, it's not.
> I've searched the list archives and the internet about large offsets;
> most sources say that xntpd detects falsetickers with an appropriate
> number of sources.
It should, but then most of the posts you're likely to find will
probably be describing much newer versions of ntpd, unless you've
made sure to include "xntpd" as part of your query. Even then, they
may well be posts about versions of xntpd that are newer than what
you have.
> Is there a bug in this version of xntpd?
It certainly sounds like you've found a pretty major bug, but I
do not have first-hand knowledge of any such beast.
> I cannot
> update the daemon's due to a configuration freeze on these systems.
What you describe does not appear to be fixable with a simple
configuration change. I believe that you would be required to make
code changes, which you say are impossible.
> Our program
> cannot purchase new time server equipment that consistently stores year
> information.
Okay, so you can't make software changes in order to be able to
deal properly with the hardware problems, and you can't make hardware
changes in order to allow the code to work better.
Maybe it's just me, but it sounds like you are well and truly
screwed. I certainly hope that you will be able to find a solution
to your problems that you can actually implement, without making code
changes or buying new hardware. However, I fear that I cannot hold
out much hope for you.
--
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the questions
mailing list