[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