Leap second hangover? - NTP

This is a discussion on Leap second hangover? - NTP ; Two of my PCs have show a great NTP instability since 0000UTC this morning, just like the events which happened on January 1st after the leap second insertion. Please see: http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html At 06:00 UTC I restarted the NTP servers on ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Leap second hangover?

  1. Leap second hangover?

    Two of my PCs have show a great NTP instability since 0000UTC this
    morning, just like the events which happened on January 1st after the leap
    second insertion. Please see:

    http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

    At 06:00 UTC I restarted the NTP servers on those systems (Bacchus and
    Stamsund), rewriting the ntp.drift file with a known good value for the
    PCs in question.

    Unfortunately, I didn't note which servers (in addition to my own simple
    stratum 1 server - Pixie) those PC were clients to, but you may want to
    look out for this behaviour in your own systems. The fact three PCs
    showed no problem at all rules out (I hope) the client software I am using
    (Meinberg Xmas build for Windows).

    If there are any specific diagnostics I should run, please let me know.

    David



  2. Re: Leap second hangover?


    "David J Taylor" wrote:

    > Two of my PCs have show a great NTP instability since 0000UTC this
    > morning, just like the events which happened on January 1st after the leap
    > second insertion. Please see:
    >
    > http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html
    >
    > At 06:00 UTC I restarted the NTP servers on those systems (Bacchus and
    > Stamsund), rewriting the ntp.drift file with a known good value for the
    > PCs in question.
    >
    > Unfortunately, I didn't note which servers (in addition to my own simple
    > stratum 1 server - Pixie) those PC were clients to,


    A change of a syspeer is probably recorded in the Eventlog/Application.

    Karel Sandler



  3. Re: Leap second hangover?

    Karel Sandler wrote:
    > "David J Taylor" wrote:
    >
    >> Two of my PCs have show a great NTP instability since 0000UTC this
    >> morning, just like the events which happened on January 1st after
    >> the leap second insertion. Please see:
    >>
    >> http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html
    >>
    >> At 06:00 UTC I restarted the NTP servers on those systems (Bacchus
    >> and Stamsund), rewriting the ntp.drift file with a known good value
    >> for the PCs in question.
    >>
    >> Unfortunately, I didn't note which servers (in addition to my own
    >> simple stratum 1 server - Pixie) those PC were clients to,

    >
    > A change of a syspeer is probably recorded in the
    > Eventlog/Application.
    > Karel Sandler


    Thanks - they are indeed recorded there.

    On both problem PCs, at 01:00 a positive leap second is inserted. Arrgh!

    Now the announcement wasn't coming from my own stratum 1 server (at least
    I hope it wasn't, as not all client PCs were affected).

    On PC Bacchus, a positive leap second was detected by NTP at 09:10 (clock)
    on June 06, the event log does not show which server provided this duff
    information. The NTP on that server was restarted on March 04 and was
    using NTP UK pool servers, plus ntp2c.mcc.ac.uk.

    On PC Stamsund, a positive leap second was detected by NTP at 09:17
    (clock) on June 6. Its servers included UK pool servers, and 130.88.200.6
    (utserv.mcc.ac.uk).

    [Suggestion to the developers: log which server suggested the leap-second]

    [Suggestion to the developers: provide some sort of "majority vote
    required" before a leap-second is actually inserted]

    All my systems are using the server ntp2c.mcc.ac.uk, so I presume that is
    not is sending out the spurious message. How can I find out if a server
    is sending out a leap-second required message? I can only assume
    something in the UK pool of servers was incorrectly sending the
    leap-second message, and may still be.

    [Suggestion to NTP pool maintainers: list erroneous servers like this if
    possible]

    Cheers,
    David



  4. Re: Leap second hangover?

    "David J Taylor" writes:

    >On both problem PCs, at 01:00 a positive leap second is inserted. Arrgh!


    Interesting stuff - after the last leapsecond there were stuff
    public time servers advertising a pending leapsecond 12 hours later.
    Evidently there were some still advertising it a whole 6 months
    later!

    >All my systems are using the server ntp2c.mcc.ac.uk, so I presume that is
    >not is sending out the spurious message. How can I find out if a server
    >is sending out a leap-second required message? I can only assume
    >something in the UK pool of servers was incorrectly sending the
    >leap-second message, and may still be.


    You can see the leap bits by doing something like:

    ntpq -c rv localhost

    (replace localhost with the name of the host you want to query)
    and look for the "leap=" value. It should be "00" at the moment.
    I used this to produce the graph at:

    http://www.maths.tcd.ie/~dwmalone/ti...ml#ntpleapflag

    It would be interesting to survey the pool servers and see which
    are advertising a leap second.

    David.

  5. Re: Leap second hangover?

    David Malone wrote:
    > "David J Taylor"
    > writes:
    >
    >> On both problem PCs, at 01:00 a positive leap second is inserted.
    >> Arrgh!

    >
    > Interesting stuff - after the last leapsecond there were stuff
    > public time servers advertising a pending leapsecond 12 hours later.
    > Evidently there were some still advertising it a whole 6 months
    > later!
    >
    >> All my systems are using the server ntp2c.mcc.ac.uk, so I presume
    >> that is not is sending out the spurious message. How can I find out
    >> if a server is sending out a leap-second required message? I can
    >> only assume something in the UK pool of servers was incorrectly
    >> sending the leap-second message, and may still be.

    >
    > You can see the leap bits by doing something like:
    >
    > ntpq -c rv localhost
    >
    > (replace localhost with the name of the host you want to query)
    > and look for the "leap=" value. It should be "00" at the moment.
    > I used this to produce the graph at:
    >
    > http://www.maths.tcd.ie/~dwmalone/ti...ml#ntpleapflag
    >
    > It would be interesting to survey the pool servers and see which
    > are advertising a leap second.
    >
    > David.


    Thanks, David. Well, I can see that neither Manchester not my simple
    stratum-1 server is advertsing leap-seconds. Persumably some in the UK
    pool still are (or were).

    Perhaps you can use your program to check?

    Cheers,
    David



  6. Re: Leap second hangover?

    "David J Taylor" writes:

    >Thanks, David. Well, I can see that neither Manchester not my simple
    >stratum-1 server is advertsing leap-seconds. Persumably some in the UK
    >pool still are (or were).


    >Perhaps you can use your program to check?


    Sure - I queried a few servers and found 19 machines in uk.pool.ntp.org.
    They won't all answer the "rv" query, so I found that some versions
    of ntpdate will print out the leap bits, and all the servers will
    answer ntpdate queries with the "-d" flag. It seems none of them
    have the leap bits set now.

    David.

    === 131.111.226.25 ===
    stratum 3, precision -17, leap 00, trust 000
    === 195.137.27.138 ===
    stratum 2, precision -16, leap 00, trust 000
    === 195.224.39.103 ===
    stratum 3, precision -19, leap 00, trust 000
    === 212.159.114.45 ===
    stratum 3, precision -16, leap 00, trust 000
    === 213.2.4.70 ===
    stratum 4, precision -20, leap 00, trust 000
    === 213.2.4.80 ===
    stratum 3, precision -16, leap 00, trust 000
    === 217.155.3.202 ===
    stratum 2, precision -18, leap 00, trust 000
    === 217.174.250.58 ===
    stratum 2, precision -18, leap 00, trust 000
    === 217.31.136.10 ===
    stratum 3, precision -19, leap 00, trust 000
    === 81.187.221.26 ===
    stratum 3, precision -20, leap 00, trust 000
    === 81.187.65.110 ===
    stratum 2, precision -14, leap 00, trust 000
    === 81.2.102.154 ===
    stratum 3, precision -19, leap 00, trust 000
    === 81.5.136.18 ===
    stratum 3, precision -20, leap 00, trust 000
    === 82.133.58.132 ===
    stratum 2, precision -20, leap 00, trust 000
    === 82.152.150.47 ===
    stratum 2, precision -19, leap 00, trust 000
    === 82.68.126.114 ===
    stratum 2, precision -20, leap 00, trust 000
    === 83.138.191.59 ===
    stratum 2, precision -20, leap 00, trust 000
    === 83.67.64.230 ===
    stratum 3, precision -20, leap 00, trust 000
    === 87.75.128.50 ===
    stratum 2, precision -20, leap 00, trust 000


  7. Re: Leap second hangover?

    David Malone wrote:
    > "David J Taylor"
    > writes:
    >
    >> Thanks, David. Well, I can see that neither Manchester not my simple
    >> stratum-1 server is advertsing leap-seconds. Persumably some in the
    >> UK pool still are (or were).

    >
    >> Perhaps you can use your program to check?

    >
    > Sure - I queried a few servers and found 19 machines in
    > uk.pool.ntp.org.
    > They won't all answer the "rv" query, so I found that some versions
    > of ntpdate will print out the leap bits, and all the servers will
    > answer ntpdate queries with the "-d" flag. It seems none of them
    > have the leap bits set now.
    >
    > David.
    >
    > === 131.111.226.25 ===
    > stratum 3, precision -17, leap 00, trust 000

    [rest of list cut]

    Oh, many thanks for that, David

    I hope the pool managers will take note and check that this doesn't happen
    next time!

    I was surprised that no-one else reported the problem....

    Cheers,
    David



  8. Re: Leap second hangover?

    "David J Taylor" wrote:

    >>> Two of my PCs have show a great NTP instability since 0000UTC this
    >>> morning, just like the events which happened on January 1st after
    >>> the leap second insertion. Please see:
    >>>
    >>> http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html


    > On both problem PCs, at 01:00 a positive leap second is inserted. Arrgh!
    >
    > Now the announcement wasn't coming from my own stratum 1 server (at least
    > I hope it wasn't, as not all client PCs were affected).
    >
    > On PC Bacchus, a positive leap second was detected by NTP at 09:10 (clock)
    > on June 06, the event log does not show which server provided this duff
    > information. The NTP on that server was restarted on March 04 and was
    > using NTP UK pool servers, plus ntp2c.mcc.ac.uk.
    >
    > On PC Stamsund, a positive leap second was detected by NTP at 09:17
    > (clock) on June 6. Its servers included UK pool servers, and 130.88.200.6
    > (utserv.mcc.ac.uk).
    >
    > [Suggestion to the developers: log which server suggested the leap-second]
    >
    > [Suggestion to the developers: provide some sort of "majority vote
    > required" before a leap-second is actually inserted]
    >
    > All my systems are using the server ntp2c.mcc.ac.uk, so I presume that is
    > not is sending out the spurious message. How can I find out if a server
    > is sending out a leap-second required message? I can only assume
    > something in the UK pool of servers was incorrectly sending the
    > leap-second message, and may still be.
    >
    > [Suggestion to NTP pool maintainers: list erroneous servers like this if
    > possible]


    According to the www.pool.ntp.org there are 57 UK servers today. All these
    servers (3 S1, 32 S2, 20 S3 and 2 S4) have 'leap 00' (at Jul 1 23:36 UTC)
    and all those three S1 were OK according to the pool scores. But - one more
    server (S1) has been there until Jul 1 03 AM UTC.
    Maybe, don't know.

    Karel Sandler



  9. Re: Leap second hangover?

    Karel Sandler wrote:
    []
    > According to the www.pool.ntp.org there are 57 UK servers today. All
    > these servers (3 S1, 32 S2, 20 S3 and 2 S4) have 'leap 00' (at Jul 1
    > 23:36 UTC) and all those three S1 were OK according to the pool
    > scores. But - one more server (S1) has been there until Jul 1 03 AM
    > UTC. Maybe, don't know.
    >
    > Karel Sandler


    Thanks for that information, Karel. I've added it to my small write-up of
    the July 2006 glitch!

    http://www.david-taylor.myby.co.uk/n...htm#2006-07-01

    Am I the only person who saw this problem?

    Cheers,
    David



  10. Re: Leap second hangover?

    On 2006-07-02, David J Taylor wrote:
    > Karel Sandler wrote:
    > []
    >> According to the www.pool.ntp.org there are 57 UK servers today. All
    >> these servers (3 S1, 32 S2, 20 S3 and 2 S4) have 'leap 00' (at Jul 1
    >> 23:36 UTC) and all those three S1 were OK according to the pool
    >> scores. But - one more server (S1) has been there until Jul 1 03 AM
    >> UTC. Maybe, don't know.
    >>
    >> Karel Sandler

    >
    > Thanks for that information, Karel. I've added it to my small write-up of
    > the July 2006 glitch!
    >
    > http://www.david-taylor.myby.co.uk/n...htm#2006-07-01
    >
    > Am I the only person who saw this problem?


    No. I saw it on two of my machines. On one on June30 23:59:60 UTC, on
    the other also a day later.

    [UTC+0200]
    Jul 1 01:59:59 asteria kernel: Clock: inserting leap second 23:59:60 UTC

    [UTC+0000]
    Jun 30 23:59:59 blackhole kernel: [22210173.960000] Clock: inserting leap second 23:59:60 UTC
    Jul 1 23:59:59 blackhole kernel: [22296576.700000] Clock: inserting leap second 23:59:60 UTC

    Cheers,
    Peter

  11. Re: Leap second hangover?

    Peter Palfrader writes:

    >No. I saw it on two of my machines. On one on June30 23:59:60 UTC, on
    >the other also a day later.


    If you haven't reset your machine since, could you get a list of peers
    with "ntpq -p" on both machines. This should help narrow down the machine
    that introduced the eap second.

    David.

  12. Re: Leap second hangover?

    On 2006-07-02, David Malone wrote:
    >>No. I saw it on two of my machines. On one on June30 23:59:60 UTC, on
    >>the other also a day later.

    >
    > If you haven't reset your machine since, could you get a list of peers
    > with "ntpq -p" on both machines. This should help narrow down the machine
    > that introduced the eap second.


    Certainly.

    [new-bh] blackhole:~# ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    -asteria.debian. 130.149.17.21 2 u 642 1024 377 18.009 2.776 0.121
    -nsa1.sil.at 193.10.7.250 2 u 704 1024 377 14.995 6.124 4.247
    +svr2.m-online.n 130.149.17.21 2 u 659 1024 377 18.710 -0.859 0.085
    *svr1.m-online.n 212.18.1.106 2 u 718 1024 377 18.428 -0.938 0.414
    -rainbow.bksys.a 192.53.103.108 2 u 655 1024 377 52.223 -15.817 5.789
    -salukes.opensou 80.127.4.179 2 u 711 1024 377 138.165 -50.134 3.140
    +thales.ham.nw.s 130.149.17.21 2 u 659 1024 377 10.074 1.278 0.126
    -20six.fr 172.20.20.34 3 u 660 1024 377 7.475 28.472 1.658
    LOCAL(0) LOCAL(0) 13 l 43 64 377 0.000 0.000 0.002

    There's also http://asteria.noreply.org/~weasel/b....oftc.net.html
    which shows the ntp statistics for each peer of blackhole. 20six.fr looks a
    bit suspicous.


    weasel@asteria:~$ ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    -simi.came.sbg.a 130.149.17.8 2 u 1022 1024 377 8.701 0.708 0.900
    -rainbow.bksys.a 192.53.103.108 2 u 24 1024 377 8.473 -3.722 0.814
    -pluto.fips.at 130.149.17.21 2 u 738 1024 377 0.717 -1.178 0.099
    -hostmaster.org 192.53.103.104 2 u 750 1024 377 7.849 -0.146 0.051
    BGSZ040.kfunigr .STEP. 16 u - 1024 0 0.000 0.000 4000.00
    -trane.wu-wien.a 195.13.1.153 3 u 771 1024 377 2.104 -5.848 0.478
    -salukes.opensou 80.127.4.179 2 u 748 1024 377 24.197 3.723 0.101
    -thales.ham.nw.s 130.149.17.21 2 u 750 1024 377 23.021 -2.133 0.089
    -20six.fr 172.20.20.34 3 u 526 1024 377 14.665 27.655 1.914
    +chronos.zedat.f 193.63.105.18 2 u 767 1024 377 24.899 -0.594 0.232
    -ntps1-0.cs.tu-b .PPS. 1 u 10 1024 377 27.712 -0.126 0.325
    +ntps1-1.cs.tu-b .PPS. 1 u 939 1024 377 26.699 -0.801 0.375
    +ntp1.ien.it .IEN. 1 u 621 1024 377 32.962 -0.314 0.255
    +ntp2.ien.it .IEN. 1 u 727 1024 377 31.800 -0.775 0.344
    -ptbtime1.ptb.de .PTB. 1 u 745 1024 377 20.868 -1.392 0.047
    *ptbtime2.ptb.de .PTB. 1 u 63 1024 377 20.052 -0.499 0.265
    -bandit.probe-ne .DCFa. 1 u 745 1024 377 13.700 18.735 0.409
    -212-82-32-15.ip .PPS. 1 u 747 1024 377 24.359 -1.410 0.085
    -rustime01.rus.u .DCFp. 1 u 784 1024 377 17.898 -1.528 0.005
    -nsa1.sil.at 193.10.7.250 2 u 737 1024 377 9.988 9.448 4.304
    -mammut.cosy.sbg 213.84.251.124 3 u 747 1024 377 5.602 -1.225 0.840
    -svr2.m-online.n 130.149.17.21 2 u 752 1024 377 15.144 3.226 0.006
    -svr1.m-online.n 212.18.1.106 2 u 739 1024 377 14.973 3.229 0.236
    LOCAL(0) LOCAL(0) 13 l 65 64 377 0.000 0.000 0.004
    [Yes, I should clean this one up one of these days]

    Cheers,
    Peter

  13. Re: Leap second hangover?

    Peter Palfrader writes:

    >There's also http://asteria.noreply.org/~weasel/b....oftc.net.html
    >which shows the ntp statistics for each peer of blackhole. 20six.fr looks a
    >bit suspicous.


    It definitely looks like a candidate - both your machines also peer
    with it and it looks like it was one second off for much of yesterday.

    David.

  14. Re: Leap second hangover?

    David J Taylor wrote:

    > Karel Sandler wrote:
    > []
    >> According to the www.pool.ntp.org there are 57 UK servers today. All
    >> these servers (3 S1, 32 S2, 20 S3 and 2 S4) have 'leap 00' (at Jul 1
    >> 23:36 UTC) and all those three S1 were OK according to the pool
    >> scores. But - one more server (S1) has been there until Jul 1 03 AM
    >> UTC. Maybe, don't know.
    >>
    >> Karel Sandler

    >
    > Thanks for that information, Karel. I've added it to my small write-up of
    > the July 2006 glitch!
    >
    > http://www.david-taylor.myby.co.uk/n...htm#2006-07-01
    >
    > Am I the only person who saw this problem?


    I?m seeing intermittent problems using DCF77 receivers (Tobit Timelan) and
    leap seconds. Sometimes leap_add_sec ist set in lower strata, dunno why and
    when it is set. Will capture the packets from (and make a ntpq -crv on) the
    DCF77 boxes and will see when it will happen. Finding out 'why' will be a
    little difficult for me.

    Cheers

    Markus

+ Reply to Thread