[ntp:questions] Re: Calling ONCORE owners...
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