I am seeing several NTP servers -- both strata 1 and 2 -- reporting
leap-seconds in the middle of the month of January.  The 31 December
2008 leap-second has already passed.  More important, the standard
requires all leap-seconds to occur at the end of the last minute of a
calendar month with a convention that they occur at the end of a
calendar quarter.

NTP servers that report leap-seconds within a month are buggy and should
be fixed.  I have attempted to send E-mail messages to the operators of
buggy servers that I have detected.  This is not always successful
because listed E-mail addresses are sometimes obsolete.

Since I have not (and will not) test all NTP servers, operators reading
this newsgroup should check their own servers to ensure they are not
reporting false leap-seconds.

-- 

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?"  Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

David E. Ross wrote:

> 
> NTP servers that report leap-seconds within a month are buggy and should
> be fixed.  I have attempted to send E-mail messages to the operators of

NTP servers need to start announcing more than a day in advance, so I'm 
not sure what you mean by within a month.  The reason for this is the 
time that it can take to propagate from stratum 1 to stratum 15.

> buggy servers that I have detected.  This is not always successful
> because listed E-mail addresses are sometimes obsolete.

David Woolley wrote:
> David E. Ross wrote:
> 
>>
>> NTP servers that report leap-seconds within a month are buggy and should
>> be fixed.  I have attempted to send E-mail messages to the operators of
> 
> NTP servers need to start announcing more than a day in advance, so I'm 
> not sure what you mean by within a month.  The reason for this is the 
> time that it can take to propagate from stratum 1 to stratum 15.
> 
>> buggy servers that I have detected.  This is not always successful
>> because listed E-mail addresses are sometimes obsolete.

How many REAL servers or clients are at stratum 15?  I'd expect to find 
most clients at strata between 2 and 5.

Richard B. Gilbert wrote:

> How many REAL servers or clients are at stratum 15?  I'd expect to find 
> most clients at strata between 2 and 5.

That doesn't matter.  Servers have to act as though they have a stratum 
15 client.  (Actually, both stratum 15, with maxpoll 10, and root 
distance limits are less than a day, but it is still advisable to allow 
for down time as well.)

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>> How many REAL servers or clients are at stratum 15?  I'd expect to 
>> find most clients at strata between 2 and 5.
> 
> That doesn't matter.  Servers have to act as though they have a stratum 
> 15 client.  (Actually, both stratum 15, with maxpoll 10, and root 
> distance limits are less than a day, but it is still advisable to allow 
> for down time as well.)

Given the number of stratum 1, 2, and 3 systems that failed to get it 
right, I'm not going to worry about any higher strata.

On 1/25/2009 11:45 AM, David Woolley wrote:
> David E. Ross wrote:
> 
>> NTP servers that report leap-seconds within a month are buggy and should
>> be fixed.  I have attempted to send E-mail messages to the operators of
> 
> NTP servers need to start announcing more than a day in advance, so I'm 
> not sure what you mean by within a month.  The reason for this is the 
> time that it can take to propagate from stratum 1 to stratum 15.
> 
>> buggy servers that I have detected.  This is not always successful
>> because listed E-mail addresses are sometimes obsolete.

I believe the two-bit leap indicator in the NTP message indicates that a
leap-second will occur at the end of the current day.  At least, that's
how my NTP client (SocketWatch by RoboMagic) is interpreting the
message.  That's also per RFC 4330, the latest specification that I can
find for the protocol.

Leap-seconds are, of course, announced by the IERS well more than a
month in advance (announced almost six months in advance for the 31
December 2008 leap-second).  That announcement is repeated in the United
States by the USNO.

-- 

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?"  Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

"David E. Ross" <nobody@nowhere.not> writes:

>I am seeing several NTP servers -- both strata 1 and 2 -- reporting
>leap-seconds in the middle of the month of January.  The 31 December
>2008 leap-second has already passed.  More important, the standard
>requires all leap-seconds to occur at the end of the last minute of a
>calendar month with a convention that they occur at the end of a
>calendar quarter.

June 30 or Dec 31, then Sep 30 or Mar 31, then the ends of other months if
there are more than 4 a year. 
ntp refuses to do any that are not June or Dec. 



>NTP servers that report leap-seconds within a month are buggy and should
>be fixed.  I have attempted to send E-mail messages to the operators of
>buggy servers that I have detected.  This is not always successful
>because listed E-mail addresses are sometimes obsolete.

Agreed. Some servers are just irresponsible. 
Mind you in many cases the server operators have no idea what ntp means,
and no idea even how to switch off the leap second report.



>Since I have not (and will not) test all NTP servers, operators reading
>this newsgroup should check their own servers to ensure they are not
>reporting false leap-seconds.

Well, maybe you will catch 1 in a thousand of them.

Unruh <unruh-spam@physics.ubc.ca> writes:

>>Since I have not (and will not) test all NTP servers, operators reading
>>this newsgroup should check their own servers to ensure they are not
>>reporting false leap-seconds.

>Well, maybe you will catch 1 in a thousand of them.

I'm still monitoring a slice of them and updating the graphs at:

	http://www.maths.tcd.ie/~dwmalone/time/leap2008.html#ntpleapflag

The number of stratum 1 servers advertising the leap is almost zero
now. The number of pool and stratum 2 servers is still somewhat
higher,

	David.

dwmalone@maths.tcd.ie (David Malone) writes:

>Unruh <unruh-spam@physics.ubc.ca> writes:

>>>Since I have not (and will not) test all NTP servers, operators reading
>>>this newsgroup should check their own servers to ensure they are not
>>>reporting false leap-seconds.

>>Well, maybe you will catch 1 in a thousand of them.

>I'm still monitoring a slice of them and updating the graphs at:

>	http://www.maths.tcd.ie/~dwmalone/time/leap2008.html#ntpleapflag

>The number of stratum 1 servers advertising the leap is almost zero
>now. The number of pool and stratum 2 servers is still somewhat
>higher,

No I meant one in a thousand would read this post of yours and repent and
change their ways. 

Why not publish a list of the errant servers and shame them into good behaviour. 



>	David.

Richard B. Gilbert wrote:

> 
> Given the number of stratum 1, 2, and 3 systems that failed to get it 
> right, I'm not going to worry about any higher strata.

It is the stratum 1, 2 and 3 servers that need to set the leap indicator 
early.

There probably is a problem with leap indicators not being cancelled, 
but there seem to be a suggestion in the original article that leap 
indication should only be set within minutes of the event.

Unruh <unruh-spam@physics.ubc.ca> writes:

>No I meant one in a thousand would read this post of yours and repent and
>change their ways. 

Ah - sorry - I misunderstood!

>Why not publish a list of the errant servers and shame them into good behaviour

I suspect that the stratum 2 and pool servers that are still
advertising leaps are doing so because they have learned about it
from an upstream server that is advertising it, so there's not much
point in nagging about it. From the stratum 1 list, I've only seen
ntp2.remco.org and ubitaneous.cpsc.ucalgary.ca advertise leap bits
in the last couple of days.

I guess that when the newer version of ntpd that takes a vote on
the forthcomming leap second is more widely deployed, then the
number of stratum 2 and pool servers advertiting leaps will be more
tame.

	David.

On 1/25/2009 11:41 PM, David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>> Given the number of stratum 1, 2, and 3 systems that failed to get it 
>> right, I'm not going to worry about any higher strata.
> 
> It is the stratum 1, 2 and 3 servers that need to set the leap indicator 
> early.
> 
> There probably is a problem with leap indicators not being cancelled, 
> but there seem to be a suggestion in the original article that leap 
> indication should only be set within minutes of the event.

Per my earlier reply, they should be set only during the same day that
ends with a leap-second.

-- 

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?"  Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

"David E. Ross" <nobody@nowhere.not> writes:

>Per my earlier reply, they should be set only during the same day that
>ends with a leap-second.

Note that while some of the current RFCs say "current day" the draft
of the NTPv4 spec at:

	http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-11.txt

says "end of the current month". I guess this is to bring the spec
inline with existing practice.

	David.

On 1/26/2009 8:30 AM, David Malone wrote:
> "David E. Ross" <nobody@nowhere.not> writes:
> 
>> Per my earlier reply, they should be set only during the same day that
>> ends with a leap-second.
> 
> Note that while some of the current RFCs say "current day" the draft
> of the NTPv4 spec at:
> 
> 	http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-11.txt
> 
> says "end of the current month". I guess this is to bring the spec
> inline with existing practice.
> 
> 	David.

Whether the leap-second flag means "end of the current day" (per RFCs
1305 and 4330) or "end of the current month" (per the draft RFC for NTP
v.4), indicating a leap-second today is an error.  When such an error is
seen, it makes me question the accuracy of the affected NTP server.
After all, if they can't get the leap-second flag correct (something I
dealt with in the early 1970s before there was NTP), what else are they
doing wrong?

By the way, the draft RFC expires in a little over a month from now.

-- 

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?"  Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

David,

David E. Ross wrote:
> On 1/26/2009 8:30 AM, David Malone wrote:
>> "David E. Ross" <nobody@nowhere.not> writes:
>> 
>>> Per my earlier reply, they should be set only during the same day that
>>> ends with a leap-second.
>> 
>> Note that while some of the current RFCs say "current day" the draft
>> of the NTPv4 spec at:
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-11.txt
>> 
>> says "end of the current month". I guess this is to bring the spec
>> inline with existing practice.

Since leap seconds are only to be inserted at the end of a month it
shouldn't really matter whether a (valid) announcement starts at the
beginning of the month or at the last day of a month.

If the receiver of that announcement works correctly then the leap second
should be inserted correctly.

> Whether the leap-second flag means "end of the current day" (per RFCs
> 1305 and 4330) or "end of the current month" (per the draft RFC for NTP
> v.4), indicating a leap-second today is an error.

I absolutely agree. The question is what is the reason for this error.

> When such an error is 
> seen, it makes me question the accuracy of the affected NTP server.
> After all, if they can't get the leap-second flag correct (something I
> dealt with in the early 1970s before there was NTP), what else are they
> doing wrong?

There may be several possible reasons why an NTP server may still report a
leap second announcement. 

For example, that particular NTP server still receives an announcement from
an upstream source (NTP server or refclock). If the upstream source is a
refclock then the refclock should be blamed. If the upstream source is an
NTP server then the question is again, where that NTP server has received
the announcement from.

The question is also which version of the NTP program is running on those
servers.

Around the last leap second I've heard 2 reports from different people that
NTP servers running release versions did not clear the leap second flag
after the leap second had occurred (and inserted correctly) when the
servers had been configured to peer with other servers.

This seems to indicate that if a group of peers has received an announcement
from an external source they pass arround the announcement to each other so
it will never be cleared. 

Sounds like this might be what you've observed. 

I haven't duplicated this problem, but if it's true it's clearly a bug in
ntpd, though this may pop up in certain configurations.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

dwmalone@maths.tcd.ie (David Malone) wrote:

> From the stratum 1 list, I've only seen ntp2.remco.org [...] advertise
> leap bits in the last couple of days.

That's interesting because it's open to ntpq.  It's running 4.2.5p113
and seems to have the leapfile (tai=33, leapsec=200901010000,
expire=200906280000), which I thought was supposed to get it right.
However its GPS refclock has leap=01.

-- 
Ronan Flood <usenet@umbral.org.uk>

David E. Ross wrote:
> Whether the leap-second flag means "end of the current day" (per RFCs
> 1305 and 4330) or "end of the current month" (per the draft RFC for NTP
> v.4), indicating a leap-second today is an error.  When such an error is
> seen, it makes me question the accuracy of the affected NTP server.
> After all, if they can't get the leap-second flag correct (something I
> dealt with in the early 1970s before there was NTP), what else are they
> doing wrong?
> 
> By the way, the draft RFC expires in a little over a month from now.
> 

That doesn't matter at this point. The draft has been forwarded to IESG
for review. The draft termination date relates to the point beyond which
discussions should not continue in the working group without an updated
draft. Once last call as closed and forwarded to IESG the expiration
date is not relevant. It's important to expire drafts because ones that
don't progress can be dropped.

Danny