[ntp:questions] Re: Z3801 Leapsecond bug - Sep 30?
martin.burnicki at meinberg.de
Tue Aug 30 10:52:20 UTC 2005
shoppa at trailing-edge.com wrote:
> My Z3801A on the :SYSTEM:STATUS? page knows that a leapsecond is
> coming up. The "+1 leapsecond pending" shows this. This leapsecond
> was announced this summer, and according to all the announcements it's
> an extra second at the end of the year, i.e. Dec 31 2005.
> But if I ask further about the date and time of the leapsecond, I get:
> This is the last day of September. (I realize that not everyone may
> hex GPS time like me, so I also used the undocumented command that
> shows the date in year, month, day.) I understand that while
> have never been issued other than the end of the year or halfway
> the year, that the protocol allows them to be at the end of March and
> September as well, and that the GPS protocol may not identify the date
> of the leapsecond uniuely enough.
The GPS data set for the UTC correction contains the time of the next leap
second coded as the 8 LSBs of the GPS week number, plus the day number in
that week at the end of which the leap second will occur.
In former times there have been leap seconds about once every 1.5 years, but
the upcoming leap second is the first one after January 1999. This time
interval since then exceeds the range of +/-128 weeks that could be handled
properly by the truncated 8 bit week number value.
Additionally, in the meantime there has also been the GPS 10 bit week number
rollover from 1023 to 0, so the GPS receiver's firmware may have got
confused relating the week numbers to each other, and converting the GPS
leap second parameter into human readable date.
Depending on the way the firmware evaluates those parameters internally this
may or may not introduce an additional second at the end of September.
> I'm a stratum-1 NTP server, and I guess I'll stop using the Z3801A
> and go back to something that is more reliable, like WWV audio, until I
> this figured out. Maybe the Z3801A will be off by one second from
> September 30 onwards, and maybe this is fixable by a "reboot" of the
> Z3801A? Would seem a shame, mine has about two years of uptime
> at this point...
The GPS data set also contains the number of seconds between UTC and GPS
time before and after that leap second (currently 32 and 33). In the past,
the satellites had started to transmit the recent value (33 in this case)
for both of those parameters shortly after the leap second really had
So if your receiver should output the time 1 second off after September 30,
there's a chance that it will start to work correctly again in January
> I suppose this could even interrupt oscillator discipline and 10MHz
> output, although I hope that these are keyed entirely off the PPS and
> ignore the other stuff. Being off by 1 second would require a slew
> of 10 million oscillator cycles... wow will that require a big long
> change in EFC!
Maybe it does not affect those because assumably the firmware internally
computes using the GPS time (GPS week number and second of the week). I'd
expect the error to come in the time shall be output, i.e. the GPS time is
converted to UTC and/or local time, and the wrong number of seconds offset
Since the offset is exactly 1 second, the PPS should not be affected. Maybe
you can just disconnect the receiver from the NTP server and see what it's
doing after September 30. If it's really 1 second off, you might be able to
configure a "fudge time1" value for the receiver in ntp.conf (depending on
the driver you're using) until December.
> Is there a fix for this bug, maybe new firmware from HP? How did the
> bug happen, by announcing a leapsecond more than three months in
> advance maybe?
It's definitely a firmware bug where the truncated week numbers aren't
handled correctly. You should try to contact HP for a firmware update,
More information about the questions