[ntp:questions] Re: Motorola Oncore receivers and Leap Second bug

Tim Shoppa shoppa at trailing-edge.com
Wed Aug 13 20:35:05 UTC 2003

Terje Mathisen <terje.mathisen at hda.hydro.com> wrote in message news:<bh7k5n$ihb$2 at osl016lin.hda.hydro.com>...
> Tim Shoppa wrote:
> > Motorola's announcement, dated 19-Jul-2003, at
> > 
> >   http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf
> > 
> > says that Oncore VP,UT, GT, and M12 models will report the wrong calendar
> > date at 11/28/2003 00:00:00 UTC, instead reporting that the date is
> > 11/29/2003 for that single second.
> > 
> > *My* inference is that this will only happen when the Oncore is reporting
> > UTC (as opposed to GPS) time, but I could be mistaken.
> If it really only occurs for that single second, I'm not going to worry 
> about my server:
> The 24 hour off time stamp will simply be discarded as obviously bogus, 
> and then a second later everything will be OK again, right?

I think that the discarding will occur at the ntpd level intersection
algorithm and not in the Oncore refclock module, because the
bad date *is* properly formatted
(just wrong by one day).  My conclusion is that if the Oncore is polled in
the bad second it will be declared a falseticker.

The PPS output from the Oncore remains good throughout, but if the Oncore
is declared falseticker isn't PPS disabled by ntpd until the Oncore goes
truechimer again?

I haven't messed much with the guts of the Oncore refclock (my hacking
experience extends only to HP and PARSE refclocks) so these are just
guesses of mine.  I do know that if my Z3801A or my SV6 output bad UTC
time information that they'll be excluded by the intersection algorithm
and PPS won't be turned on until the serial timestamps are correct.  I've
never tested it the other way, where the serial timestamp "goes bad".


More information about the questions mailing list