Carl R. Friend wrote:
I've got a Motorola ONCORE UT+ receiver coupled to a Linux box running NTP [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
Tapio _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
