Spurious positive leap second announcement? - NTP

This is a discussion on Spurious positive leap second announcement? - NTP ; Noted this in my even log: Detected positive leap second announcement for 2007-04-01 00:00:00 UTC ntpq -p gives: Remote refid -pie.crustynet.o 130.88.202.49 +194.153.168.75 195.66.241.3 +utserv.mcc.ac.u 193.62.22.98 -linnaeus.inf.ed 129.215.64.243 Perhaps one of these servers has a problem? Cheers, David...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Spurious positive leap second announcement?

  1. Spurious positive leap second announcement?

    Noted this in my even log:

    Detected positive leap second announcement for 2007-04-01 00:00:00 UTC

    ntpq -p gives:

    Remote refid

    -pie.crustynet.o 130.88.202.49
    +194.153.168.75 195.66.241.3
    +utserv.mcc.ac.u 193.62.22.98
    -linnaeus.inf.ed 129.215.64.243

    Perhaps one of these servers has a problem?

    Cheers,
    David



  2. Re: Spurious positive leap second announcement?

    David J Taylor wrote:
    > Noted this in my event log:
    >
    > Detected positive leap second announcement for 2007-04-01 00:00:00 UTC
    >
    > ntpq -p gives:
    >
    > Remote refid
    >
    > -pie.crustynet.o 130.88.202.49
    > +194.153.168.75 195.66.241.3
    > +utserv.mcc.ac.u 193.62.22.98
    > -linnaeus.inf.ed 129.215.64.243
    >
    > Perhaps one of these servers has a problem?
    >
    > Cheers,
    > David


    Oh, and if someone could remind which NTPQ command will show the full
    addresses, please?

    The first two servers are pool, IIRC. The servers I know are:
    utserv.mcc.ac.uk
    linnaeus.inf.ed.ac.uk

    Thanks,
    David



  3. Re: Spurious positive leap second announcement?

    On 2007-03-06, David J Taylor wrote:

    > Noted this in my even log:
    >
    > Detected positive leap second announcement for 2007-04-01 00:00:00 UTC


    If you wish to see the leap variable for each of those servers:

    1. 'ntpq -cas your_time_server' to get the list of association numbers

    2. 'ntpq -c"rv Assn# leap" your_time_server' for each association number

    I used this "one-liner" (in bash) to check all of the ntpds on my LAN:

    for H in space_delimited_list_of_hostnames ; do for P in `ntpq -cas $H | \
    awk 'OK==1 { print $2} /=/ { OK = 1 }'`; do echo -n "$H - $P: "; \
    ntpq -c"rv $P leap" $H | tail -n 1; done; done

    BTW: The USNO "When Does Daylight Time Begin and End?" is at
    http://aa.usno.navy.mil/faq/docs/daylight_time.html

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  4. Re: Spurious positive leap second announcement?

    Steve Kostecke wrote:
    > On 2007-03-06, David J Taylor wrote:
    >
    >> Noted this in my even log:
    >>
    >> Detected positive leap second announcement for 2007-04-01 00:00:00
    >> UTC

    >
    > If you wish to see the leap variable for each of those servers:
    >
    > 1. 'ntpq -cas your_time_server' to get the list of association numbers
    >
    > 2. 'ntpq -c"rv Assn# leap" your_time_server' for each association
    > number
    >
    > I used this "one-liner" (in bash) to check all of the ntpds on my LAN:
    >
    > for H in space_delimited_list_of_hostnames ; do for P in `ntpq -cas
    > $H | \ awk 'OK==1 { print $2} /=/ { OK = 1 }'`; do echo -n "$H - $P:
    > "; \
    > ntpq -c"rv $P leap" $H | tail -n 1; done; done
    >
    > BTW: The USNO "When Does Daylight Time Begin and End?" is at
    > http://aa.usno.navy.mil/faq/docs/daylight_time.html


    Thanks, Steve. I used a simpler script (fixed association numbers) and
    got this:

    -------------------------------------------------------------
    C:\Tests>for /L %S IN (53081 1 53085) DO (ntpq -c"rv %S leap" )

    C:\Tests>(ntpq -c"rv 53081 leap" )
    assID=53081 status=9624 reach, conf, sel_sys.peer, 2 events, event_reach,
    leap=00

    C:\Tests>(ntpq -c"rv 53082 leap" )
    assID=53082 status=9424 reach, conf, sel_candidat, 2 events, event_reach,
    leap=00

    C:\Tests>(ntpq -c"rv 53083 leap" )
    assID=53083 status=9424 reach, conf, sel_candidat, 2 events, event_reach,
    leap=00

    C:\Tests>(ntpq -c"rv 53084 leap" )
    assID=53084 status=9424 reach, conf, sel_candidat, 2 events, event_reach,
    leap=00

    C:\Tests>(ntpq -c"rv 53085 leap" )
    assID=53085 status=9324 reach, conf, sel_outlyer, 2 events, event_reach,
    leap=00

    C:\Tests>
    -------------------------------------------------------------

    As these all show leap=00, does this mean that the errant server has now
    been corrected? How can I find out if my own ntp client will try to
    insert a leap second or not?


    -------------------------------------------------------------
    C:\Tests>ntpq -c rv
    assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
    version="ntpd 4.2.0b@1.1436-mbg-o Dec 22 12:23:10 (UTC+01:00) 2005 (1)",
    processor="unknown", system="WINDOWS/NT", leap=00, stratum=2,
    precision=-23, rootdelay=1.335, rootdispersion=36.490, peer=53081,
    refid=192.168.0.3,
    reftime=c997fc41.b1374d63 Tue, Mar 6 2007 14:42:09.692, poll=8,
    clock=c998021e.08b0448a Tue, Mar 6 2007 15:07:10.033, state=4,
    offset=4.463, frequency=12.740, jitter=0.467, noise=1.086,
    stability=0.035, tai=0
    -------------------------------------------------------------

    Does leap_none look good?

    Thanks,
    David



  5. Re: Spurious positive leap second announcement?

    David J Taylor wrote:

    > Oh, and if someone could remind which NTPQ command will show the full
    > addresses, please?


    ntpq -np will display the unresolved addresses for the remote time
    servers

    ntpdc -clis will display the complete hostnames of the remote time
    servers

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  6. Re: Spurious positive leap second announcement?


    "David J Taylor"
    wrote in message news:OXdHh.13842$I46.13691@text.news.blueyonder.co .uk...
    > Noted this in my even log:
    >
    > Detected positive leap second announcement for 2007-04-01 00:00:00 UTC
    >
    > ntpq -p gives:
    >
    > Remote refid
    >
    > -pie.crustynet.o 130.88.202.49
    > +194.153.168.75 195.66.241.3
    > +utserv.mcc.ac.u 193.62.22.98
    > -linnaeus.inf.ed 129.215.64.243
    >
    > Perhaps one of these servers has a problem?
    >
    > Cheers,
    > David
    >
    >

    2007-04-01? Sounds like someone's idea of an April Fools' joke.

    Barring that, it could be a test of their system's implementation of leap
    seconds.


    Brian



  7. Re: Spurious positive leap second announcement?

    On 2007-03-06, Brian Garrett wrote:

    > "David J Taylor" wrote:
    >
    >> Noted this in my even log:
    >>
    >> Detected positive leap second announcement for 2007-04-01 00:00:00 UTC

    >
    > 2007-04-01? Sounds like someone's idea of an April Fools' joke.


    That server was probably still using the old zonefile. Here's what an
    old zonefile shows for 2007:

    localhost:/usr/share/zoneinfo$ /usr/sbin/zdump -v EST5EDT.orig | grep 2007
    Sun Apr 1 06:59:59 2007 GMT = Sun Apr 1 01:59:59 2007 EST isdst=0
    Sun Apr 1 07:00:00 2007 GMT = Sun Apr 1 03:00:00 2007 EDT isdst=1
    Sun Oct 28 05:59:59 2007 GMT = Sun Oct 28 01:59:59 2007 EDT isdst=1
    Sun Oct 28 06:00:00 2007 GMT = Sun Oct 28 01:00:00 2007 EST isdst=0

    Here's the updated version of that zonefile:

    localhost:/usr/share/zoneinfo$ /usr/sbin/zdump -v EST5EDT | grep 2007
    Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  8. Re: Spurious positive leap second announcement?

    In article Steve Kostecke
    writes:
    >On 2007-03-06, Brian Garrett wrote:
    >
    >> "David J Taylor" wrote:
    >>
    >>> Noted this in my even log:
    >>>
    >>> Detected positive leap second announcement for 2007-04-01 00:00:00 UTC

    >>
    >> 2007-04-01? Sounds like someone's idea of an April Fools' joke.

    >
    >That server was probably still using the old zonefile. Here's what an
    >old zonefile shows for 2007:
    >
    >localhost:/usr/share/zoneinfo$ /usr/sbin/zdump -v EST5EDT.orig | grep 2007
    >Sun Apr 1 06:59:59 2007 GMT = Sun Apr 1 01:59:59 2007 EST isdst=0
    >Sun Apr 1 07:00:00 2007 GMT = Sun Apr 1 03:00:00 2007 EDT isdst=1
    >Sun Oct 28 05:59:59 2007 GMT = Sun Oct 28 01:59:59 2007 EDT isdst=1
    >Sun Oct 28 06:00:00 2007 GMT = Sun Oct 28 01:00:00 2007 EST isdst=0


    Uh, asleep at the wheel?:-)

    --Per Hedeland
    per@hedeland.org

  9. Re: Spurious positive leap second announcement?

    Steve Kostecke wrote:
    > On 2007-03-06, Brian Garrett wrote:
    >
    >> "David J Taylor" wrote:
    >>
    >>> Noted this in my even log:
    >>>
    >>> Detected positive leap second announcement for 2007-04-01 00:00:00
    >>> UTC

    >>
    >> 2007-04-01? Sounds like someone's idea of an April Fools' joke.

    >
    > That server was probably still using the old zonefile. Here's what an
    > old zonefile shows for 2007:
    >
    > localhost:/usr/share/zoneinfo$ /usr/sbin/zdump -v EST5EDT.orig | grep
    > 2007 Sun Apr 1 06:59:59 2007 GMT = Sun Apr 1 01:59:59 2007 EST
    > isdst=0
    > Sun Apr 1 07:00:00 2007 GMT = Sun Apr 1 03:00:00 2007 EDT isdst=1
    > Sun Oct 28 05:59:59 2007 GMT = Sun Oct 28 01:59:59 2007 EDT isdst=1
    > Sun Oct 28 06:00:00 2007 GMT = Sun Oct 28 01:00:00 2007 EST isdst=0
    >
    > Here's the updated version of that zonefile:
    >
    > localhost:/usr/share/zoneinfo$ /usr/sbin/zdump -v EST5EDT | grep 2007
    > Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST isdst=0
    > Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT isdst=1
    > Sun Nov 4 05:59:59 2007 GMT = Sun Nov 4 01:59:59 2007 EDT isdst=1
    > Sun Nov 4 06:00:00 2007 GMT = Sun Nov 4 01:00:00 2007 EST isdst=0


    Thanks, Steve, but to the best of my knowledge there is no zone file on
    the client PC (running Windows). If it's the server problem, then it's
    outside my control.

    In any case, why would a time zone file create a leap-second annoucement?
    I thought that they were two different things.

    How can I tell if this PC will try to insert a leap second or not?

    Thanks,
    David



  10. Re: Spurious positive leap second announcement?

    >>> Noted this in my even log:
    >>>
    >>> Detected positive leap second announcement for 2007-04-01 00:00:00 UTC

    >>
    >> 2007-04-01? Sounds like someone's idea of an April Fools' joke.

    >
    >That server was probably still using the old zonefile. Here's what an
    >old zonefile shows for 2007:


    How did we get from leap seconds to zone files?

    I can see that if we have a leap second coming up in early April
    there might be some confusion about when it happens in local time
    if the zone file hasn't been updated. But I haven't seen
    any comments about a leap second coming soon. Did I miss
    something?
    --
    These are my opinions, not necessarily my employer's. I hate spam.


  11. Re: Spurious positive leap second announcement?

    Hi all,

    David J Taylor wrote:
    > Noted this in my even log:
    >
    > Detected positive leap second announcement for 2007-04-01 00:00:00 UTC


    This message comes from the Windows-specific code which handles leap second
    announcements received from the NTP kernel, so it will not be displayed in
    non-Windows versions of ntpd.

    The NTP kernel seems to have received such an announcement from one of its
    upstream servers and/or refclocks. However, ntpq/ntpdc queries to those
    servers mentioned in a different posting shows that none of them had a leap
    second announcement at the time you sent the ntpq/ntpdc queries. So the
    announcement seems to have been cancelled at the upstream server in the
    meantime.

    I'm not quite sure how the leap second announcement is removed in your local
    ntpd. From what I've seen at a first look at the code (variable leap_next)
    the announcements are or'ed from the announcements of the upstram servers
    which survive the clustering.

    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.

    Please note that leap seconds have absolutely nothing to do with time zone
    settings or time zone files since leap seconds are inserted into the UTC
    time scale. Of course the local times just follow the leap second since
    they're generally just UTC time plus an offset of some hours.

    Basically, leap second might be added or subtracted at the end of any month,
    but preferably this should be done at the end of June or December, and if
    required at a shorter interval it should be at the end of March or
    September.

    I rememeber there have been invalid leap second announcements for end of
    September 2005 which came from a GPS receiver (not Meinberg ;-) which "saw"
    the leap second announcement from GPS for end of December, 2005, but did
    not evaluate the insertion date correctly.

    So end of March is also a candidate for faulty announcements, even though
    there's currently no pending leap second announcement.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  12. Re: Spurious positive leap second announcement?

    Martin Burnicki wrote:
    > Hi all,
    >
    > David J Taylor wrote:
    >> Noted this in my even log:
    >>
    >> Detected positive leap second announcement for 2007-04-01 00:00:00
    >> UTC

    []
    > 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.

    []
    > So end of March is also a candidate for faulty announcements, even
    > though there's currently no pending leap second announcement.
    >
    >
    > Martin


    Martin,

    Many thanks for your analysis. If NTP is capable of forgetting the false
    announcement, that's great. However, I would like to know how to confirm
    this on the particular system. Can anyone explain the significance of the
    "leap_none" in the output below?

    C:\>ntpq -c rv
    assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
    version="ntpd 4.2.0b@1.1436-mbg-o Dec 22 12:23:10 (UTC+01:00) 2005 (1)",
    processor="unknown", system="WINDOWS/NT", leap=00, stratum=2,
    precision=-23, rootdelay=1.395, rootdispersion=50.905, peer=53081,
    refid=192.168.0.3,
    reftime=c9991306.8c1ee90a Wed, Mar 7 2007 10:31:34.547, poll=10,
    clock=c99919a7.de0c922d Wed, Mar 7 2007 10:59:51.867, state=4,
    offset=7.139, frequency=11.194, jitter=0.583, noise=1.504,
    stability=0.046, tai=0

    C:\>

    Does "leap_none" tell me anything about the way this client will behave?
    I've tried searching but haven't found a simple, plain English
    explanation!

    Thanks,
    David




  13. Re: Spurious positive leap second announcement?

    On Wed, 07 Mar 2007 10:01:02 +0100, Martin Burnicki
    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?

    >Basically, leap second might be added or subtracted at the end of any month,
    >but preferably this should be done at the end of June or December, and if
    >required at a shorter interval it should be at the end of March or
    >September.
    >
    >I rememeber there have been invalid leap second announcements for end of
    >September 2005 which came from a GPS receiver (not Meinberg ;-) which "saw"
    >the leap second announcement from GPS for end of December, 2005, but did
    >not evaluate the insertion date correctly.
    >
    >So end of March is also a candidate for faulty announcements, even though
    >there's currently no pending leap second announcement.


    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.
    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.

    Any time lords willing to confront the US military on this?


  14. Re: Spurious positive leap second announcement?

    David,

    David J Taylor wrote:
    > Many thanks for your analysis. If NTP is capable of forgetting the false
    > announcement, that's great. However, I would like to know how to confirm
    > this on the particular system. Can anyone explain the significance of the
    > "leap_none" in the output below?
    >
    > C:\>ntpq -c rv
    > assID=0 status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
    > version="ntpd 4.2.0b@1.1436-mbg-o Dec 22 12:23:10 (UTC+01:00) 2005 (1)",
    > processor="unknown", system="WINDOWS/NT", leap=00, stratum=2,
    > precision=-23, rootdelay=1.395, rootdispersion=50.905, peer=53081,
    > refid=192.168.0.3,
    > reftime=c9991306.8c1ee90a Wed, Mar 7 2007 10:31:34.547, poll=10,
    > clock=c99919a7.de0c922d Wed, Mar 7 2007 10:59:51.867, state=4,
    > offset=7.139, frequency=11.194, jitter=0.583, noise=1.504,
    > stability=0.046, tai=0
    >
    > Does "leap_none" tell me anything about the way this client will behave?
    > I've tried searching but haven't found a simple, plain English
    > explanation!


    I'm not quite sure about this.

    Again, after just a quick look at this, there's a variable "leap_next" which
    is updated from the responses from the surviving upstream servers.

    If the corresponding flag is set in "leap_next" then the leap second
    announcement is also passed to the kernel to handle it (if kernel support
    is available) or it is evaluated by the specific leap second handler code
    in the Windows port.

    Occasionally, "leap_next" is copied to another variable "sys_leap" which is
    reported to ntpq queries.

    I've not yet had time to look at this closer.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  15. Re: Spurious positive leap second announcement?

    Marc,

    Marc Brett wrote:
    > On Wed, 07 Mar 2007 10:01:02 +0100, Martin Burnicki
    > 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] ",
    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

+ Reply to Thread