[ntp:questions] Re: Calling ONCORE owners...

Tapio Sokura oh2kku at iki.fi
Sun Jan 1 16:37:21 UTC 2006

Carl R. Friend wrote:
>    I've got a Motorola ONCORE UT+ receiver coupled to a Linux box
> running NTP 4.1.1 at 1.786  and OS version 2.4.29-NANO.  At the duly
> appointed hour last evening when I was supposed to get 23:59:60,
> the direct output of the satellite receiver indicated such but NTP
> never altered the system clock.  Further, even with the leap bit set
> from the receiver, the leap bits were not set in NTP.  Needless to
> say, this caused the computer clock to go into a tizzy and it finally
> stepped about a half-hour later.

That's just about what I saw with an Oncore VP 6-channel receiver with 
8.4 firmware on Linux 2.2.19-NANO (Red Hat 6.1) running ntpd 
4.1.1a at 1.791. I only had the Oncore reference driver configured in 
ntp.conf for a week before the leap second, so remote clocks wouldn't 
interfere with the way Oncore handles the leap.

As you mentioned, no warning of the impending leap second was given, the 
machine had the leap bits set to zero all the time. When the leap 
occurred (I didn't monitor the GPS output directly, just via ntpd's 
behavior), things just went on like nothing had happened. After some 
time, I think it took about 10 minutes or so, something somewhere 
realized that there has been a leap and the time was stepped a second 
backwards and then settled there. I logged clockstats and ntpq output 
before and after the leap, but haven't really looked at them yet so the 
above is from memory of what I saw last night. Could this anomaly with 
leap processing with Oncore have something to do with the "fake" leap 
second of 28.11.2003? I did see that fake leap happen then with my unit.

I looked at the behavior of some machines that have multiple upstream 
servers, but no direct reference clocks, many did not handle the leap 
well. After a while some normally very stable machines went into wild 
-500/+500 ppm oscillations trying to jump between servers that leaped 
and servers that didn't leap. After the majority of upstream servers 
started showing correct time after the leap, the oscillations damped out 
slowly, but still 16 hours after the leap some are several tens of 
milliseconds off their upstream servers that have stable time and stable 
network path with a delay of under 10 ms. And some servers didn't have 
any problems with the leap.


More information about the questions mailing list