Leap second hangover?

Leap second hangover?

Post by David J Ta » Sun, 02 Jul 2006 15:53:04


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.yqcomputer.com/

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
 
 
 

Leap second hangover?

Post by Karel Sand » Sun, 02 Jul 2006 19:26:47


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

Karel Sandler

 
 
 

Leap second hangover?

Post by David J Ta » Sun, 02 Jul 2006 21:35:37


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
 
 
 

Leap second hangover?

Post by dwmalon » Sun, 02 Jul 2006 23:57:56

"David J Taylor" < XXXX@XXXXX.COM > writes:


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!


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.yqcomputer.com/ ~dwmalone/time/leap2005.html#ntpleapflag

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

David.
 
 
 

Leap second hangover?

Post by David J Ta » Mon, 03 Jul 2006 00:08:11


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
 
 
 

Leap second hangover?

Post by dwmalon » Mon, 03 Jul 2006 03:08:20

"David J Taylor" < XXXX@XXXXX.COM > writes:



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
 
 
 

Leap second hangover?

Post by David J Ta » Mon, 03 Jul 2006 04:22:46


[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
 
 
 

Leap second hangover?

Post by Karel Sand » Mon, 03 Jul 2006 09:49:22


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
 
 
 

Leap second hangover?

Post by David J Ta » Mon, 03 Jul 2006 15:57:23


[]

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

http://www.yqcomputer.com/ #2006-07-01

Am I the only person who saw this problem?

Cheers,
David
 
 
 

Leap second hangover?

Post by Peter Palf » Mon, 03 Jul 2006 19:53:20


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
 
 
 

Leap second hangover?

Post by dwmalon » Mon, 03 Jul 2006 19:59:42

Peter Palfrader < XXXX@XXXXX.COM > writes:


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.
 
 
 

Leap second hangover?

Post by Peter Palf » Mon, 03 Jul 2006 21:18:08

n 2006-07-02, David Malone < XXXX@XXXXX.COM > wrote:

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/bh-ntp/blackhole.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
 
 
 

Leap second hangover?

Post by dwmalon » Mon, 03 Jul 2006 21:52:39

Peter Palfrader < XXXX@XXXXX.COM > writes:


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.
 
 
 

Leap second hangover?

Post by Markus Reh » Tue, 04 Jul 2006 04:02:50


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