Subject: [ntpwg] leap second: definitions and DCF-77

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 16 Jun 2015 08:44:52 +0200

Hi!

I just found out that NTPv3 and NTPv4 use a different definition for the leap seconds announcement:

RFC 1305 (NTPv3) specifies:
"On the day prior to the insertion of a leap second the leap bits (sys.leap) are set at the primary servers" (page 52)
"Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day," (page 63)

RFC 5905 says: "LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9." (page 20)

So obviously NTPv4 allows the Leap Indicator (LI) to be set almost one month ahead, while NTPv3 requires LI to be set at most 24 hours before the event. So when using the definition of NTPv4, NTPv3 implementationy may misbehave, right?

As a matter of fact, DCF-77 is already announcing the leap second, and NTPv4 servers already announce it:

ntpq> cl
assID=0 status=0004 clk_okay, last_clk_badsignal,
device="Meinberg DCF PZF 535/509 / TCXO",
timecode="\x0216.06.15; 2; 08:32:09;    S   \x03", poll=109779,
noreply=0, badformat=0, baddata=0, fudgetime1=12.310, stratum=0,
refid=DCFp, flags=0,
refclock_time="d92a4169.00000000  Tue, Jun 16 2015  6:32:09.000",
refclock_status="DST; TIME CODE; (LEAP INDICATION; ANTENNA)",
refclock_format="Meinberg Standard",
refclock_states="*NOMINAL: 81d+16:15:38 (99.64%); FAULT: 03:07:47 (0.15%); PROPAGATION DELAY: 03:52:44 (0.19%); running time: 81d+23:16:09"
assID=0 status=42f4 leap_add_sec, sync_lf_clock, 15 events, event_peer/strat_chg,
version="ntpd [email-masked] Wed Dec  7 21:14:27 UTC 2011 (1)",
processor="i686", system="Linux/2.6.16.60-0.103.1-default", leap=01,
stratum=1, precision=-20, rootdelay=0.000, rootdispersion=3.084,
peer=32692, refid=DCFp,
reftime=d92a438b.0a0417d4  Tue, Jun 16 2015  8:41:15.039, poll=9,
clock=d92a43ca.8df242b5  Tue, Jun 16 2015  8:42:18.554, state=4,
...

(I know this server is old, but it has "good old hardware")

Regards,
Ulrich

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 16 Jun 2015 09:11:45 +0200

> So obviously NTPv4 allows the Leap Indicator (LI) to be set almost one month ahead, while NTPv3 requires LI to be set at most 24 hours before the event. So when using the definition of NTPv4, NTPv3…

Do you know if ntpd returns the LI when an NTPv3 client does a
query?

Are there still many NTPv3 clients?

Kurt

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 16 Jun 2015 09:35:32 +0200

> RFC 5905 says: "LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9." (page…

I think it's supposed to be day, not month.

The figure 9 in RFC 5905 has:

           | 1     | last minute of the day has 61 seconds  |
           | 2     | last minute of the day has 59 seconds  |

In RFC 4330 it's last minute of day like in RFC 1305. In ntpd versions before
4.2.6 it was announced in the month, but 4.2.6 and newer announce it only in
the last day.

> So obviously NTPv4 allows the Leap Indicator (LI) to be set almost one month ahead, while NTPv3 requires LI to be set at most 24 hours before the event. So when using the definition of NTPv4, NTPv3…

Right, clients that don't check what day it is are now leaping every day if
their server (or majority of servers) is already announcing the leap second.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 16 Jun 2015 08:41:45 +0000

"Ulrich Windl" writes:
> "On the day prior to the insertion of a leap second the leap bits
> (sys.leap) are set at the primary servers" (page 52) "Leap Indicator
> (LI): This is a two-bit code warning of an impending leap second to be
> inserted/deleted in the last minute of the current day," (page 63)
> 
> RFC 5905 says: "LI Leap Indicator (leap): 2-bit integer warning of an
> impending leap second to be inserted or deleted in the last minute of
> the current month with values defined in Figure 9." (page 20)
> 
> So obviously NTPv4 allows the Leap Indicator (LI) to be set almost one
> month ahead, while NTPv3 requires LI to be set at most 24 hours before
> the event. So when using the definition of NTPv4, NTPv3
> implementationy may misbehave, right?

No.  A v4 server should respond with v4 behavior when answering a v4
client, and v3 behavior when answering a v3 client.

I haven't looked to see if the code actually does this.

I will say we're well in to June and there are plenty of v4 servers out
there and we haven're received a bug report.

I haven't looked at the v3 code in a very long time.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 16 Jun 2015 08:56:09 +0000

> > NTPv4 servers already announce it:

and more than that, we haven't had a bug report about this since I can
remember for any previous leap seconds, and the NTPv4 code first came
out in the fall of 1997.

H

---

From: Hal Murray <[email-masked]>
Date: Tue, 16 Jun 2015 02:23:58 -0700

> servers already announce it: 

That's good.

The GPS satellites have been announcing a leap second for about 5 months.

> ntpq> cl assID=0 status=0004 clk_okay, last_clk_badsignal, device="Meinberg
> DCF PZF 535/509 / TCXO", timecode="\x0216.06.15; 2; 08:32:09;    S   \x03",
...
> system="Linux/2.6.16.60-0.103.1-default", leap=01, stratum=1, precision=-20,
...

"Announce" is an interesting word.  The DCF-77 driver has told ntpd that a 
leap is pending.  Is that server returning the leap bits on the normal NTP 
replies?  (I think they are mode 4)

---------

I fixed a bug a couple of months ago where the Palisade/Thunderbolt driver 
was returning the leap info several months early.  You can guess how I 
discovered the bug.

-- 
These are my opinions.  I hate spam.

---

From: Greg Dowd <[email-masked]>
Date: Tue, 16 Jun 2015 15:16:13 +0000

I did ask Dave Mills about this when the change first started creeping in.  I think the first use case was dial up ACTS where the poll interval could exceed a day.  I think there is also an interesting issue with the clearing of the leap indicator.  Years ago, the UDel documentation clearly described how the leap second could be disambiguated from the preceding second by using the leap indicator as a modifier.  This description of the behavior showed the leap indicator being cleared immediately after the leap was inserted.  I actually defined my architecture and design around this fact as I couldn't run the clock at 1/2 speed or some other high rate change without a significant impact on the frequency outputs of the boxes we made where frequency and phase were always coupled.   Because of this my second would actually "repeat" if queried continuously during the event.

At some point in the late nineties, the open source ntpd stopped clearing the leap indicator bit until some later point in the process, next sys poll or something, which caused some of our qa tests to fail.  When I asked Dave about it, he said that the onus of using the leap data was on the client system and had to be gated appropriately there and he saw no need to precisely define leap behaviors.  It essentially became a passthrough of the majority clique of the input sources.

I'm pretty sure there is nothing in ntp_proto.c that differentiates the leap bit response by version.  I think you get whatever sys_leap is set to.  

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of Ulrich Windl
Sent: Monday, June 15, 2015 11:45 PM
To: [email-masked]
Subject: [ntpwg] leap second: definitions and DCF-77

EXTERNAL EMAIL

Hi!

RFC 1305 (NTPv3) specifies:
"On the day prior to the insertion of a leap second the leap bits (sys.leap) are set at the primary servers" (page 52) "Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day," (page 63)

ntpq> cl
assID=0 status=0004 clk_okay, last_clk_badsignal, device="Meinberg DCF PZF 535/509 / TCXO",
timecode="\x0216.06.15; 2; 08:32:09;    S   \x03", poll=109779,
noreply=0, badformat=0, baddata=0, fudgetime1=12.310, stratum=0, refid=DCFp, flags=0,
refclock_time="d92a4169.00000000  Tue, Jun 16 2015  6:32:09.000", refclock_status="DST; TIME CODE; (LEAP INDICATION; ANTENNA)", refclock_format="Meinberg Standard",
refclock_states="*NOMINAL: 81d+16:15:38 (99.64%); FAULT: 03:07:47 (0.15%); PROPAGATION DELAY: 03:52:44 (0.19%); running time: 81d+23:16:09"
assID=0 status=42f4 leap_add_sec, sync_lf_clock, 15 events, event_peer/strat_chg, version="ntpd [email-masked] Wed Dec  7 21:14:27 UTC 2011 (1)", processor="i686", system="Linux/2.6.16.60-0.103.1-default", leap=01, stratum=1, precision=-20, rootdelay=0.000, rootdispersion=3.084, peer=32692, refid=DCFp,
reftime=d92a438b.0a0417d4  Tue, Jun 16 2015  8:41:15.039, poll=9,
clock=d92a43ca.8df242b5  Tue, Jun 16 2015  8:42:18.554, state=4, ...

Regards,
Ulrich

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 16 Jun 2015 23:19:23 +0200

Hi Ulrich,

[...]

> timecode="\x0216.06.15; 2; 08:32:09;    S   \x03", poll=109779,

There is no leap second warning flag in the time string above. An 
additional 'A' would indicate this. The 'S' means that Germany is on 
Summer time.

DCF-77 sends annoncement flags for DST changeover or leap second only 60 
minutes before the event.

> refclock_status="DST; TIME CODE; (LEAP INDICATION; ANTENNA)",

Don't know where the "LEAP INDICATION" in the refclock driver comes 
from. Eventually from a leap second file installed on the server? 
Current versions of ntpd wouldn't set/send the leap flag at the current 
time.

> processor="i686", system="Linux/2.6.16.60-0.103.1-default", leap=01,

"leap=01" send now is eventually very dangerous. If I remember correctly 
the 4.2.4 had a build-in check to accept leap seconds only at the end of 
June or December. This has been removed in 4.2.6 and newer.

If current versions of ntpd really accept a leap second warning for the 
end of the current day (and not only the current month) then such 
clients can run into problems.

I'm actually out of the office, on a training, so I can't duplicate the 
exact behaviour.

> (I know this server is old, but it has "good old hardware")

Martin
-- 
Martin Burnicki

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: David Malone <[email-masked]>
Date: Tue, 16 Jun 2015 10:47:45 +0100

> there and we haven're received a bug report.

Based on my data:

	http://www.maths.tcd.ie/~dwmalone/time/leaps/

It looks like they've been advertised for more than a day for a
long time. I could try and extract a bigger window, if that was
useful.

	Daviid.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 17 Jun 2015 08:32:05 +0200

Hi!

My initial complaint was like this (you could read between the lines, I guess):

The RFCs spcify what the LI indicates, but it does not really define when it has to be set and cleared when conforming to the protocol. Those statements about the "current day" or "current month" seem to describe common practice or expectation, but don't look very much like a definition.

--off-topic--
Most systems are described by a combination of allowing things and forbidding things. Thus there are things that are neither allowed or forbidden, effectively "defining the undefined". Some people don't like that and say: We only describe what is allowed, and everything that is not allowed is forbidden. -- Maybe we could redesign the specification like that...
---end off-topic---

Regards,
Ulrich

>>> Greg Dowd <[email-masked]> schrieb am 16.06.2015 um 17:16 in Nachricht
<[email-masked]>:
> I did ask Dave Mills about this when the change first started creeping in.  I 
> think the first use case was dial up ACTS where the poll interval could 
> exceed a day.  I think there is also an interesting issue with the clearing 
> of the leap indicator.  Years ago, the UDel documentation clearly described 
> how the leap second could be disambiguated from the preceding second by using 
> the leap indicator as a modifier.  This description of the behavior showed 
> the leap indicator being cleared immediately after the leap was inserted.  I 
> actually defined my architecture and design around this fact as I couldn't 
> run the clock at 1/2 speed or some other high rate change without a 
> significant impact on the frequency outputs of the boxes we made where 
> frequency and phase were always coupled.   Because of this my second would 
> actually "repeat" if queried continuously during the event.
> 
> At some point in the late nineties, the open source ntpd stopped clearing 
> the leap indicator bit until some later point in the process, next sys poll 
> or something, which caused some of our qa tests to fail.  When I asked Dave 
> about it, he said that the onus of using the leap data was on the client 
> system and had to be gated appropriately there and he saw no need to 
> precisely define leap behaviors.  It essentially became a passthrough of the 
> majority clique of the input sources.
> 
> I'm pretty sure there is nothing in ntp_proto.c that differentiates the leap 
> bit response by version.  I think you get whatever sys_leap is set to.  
> 
> 
> 
> 
> 
> 
> 
> 
> "On the day prior to the insertion of a leap second the leap bits (sys.leap) 
> are set at the primary servers" (page 52) "Leap Indicator (LI): This is a 
> two-bit code warning of an impending leap second to be inserted/deleted in 
> the last minute of the current day," (page 63)
> 
> impending leap second to be inserted or deleted in the last minute of the 
> current month with values defined in Figure 9." (page 20)
> 
> So obviously NTPv4 allows the Leap Indicator (LI) to be set almost one month 
> ahead, while NTPv3 requires LI to be set at most 24 hours before the event. 
> So when using the definition of NTPv4, NTPv3 implementationy may misbehave, 
> right?
> 
> refclock_states="*NOMINAL: 81d+16:15:38 (99.64%); FAULT: 03:07:47 (0.15%); 
> PROPAGATION DELAY: 03:52:44 (0.19%); running time: 81d+23:16:09"
> assID=0 status=42f4 leap_add_sec, sync_lf_clock, 15 events, 
> event_peer/strat_chg, version="ntpd [email-masked] Wed Dec  7 21:14:27 UTC 
> 2011 (1)", processor="i686", system="Linux/2.6.16.60-0.103.1-default", leap=01, 
> stratum=1, precision=-20, rootdelay=0.000, rootdispersion=3.084, peer=32692, 
> refid=DCFp,

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 17 Jun 2015 08:48:43 +0200

>>> Martin Burnicki <[email-masked]> schrieb am 16.06.2015 um
23:19 in
Nachricht <[email-masked]>:
> Hi Ulrich,
> 
> [...]
> Ulrich Windl wrote:
> 
>> As a matter of fact, DCF-77 is already announcing the leap second, and
NTPv4 
> servers already announce it:
>>
>> ntpq> cl

Mea culpa: Thanks Martin! I should have read the specs on the Meinberg data
format. Anyway: So the server got the information from the leapseconds file.

> minutes before the event.

That's what I read, but my guess was they might have changed it in the last
years.

> from. Eventually from a leap second file installed on the server? 

Maybe another confusion: Probably Frank Kardel or Rainer Pruy could verify:
The conversion is done in parsestate() of refclock_parse.c, but I didn't quite
understand the meaning of the parentheses.

> event_peer/strat_chg,