[ntp:questions] Spurious positive leap second announcement?

Martin Burnicki martin.burnicki at meinberg.de
Wed Mar 7 12:32:47 UTC 2007


Marc,

Marc Brett wrote:
> On Wed, 07 Mar 2007 10:01:02 +0100, Martin Burnicki
> <martin.burnicki at meinberg.de> wrote:
> 
>>So if none of the upstream servers sends the announcement anymore, the
>>local ntpd just seems to "forget" the announcement it has seen before.
>>However, I'll have a closer look at this.
> 
> This is partly because of the ambiguity of the NTP leap bits.  leap=00
> means either "no leap at next available opportunity" or "don't know" and
> the client
> has no way of knowing what to do if it's fed both 0s and 1s.  Is there
> definitely a leap-second event on the way but one server doesn't know
> about it yet, or are the two servers positively contradicting each other?

I think unless the time of an upstream source jumps due to a leap second
which has not been announced by that upstream source, it makes no
difference for ntpd whether it is just not aware of an upcoming leap
second, or there is no leap second scheduled.

The current NTP code just accepts a leap second announcement if any of the
cluster of upstream servers forwards such announcement, and if the
announcement is there at the time when the leap second may be inserted then
it is just inserted. 

The question here is what happens if a (faulty) announcement is temporarily
there at a time when no leap second could be scheduled, and the
announcement has already disappeared at the next possible time for a leap
second.

[...]
> I wish the GPS operators would flag for upcoming leap-seconds no more than
> 3 months in advance of the event, in order to prevent just this sort of
> ambiguity. 

This is not a problem of the GPS operators. The UTC parameters sent by the
GPS satellites include the UTC offset before a leap second, the new UTC
offset after that leap second, plus a (8 bit truncated) week number and day
number of that week at the end of which the leap second will be inserted.

This can be used by the GPS receiver's firmware to determine the exact date
when the leap second will be inserted. The interval for which an
unambiguous announcement of a leap second is possible is +/- 128 weeks. 

In the past, the GPS satellites started to announce an upcoming leap second
event shortly after it had been announced by the IERS, i.e. less than half
a year (26 weeks) before the event.

So it is just a problem of the GPS receiver firmware developers who do not
evaluate the available information carefully enough.

> I don't know of any GPS receiver which outputs the date/time of 
> the next leap
> second event; all they ever do is raise a binary flag.  If the GPS signal
> in space says, in February, that the next leap second is at 24:00 30 June,
> the
> receivers all dumb-down the message to "leap second on the way".  The poor
> user is left to guess whether it's in March or June.

If you run a Meinberg GPS connected via serial port (using the parse driver;
thanks, Frank) then ntpq's "clockvars" command may help:

# ntpq -c "cv 879"
assID=879 status=0001 clk_okay, last_clk_noreply,
device="Meinberg GPS16x receiver",
timecode="\x02D:07.03.07;T:3;U:13.19.21;    \x03", poll=72742,
[...]
gps_position(XYZ)="3885658.4 m, 631132.7 m, 5001776.8 m",
gps_position(LLA)="51.9829 deg, 9.2258 deg, 189.0 m",
meinberg_gps_version="4.46                 ",
meinberg_gps_status="[0x0000] <OK>",
gps_utc_correction="current correction 14 sec, last correction on
c7619a00.00000000  Sun, Jan  1 2006  0:00:00.000",
gps_message="31CCK7JL15L1R/VTX/TA90"

Please see the "gps_utc_correction" value.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list