[ntp:questions] Re: Large offset problem with xntpd 3.4x, DEC UNIX, and TrueTime NTS-100s

Richard B. Gilbert rgilbert88 at comcast.net
Sat Sep 10 21:09:11 UTC 2005


Richard B. Gilbert wrote:

> Spence Green wrote:
>
>> I was recently tasked with fixing a time synchronization setup on a 
>> closed network.  We have two old TrueTime GPS XL receivers each 
>> connected over IRIG-B to two TrueTime NTS-100 (560-5151) NTP time 
>> servers (four total NTS-100s).  I don't know which version of the ntp 
>> daemon the NTS-100s run, but they were released in 1996.  They cannot 
>> peer with each other and are locked in mode 4 (server) operation.  
>> Each NTS-100 has an ethernet connection.  From the client side, we 
>> have several hundred DEC Alpha workstations, each running Digital 
>> UNIX 4.0d and xntpd 3.4x.  I've tested a number of synchronization 
>> configurations, but for this example, assume the following:
>>
>> #ntp.conf
>>
>> driftfile /etc/ntp.driftfile
>>
>> server time001 version 3
>> server time002 version 3
>> server time003 version 3
>> server time004 version 3
>>
>> #Some logging directives
>>
>>
>> Each client thus runs at stratum 2.  We have a problem with large 
>> offsets, though.  Several weeks ago, one of the NTS-100s went down 
>> due to a power failure.  When it came back up, it had incremented its 
>> year (IRIG-B does not contain year information, so on these NTS-100s, 
>> the admin must set the year via RS-232).  Within a few days, all of 
>> the daemons had detected the 1000s+ offset and committed suicide (we 
>> aren't using "-g" or any other command line option).  The admins were 
>> not aware of this behavior and thus did not detect the failures.  The 
>> machines started drifting, etc.
>>
>> I've read the NTP RFCs and most of Dr. Mills' website.  From my 
>> understanding, the intersection algorithm, if given a sufficient 
>> number of low stratum samples, should eliminate falsetickers.  In 
>> this scenario, three of the time servers remained within a 
>> millisecond of each other, while the fourth was a year and a day 
>> off.  I've run a number of tests: using 8+ stratum 1 hosts per 
>> client, using peering between clients, adding a layer of stratum 2 
>> servers and forcing clients to stratum 3, implementing a local clock 
>> driver.  Without exception, I observe the following behavior in ntpq 
>> after restarting xntpd (delete drift files and logs, run ntpdate to 
>> step time, start xntpd with no flags):
>>
>> 1) Clients select one of the four sources and synchronize their 
>> clocks.  All client daemons operating correctly.
>> 2) I manually increment the year on one of the servers.
>> 3) All client daemons detect the large offset and switch to another 
>> server.  ntpq shows an "x" by the faulty server, indicating 
>> elimination by the intersection algorithm.
>> 4) Eventually, I see an "x" by every server/peer.  xntpd writes 
>> "Synchronisation lost" in the syslog and then aborts.
>>
>> 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.  Is there a bug in this version of xntpd?  I 
>> cannot update the daemon's due to a configuration freeze on these 
>> systems.  I've tried many different synchronization subtrees to no 
>> avail.  Our program cannot purchase new time server equipment that 
>> consistently stores year information.  Does this intersection 
>> algorithm fail for large offsets?  I'm at a total loss on this one.  
>> Does anyone have experience with this issue?
>>
>>
>> Thanks in advance,
>> Spence
>>
>>
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.isc.org
>> https://lists.ntp.isc.org/mailman/listinfo/questions
>>
>>  
>>
> I hate to think how old xntpd V3.4 must be!!!  Is there any 
> possibility that you could upgrade to something ten years newer?   The 
> current version is 4.0, soon to be 4.1 and a lot of fixes and 
> improvements have been made in the last ten years or so.

Sorry, I goofed!!   The current version is V4.2.0 soon to be V4.2.1.




More information about the questions mailing list