Marc, Marc Brett wrote: > On Wed, 07 Mar 2007 10:01:02 +0100, Martin Burnicki > <[EMAIL PROTECTED]> 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
