Subject: Re: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009

From: "Linas Vepstas" <[email-masked]>
Date: Mon, 5 Jan 2009 11:42:35 -0600

2009/1/5  <[email-masked]>:
> On Mon, 5 Jan 2009, Linas Vepstas wrote:
>
>>> Arguably the kernel's responsibility should be to keep track of the
>>> most fundamental representation of time possible for a machine (that's
>>> probably TAI) and it is a userspace responsibility to map from that
>>> value to other time standards including UTC,
>>
>> Yes, this really does seem like the right solution.
>>
>>> using control files
>>> which are updated as leap seconds are declared.
>>
>> Lets be clear on what "control files" means.  This does
>> *NOT* mean some config file shipped by some distro
>> for some package. That would be a horrid solution.
>> People don't install updates, patches, etc.  Distros
>> ship them late, or never, if the distro is old enough.
>>
>> A more appropriate solution would be to have
>> either the kernel or ntpd track the leap seconds
>> automatically.  First, the ntp protocol already provides
>> the needed notification of a leap second to anyone
>> who cares about it (i.e. there is no point in getting a
>> Linux distro involved in this -- a distribution mechanism
>> already exists, and works *better* than having a distro
>> do it).
>
> I disagree with this. NTP will only know about leap seconds if it was
> running and connected to a server that advertised the leap seconds during
> that month.
>
> for example, if you installed a new server today, how would it ever know
> that there was a leap second a couple of days ago?

OK, good point.  Unless your distro was less
than a few days old (unlikely), you are faced with the
same problem.  Sure, eventually, the distro will publish
an update (which will add to the existing list of 36 leap
seconds -- which is needed in any case, since no one
has a server that's been up since 1958),  but this is
unlikely to happen during this install window.

The long term solution would be write an RFC to extend
NTP to also provide TAI information -- e.g. to add a
message that indicates the current leap-second offset
between UTC and TAI.

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

---

From: "john stultz-lkml" <[email-masked]>
Date: Mon, 5 Jan 2009 18:27:18 -0800

On Mon, Jan 5, 2009 at 9:42 AM, Linas Vepstas <[email-masked]> wrote:
[snip]
> message that indicates the current leap-second offset

I believe Roman has already added this ability:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=153b5d054ac2d98ea0d86504884326b6777f683d;hp=9f14f669d18477fe3df071e2fa4da36c00acee8e

thanks
-john

---

From: "Linas Vepstas" <[email-masked]>
Date: Mon, 5 Jan 2009 22:53:46 -0600

> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=153b5d054ac2d98ea0d86504884326b6777f683d;hp=9f14f669d18477fe3df071e2fa4da36c00acee8e

Well, you're answering a different statment than what
I was talking about -- I wanted to make sure that TAI
information was available via NTP -- this has nothing
to do with the kernel, and would be something available
to all operating systems.

Anyway -- I'm looking at the patch you reference, and
maybe I'm being dumb -- but -- I think I see a bug.

case TIME_DEL decrements TAI, but TIME_INS does
not increment it. Instead, there's a lonely increment in
TIME_OOP which seems wrong.  ??

--linas

---

From: "Linas Vepstas" <[email-masked]>
Date: Mon, 5 Jan 2009 23:00:30 -0600

Oops.

> TIME_OOP which seems wrong.  ??

Never mind. Sorry, I'm wrong, the code looks right.
Time to stop reading email, and go to bed. :-)

--linas

---

From: David Newall <[email-masked]>
Date: Wed, 07 Jan 2009 20:33:59 +1030

Linas Vepstas wrote:
> Currently, the Linux kernel keeps time in UTC. This means
> that it must take special actions to tick twice when a leap
> second comes by.

Except it doesn't have to tick twice.  Refer to
http://lkml.org/lkml/2009/1/7/78 in which I show that a time_t (what
time() returns) counts leap seconds (According to Bernstein this is what
UTC means), and using zoneinfo, the library processes leap seconds
correctly.

I just realised that the Notes in man 2 time are confusing and probably
unnecessary.  Suffice to say that (assuming correctly configured
zoneinfo) time() returns the number of seconds elapsed since start 1970.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "M. Warner Losh" <[email-masked]>
Date: Tue, 06 Jan 2009 12:40:55 -0700 (MST)

In message: <[email-masked]>
            "Linas Vepstas" <[email-masked]> writes:
: 2009/1/5 john stultz-lkml <[email-masked]>:
: > On Mon, Jan 5, 2009 at 9:42 AM, Linas Vepstas <[email-masked]> wrote:
: > [snip]
: >> The long term solution would be write an RFC to extend
: >> NTP to also provide TAI information -- e.g. to add a
: >> message that indicates the current leap-second offset
: >> between UTC and TAI.
: >
: > I believe Roman has already added this ability:
: > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=153b5d054ac2d98ea0d86504884326b6777f683d;hp=9f14f669d18477fe3df071e2fa4da36c00acee8e
: 
: Well, you're answering a different statment than what
: I was talking about -- I wanted to make sure that TAI
: information was available via NTP -- this has nothing
: to do with the kernel, and would be something available
: to all operating systems.
: 
: Anyway -- I'm looking at the patch you reference, and
: maybe I'm being dumb -- but -- I think I see a bug.
: 
: case TIME_DEL decrements TAI, but TIME_INS does
: not increment it. Instead, there's a lonely increment in
: TIME_OOP which seems wrong.  ??

No.  That's right.  The increment doesn't happen until the leap second
has happened.  The TIME_OOP exists to increment the TAI offset at the
right time.  The decrement would happen right away, since the second
is deleted at the end of :58.

I had to draw lots of pictures when I was working this code out in
FreeBSD.

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Tue, 06 Jan 2009 12:50:34 -0700 (MST)

In message: <[email-masked]>
            "Linas Vepstas" <[email-masked]> writes:
: 2009/1/5  <[email-masked]>:
: > On Mon, 5 Jan 2009, Linas Vepstas wrote:
: >
: >>> Arguably the kernel's responsibility should be to keep track of the
: >>> most fundamental representation of time possible for a machine (that's
: >>> probably TAI) and it is a userspace responsibility to map from that
: >>> value to other time standards including UTC,
: >>
: >> Yes, this really does seem like the right solution.
: >>
: >>> using control files
: >>> which are updated as leap seconds are declared.
: >>
: >> Lets be clear on what "control files" means.  This does
: >> *NOT* mean some config file shipped by some distro
: >> for some package. That would be a horrid solution.
: >> People don't install updates, patches, etc.  Distros
: >> ship them late, or never, if the distro is old enough.
: >>
: >> A more appropriate solution would be to have
: >> either the kernel or ntpd track the leap seconds
: >> automatically.  First, the ntp protocol already provides
: >> the needed notification of a leap second to anyone
: >> who cares about it (i.e. there is no point in getting a
: >> Linux distro involved in this -- a distribution mechanism
: >> already exists, and works *better* than having a distro
: >> do it).
: >
: > I disagree with this. NTP will only know about leap seconds if it was
: > running and connected to a server that advertised the leap seconds during
: > that month.
: >
: > for example, if you installed a new server today, how would it ever know
: > that there was a leap second a couple of days ago?
: 
: OK, good point.  Unless your distro was less
: than a few days old (unlikely), you are faced with the
: same problem.  Sure, eventually, the distro will publish
: an update (which will add to the existing list of 36 leap

List of 24 leap seconds.  Although the delta is 34 right now, the
first 10 leap seconds were done as tiny steps (~50-100ms) plus
frequency offsets.  Well, the first 'leap' was 1.4228180s on Jan 1,
1961.  Everybody assumes that those seconds don't exist to simplify
things (or that there was simply a 10s step between TAI and UTC on
1-Jan-1972).  The leapsecond file from NIST doesn't even have them.

: seconds -- which is needed in any case, since no one
: has a server that's been up since 1958),  but this is
: unlikely to happen during this install window.
: 
: The long term solution would be write an RFC to extend
: NTP to also provide TAI information -- e.g. to add a
: message that indicates the current leap-second offset
: between UTC and TAI.

I'd love that.  There's likely going to be some resistance to that
because the leapfile is available via the crypto-authenticated means.
However, there's no real-time information available...  Also, there
are many reference clocks that would need this information plugged
into it somehow (IRIG doesn't report leap seconds in any meaningful[*]
way, let alone UTC-TAI offset).

[*] Some IRIG extensions do support reporting leap seconds at the end
of the hour, but that's too late...

Warner

---

From: "john stultz" <[email-masked]>
Date: Wed, 7 Jan 2009 08:04:14 -0800

On Wed, Jan 7, 2009 at 6:34 AM, Danny Mayer <[email-masked]> wrote:
> I'd much rather you spend the time tackling the clock interrupt losses
> that many of our Linux users complain about. See:
> https://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.
> for some of the gorier details. I'm sure you don't really want us
> recommending that they set HZ=100 in the kernel to alleviate the problem.

I believe the lost tick issue as well as the HZ=100 suggestions at the
page above are out of date for 2.6.21 and higher kernels as the
generic timekeeping rework addressed these problems.

Please let me know if you're still seeing any such issues with NTP.

thanks
-john

---

From: Danny Mayer <[email-masked]>
Date: Tue, 06 Jan 2009 22:50:12 -0500

>> that there was a leap second a couple of days ago?

Because it gets it's time from an upstream server that already has
incorporated the leap second so it doesn't really need to know that the
leap second happened a few days ago or even a few years ago.

> unlikely to happen during this install window.

This is nonsense. That's not how NTP works.

> message that indicates the current leap-second offset

I don't know what this discussion is really about and why this was sent
  to the working group in the middle of the discussion, but there is no
need for NTP to provide TAI information since NTP only uses UTC. Leap
Seconds are automatically signaled  and incorporated when they become
due. If you don't have NTP running for some reason when a leap second is
signaled it doesn't matter since your server source will already have
incorporated the leap second so the NTP packet includes the timestamps
that include the leap second adjustment.

Operating Systems use UTC and not TAI by universal agreement and the
ones that don't are extremely rare.

Why don't you tell us what the real problem is instead of telling us
that you need TAI offset information?

Danny

---

From: "Linas Vepstas" <[email-masked]>
Date: Tue, 6 Jan 2009 22:52:20 -0600

2009/1/6 Danny Mayer <[email-masked]>:
Hi,

Currently, the Linux kernel keeps time in UTC. This means
that it must take special actions to tick twice when a leap
second comes by.  Due to a (stupid) bug, some fraction
of linux systems crashed; this includes everything from
laptops to servers, to DVR's,  to cell phones and cell
phone towers. There's now a fix for this.

However, during the discussion, the idea came out that
maybe keeping UTC time in the kernel is just plain stupid.
So there's this idea floating around that maybe the kernel
should keep TAI time instead. The hope is that this will
reduce the complexity in the kernel, and push it out to
user space, "where it belongs" (to repeat a well-worn
mantra).

However, *if* we were to kick UTC out of the kernel,
and push it to user-land, then, of course, there's a
different problem: how does the kernel know what the
correct TAI time is?  As your reply makes abundantly
clear, NTP is not a good source for TAI information.

The comments which you labelled as "non-sense" were
a mis-understanding of  a discussion of a particular issue
that would arise if the kernel were to keep TAI -- if it did,
then user-space systems would need to have a reliable
source for leap-seconds. Since NTP does not
provide this, there was discussion about how that
could be worked-around. This then lead to the comment
that, "gee, wouldn't the right long-term solution be that
NTP provide TAI info?"

Clearly, it would be a lot of work to get the kernel to keep
TAI instead of UTC, so this is not, at this time, a "serious
proposal".  But if it were possible, and all the various
little issues that result were solvable, then it does seem
like a better long-term solution.

--linas

p.s. the opinions above are not my own; I'm just
summarizing the points made by the most vocal
posters to this list.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Wed, 07 Jan 2009 09:34:30 -0500

> that, "gee, wouldn't the right long-term solution be that

It was nonsense because the summary didn't contain all of the
information required to provide context and you copied the Working Group
in the middle of all this.

NTP can provide leap-second information via an autokey protocol request,
 see Section 10.6 Leapseconds Values Message (LEAP)
http://www.ietf.org/internet-drafts/draft-ietf-ntp-autokey-04.txt but
that means you need to have autokey set up with another NTP server and
that means adding infrastructure that you probably don't want and are
not prepared to handle.

> like a better long-term solution.

This is a *lot* more complicated than you might think. If you are
thinking of implementing this similarly to the way timezone information
is added for display purposes, you need the whole list of leap seconds
and when the change happened since you now have to look at a timestamp
and see when it was and then apply all of the leapseconds up to that
point in time and none of the leapseconds beyond that. In addition, you
have legacy files that have UTC timestamps on them so you would need to
distinguish between UTC (legacy) and TAI timestamps in the file system
among other places (anywhere where a timestamp exists) and what would
you do about database tables which contain timestamps? The list goes on.

Danny

---

From: "Linas Vepstas" <[email-masked]>
Date: Wed, 7 Jan 2009 09:42:53 -0600

Thanks for the reply.

>> clear, NTP is not a good source for TAI information.

[...]

>>   a discussion of a particular issue

Yes, that look like exactly what would be wanted.  It would be nice
if such a message was available in the regular, non-encrypted protocol.

> that means adding infrastructure that you probably don't want and are

Heh. Yes, well, I still haven't figured out how to secure DNS. Yet clearly
this whole security mess must march on, and somehow the security
infrastructure must eventually become easy to install.

> you do about database tables which contain timestamps? The list goes on.

Yes.

> recommending that they set HZ=100 in the kernel to alleviate the problem.

Actually, this is rather sorely lacking in 'gory details', rather, its
a complaint
that 'things don't work' with no discussion of the actual problem.  It would
be much better if there was a link to any previous discussions on LKML on
this issue.

My knee-jerk reaction on reading about the lost-interrupts issue is that,
yes, setting HZ=100 and disabling ACPI is indeed a decent short-term
work-around (APIC is something completely different and not something
you can disable). The correct long-term solution would be to use real-time
kernels, which are designed to make sure that things like lost interrupts
never happen.

I have no idea what the status of real-time Linux is, whether it would now
have gaurantees for timer ticks, and whether anything there would now
be mergeable into the mainline kernel.

--linas

---

From: Alan Cox <[email-masked]>
Date: Wed, 7 Jan 2009 19:31:27 +0000

> time, causing time to jump backwards by 1s (or violate POSIX time_t's
> invariant that midnight time_t is % 86400 == 0).  This jump backwards
> is a pita in the kernel, and violates the assumption that many
> programs have that time doesn't flow backwards.

They can slew the clock slowly as well. There is a wonderful quote from
one of the summaries of the POSIX committee discussions on time that says
quite simply "the posix clock is not guaranteed to be accurate"

As it currently stands the kernel contains sufficient support that at the
point you know a leap second is coming you can adjust the second length
marginally over the entire period.

The current behaviour is an implementation decision. Jumping on a second
shouldn't be an issue to most people, jumping back is asking for badness
but isn't in fact used in the world today. Slewing the entire day so that
each second is 1/86400 of a second longer or shorter wouldn't be noticed
by anyone.

Alan

---

From: Alan Cox <[email-masked]>
Date: Thu, 8 Jan 2009 10:56:56 +0000

On Thu, 8 Jan 2009 10:48:54 +0000
Alan Cox <[email-masked]> wrote:

> > On FreeBSD, Solaris and Digital Unix, I'll point out, that jumping
> > backwards is used, and has been used since at least 1994.  So saying
> > it isn't used in the world today is flat out wrong.

[Ignore previous email, must remember not to post before waking up  ;)]

You are correct - and providing gettimeofday() is being used on Linux
rather than time() which simply appears to stall due to resolution the
same is true.

Some users do run with the "right" timezone data in non posix mode
because they want their seconds 'sane' but that isn't the default.

Alan

---

From: "M. Warner Losh" <[email-masked]>
Date: Wed, 07 Jan 2009 10:24:34 -0700 (MST)

In message: <[email-masked]>
            David Newall <[email-masked]> writes:
: Linas Vepstas wrote:
: > Currently, the Linux kernel keeps time in UTC. This means
: > that it must take special actions to tick twice when a leap
: > second comes by.
: 
: Except it doesn't have to tick twice.  Refer to
: http://lkml.org/lkml/2009/1/7/78 in which I show that a time_t (what
: time() returns) counts leap seconds (According to Bernstein this is what
: UTC means), and using zoneinfo, the library processes leap seconds
: correctly.

This is *NOT* POSIX time_t.  In order to be posix compliant, you can't
do what Bernstein suggests.  You can be non-complaint and deal it with
zoneinfo.

: I just realised that the Notes in man 2 time are confusing and probably
: unnecessary.  Suffice to say that (assuming correctly configured
: zoneinfo) time() returns the number of seconds elapsed since start 1970.

That's not POSIX complaint.

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Wed, 07 Jan 2009 10:36:45 -0700 (MST)

In message: <[email-masked]>
            "Linas Vepstas" <[email-masked]> writes:
: However, during the discussion, the idea came out that
: maybe keeping UTC time in the kernel is just plain stupid.
: So there's this idea floating around that maybe the kernel
: should keep TAI time instead. The hope is that this will
: reduce the complexity in the kernel, and push it out to
: user space, "where it belongs" (to repeat a well-worn
: mantra).

I agree that this is where it belongs, but it is hard to do that in a
POSIX compliant way.  It also becomes hard to timestamp things in
filesystems using UTC rather than TAI.  There are other protocols that
deal with UTC times as well.

: However, *if* we were to kick UTC out of the kernel,
: and push it to user-land, then, of course, there's a
: different problem: how does the kernel know what the
: correct TAI time is?  As your reply makes abundantly
: clear, NTP is not a good source for TAI information.

Agreed.  That's the whole crux of the 'multiple time scales suck'
threads that I've talked about in other forums.  You have to know this
information before you start, have to deal with 'dusty system' problem
for systems that have been off for 6 months or not upgraded.  You also
have to cope with learning after the fact that your initial guess was
wrong.

I've had many systems that would get this information from GPS and
stall the rest of the system until this data came in.  I did this
mostly because there were big issues with the software down stream if
you changed the delta between your putative UTC and TAI after the
fact.

: The comments which you labelled as "non-sense" were
: a mis-understanding of  a discussion of a particular issue
: that would arise if the kernel were to keep TAI -- if it did,
: then user-space systems would need to have a reliable
: source for leap-seconds. Since NTP does not
: provide this, there was discussion about how that
: could be worked-around. This then lead to the comment
: that, "gee, wouldn't the right long-term solution be that
: NTP provide TAI info?"

I've wanted this for a long time...

: Clearly, it would be a lot of work to get the kernel to keep
: TAI instead of UTC, so this is not, at this time, a "serious
: proposal".  But if it were possible, and all the various
: little issues that result were solvable, then it does seem
: like a better long-term solution.

Yes.  The kernel would need to be able to return both UTC and TAI
times to the kernel as well, since there are requirements for NFS to
return timestamps in UTC, not in TAI.  Many file systems specify UTC
time, or have traditionally been implemented that way.

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Wed, 07 Jan 2009 10:39:47 -0700 (MST)

In message: <[email-masked]>
            Danny Mayer <[email-masked]> writes:
: Why don't you tell us what the real problem is instead of telling us
: that you need TAI offset information?

The real problem is that POSIX time_t totally ignores leap seconds.
This forces systems that are rolling through a leap second to repeat
time, causing time to jump backwards by 1s (or violate POSIX time_t's
invariant that midnight time_t is % 86400 == 0).  This jump backwards
is a pita in the kernel, and violates the assumption that many
programs have that time doesn't flow backwards.

The suggestion to solving this would be to tick in TAI time, and force
userland to cope with the leapsecond issues.  Of course, there's a
number of problems with this solution as well, but it feels like it
belongs there...

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Wed, 07 Jan 2009 12:42:01 -0700 (MST)

In message: <[email-masked]>
            Alan Cox <[email-masked]> writes:
: > time, causing time to jump backwards by 1s (or violate POSIX time_t's
: > invariant that midnight time_t is % 86400 == 0).  This jump backwards
: > is a pita in the kernel, and violates the assumption that many
: > programs have that time doesn't flow backwards.
: 
: They can slew the clock slowly as well. There is a wonderful quote from
: one of the summaries of the POSIX committee discussions on time that says
: quite simply "the posix clock is not guaranteed to be accurate"

True, You can.  However, anybody you peer with via ntpd will have
issues unless things are coordinated with ntpd (and aren't a leaf
node).  There you have much higher tolerances for correctness.

: As it currently stands the kernel contains sufficient support that at the
: point you know a leap second is coming you can adjust the second length
: marginally over the entire period.
: 
: The current behaviour is an implementation decision. Jumping on a second
: shouldn't be an issue to most people, jumping back is asking for badness
: but isn't in fact used in the world today. Slewing the entire day so that
: each second is 1/86400 of a second longer or shorter wouldn't be noticed
: by anyone.

If you are an ntp leaf node, that doesn't care about UTC accurate to
the second, this will work well.  For most users, this effectively
papers over the problem.

If you do care about UTC time being more accurate than this slewing
will be too large and introduce errors that are too big.  Likewise for
non-leaf ntp nodes.  For these machines, having time be off by 1/2
second can be very bad.  There are many real-time systems that fall
into this category, trading systems on wall street, systems that
control things based on doing things at certain points within UTC
second, etc.  For those types of systems, changing the length of the
second by this much isn't going to work at all.

ntpd also lights the INS bit only on 'leap day' so depending on when
you poll, you might not have a full day's notice of these changes, but
that can be managed...

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Wed, 07 Jan 2009 21:42:20 -0700 (MST)

In message: <[email-masked]>
            Danny Mayer <[email-masked]> writes:
: Alan Cox wrote:
: >> time, causing time to jump backwards by 1s (or violate POSIX time_t's
: >> invariant that midnight time_t is % 86400 == 0).  This jump backwards
: >> is a pita in the kernel, and violates the assumption that many
: >> programs have that time doesn't flow backwards.
: > 
: > They can slew the clock slowly as well. There is a wonderful quote from
: > one of the summaries of the POSIX committee discussions on time that says
: > quite simply "the posix clock is not guaranteed to be accurate"
: > 
: > As it currently stands the kernel contains sufficient support that at the
: > point you know a leap second is coming you can adjust the second length
: > marginally over the entire period.
: > 
: > The current behaviour is an implementation decision. Jumping on a second
: > shouldn't be an issue to most people, jumping back is asking for badness
: > but isn't in fact used in the world today. Slewing the entire day so that
: > each second is 1/86400 of a second longer or shorter wouldn't be noticed
: > by anyone.
: 
: NTP handles most of this, but it needs the cooperation of the O/S kernel
: and most of the Unix kernels are able to provide the required API's.
: FreeBSD doesn't have any of these problems but Linux historically has.
: Most of that code was designed by Dave Mills but since each kernel is
: different we should not expect them all to behave the same way and
: generally requires an understanding of what NTP expects and that's not
: always clear to kernel developers who are not expected to know NTP.

Warner

---

From: "M. Warner Losh" <[email-masked]>
Date: Thu, 08 Jan 2009 08:02:29 -0700 (MST)

In message: <[email-masked]>
            Alan Cox <[email-masked]> writes:
: > On FreeBSD, Solaris and Digital Unix, I'll point out, that jumping
: > backwards is used, and has been used since at least 1994.  So saying
: > it isn't used in the world today is flat out wrong.
: 
: I stand by my comment - when was the last time the IERS used a leap
: second removal ? The code may exist but it doesn't happen.

Jumping backwards is used for every leap second that IERS has ever
done, which was your original comment.  There's has never been a case
where there was a leap second for jump forward though.  The proper
technical term here is 'negative leap second'.  All leap seconds up
until now have been positive leap seconds, and it is unlikely there
ever will be a negative one.

Warner

---

From: Danny Mayer <[email-masked]>
Date: Wed, 07 Jan 2009 14:23:43 -0500

> if such a message was available in the regular, non-encrypted protocol.

It's not encrypted, it's an authentication protocol. You really do need
to know that you are receiving a reliable set of information otherwise
anyone can spoof you with bad data and play havoc with your clock and
timestamps.

> infrastructure must eventually become easy to install.
<DNS hat>
That's pretty easy. Install BIND 9.6.0. Read the DNSSEC deployment
instructions here: https://www.isc.org/files/DNSSEC_in_6_minutes.pdf and
implement. You should be done in almost no time.
</DNS hat>

> be much better if there was a link to any previous discussions on LKML on

Sorry, but that's not my area of expertise. I just know we have many
people running Linux and have these issues.

> kernels, which are designed to make sure that things like lost interrupts

I bow to your superior knowledge in this area.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 07 Jan 2009 22:57:54 -0500

> each second is 1/86400 of a second longer or shorter wouldn't be noticed

NTP handles most of this, but it needs the cooperation of the O/S kernel
and most of the Unix kernels are able to provide the required API's.
FreeBSD doesn't have any of these problems but Linux historically has.
Most of that code was designed by Dave Mills but since each kernel is
different we should not expect them all to behave the same way and
generally requires an understanding of what NTP expects and that's not
always clear to kernel developers who are not expected to know NTP.

Danny

---

From: David Mills <[email-masked]>
Date: Thu, 08 Jan 2009 22:22:15 +0000

Folks,

You are not correct. The kernel software clock variable is in fact 
stepped back, but the routine that actually reads the clock does not 
step the clock back unless set back more than two seconds.. Otherwise, 
the clock is strictly monotonic. That is the ad vice I gave in rfc1583 
and implemented the Digital Unix kernel because I wrote tthe code. Other 
kernelmongers might or might not have taken the advice.

As for the TAI issue discussed earlier, note that the generic NTP kernel 
supportfrom me since 1991  has TAI . However, support to read it 
requires the ntp_gettime()  syscall and nlot all kernels support it.

The recent leap was observed to work correctly in Solaris and FreeBSD. 
It worked fine with the WWV driver and the Spectracom GPS driver, but 
not the NMEA, Arbiter, Meinberg nor any of the NIST or USNO primary 
servers. It probably did work with the Canadian servers, since the 
Ottowa primary server is synchronized via my CHU audio driver. It didn't 
work onn my carefully contrived backroom servers, as they lost power 
durring the event.

See  www.eecis.udel.edu/~mills/leap.html and/or the online NTP 
documentation and/or my book.

Dave

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 08 Jan 2009 17:51:20 +0100

> do what Bernstein suggests.  You can be non-complaint and deal it with

You are free to keep your core time in whatever form you wish, but if 
you want your time_t to be POSIX compatible when accessed over POSIX 
interfaces you would need to honour the POSIX time_t mapping. While 
POSIX tried to avoid the leapsecond issue, the mapping they do perform 
has a peculiar effect on what happends on time_t if you also want to 
honour the UTC to time_t mapping while accepting UTC from external sources.

> That's not POSIX complaint.

It just *appears* to be the number of "seconds" since 1970. This 
appearence is important to some and causing a greif to others.

Cheers,
Magnus

---

From: Steve Allen <[email-masked]>
Date: Thu, 8 Jan 2009 12:09:34 -0800

> number of problems with this solution as well, but it feels like it

Agreed that the leap second belong in userland, but BIPM itself
refuses to agree with the idea of the underlying time scale being TAI.
TAI has no standing as an international recommendation, and it is not
available via the established broadcast mechanisms, and BIPM does not
want those things to happen.  What would be needed is a leap-free time
scale with an international recommendation standing behind it so as to
legitimize its use.

The most recent public insight to the ITU-R process of reconsidering
leap seconds in UTC is from September, here
http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf
In the schedule given on page 16 we see that even if the ITU-R process
goes smoothly there will be leap seconds at least until 2017, so we
have to live with them for at least that long.  However, at the
October meeting of ITU-R WP7A things did not go smoothly.  There were
two countries objecting to any change to UTC, so the process of
considering any change to the broadcast time scale is stalled.

Basically, any change to UTC is currently stalled by the
international political/diplomatic process which controls it.

Way back in 2003 the ITU-R asked for advice on the broadcast time
scale, and the advice from the experts included changing the name if
leaps are dropped.
http://www.inrim.it/luc/cesio/itu/closure.pdf
At that point nobody managed to point out that POSIX demands that the
zoneinfo mechanisms allow for offsets of seconds as well as minutes,
so there was no clear path for implementing that advice while
preserving compliance with specifications that still demand UTC.

Any epoch-based time scale has issues with UTC as it has been defined
http://www.ucolick.org/~sla/leapsecs/epochtime.html
and by ignoring leap seconds POSIX makes that even harder to implement.
During the past century we have seen the creation of at least 4
different uniform time scales, two of which are widely available by
broacast (LORAN-C and GPS), but none of which has the backing of an
international standard behind it.
http://www.ucolick.org/~sla/leapsecs/deltat.html

All civil time scales are conventional constructs, and zoneinfo is
designed to handle the arbitrary nature of changes to civil time.  If
the underlying time scale changes its name and stops having leaps,
then leap seconds in UTC are just another form of conventional change
to civil time.  UTC could become a time zone.  Processes which happen
when POSIX time_t % 86400 == 0 would happen at "atomic midnight"
instead of "civil" midnight, not a big difference.

If the ITU-R were to take the advice of the colloquium it organized,
if they were to abandon the name UTC, and establish a new
international broadcast time scale with a new name, then the
operational systems of the world receiving those broadcasts would not
notice.  There would be some rewriting of documents, specifications,
and some extra work streamlining zoneinfo.

It's not just an engineering tradeoff, it's a political tradeoff.
The question for the NTP implementors, kernel hackers, application
writers is whether it's worth waiting to see if the current political
impasse about UTC can be broken, or whether it seems better, easier,
and quicker to lobby the ITU-R delegations to abandon the name UTC
and give a new name to a broadcast time scale without leaps.

Either way we will have to handle another decade of leap seconds
before the broadcast time scale can change its characteristics.

replies directed to the LEAPSECS list

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jan 2009 13:57:24 -0500

> ever will be a negative one.

I disagree. In the 1970's, the excess LOD was as much as 3 msec.
After going down some, the mid 1990's it rose to around 2 msec.
Now, it is around 1 msec.

Here is a plot

http://www.iers.org/MainDisp.csl?pid=95-100

Only the long period variations count for leap seconds - the seasonal  
and other high frequency
oscillations tend to average out.

In the early part of the last century (~1905), it decreased by ~ 5  
msec in a year or so.
If that happened right now, it would go to ~ -4 msec negative, and we  
would be seeing
2 negative leap seconds or more per year. Even if the decrease from  
1975 to 1985 happened again, it
would be at -1 msec, and we would have a negative leap second every  
two years or so.

What is a reasonable assumption is that we would likely have a year or  
more warning of the
likelihood of a negative leap second.

Regards
Marshall Eubanks

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jan 2009 12:21:58 -0500

Here is a plot

Regards
Marshall Eubanks

---

From: Rob Seaman <[email-masked]>
Date: Fri, 9 Jan 2009 14:26:00 -0700

Follow-ups to [email-masked].

Marshall Eubanks wrote:

> Only the long period variations count for leap seconds - the  
> seasonal and other high frequency oscillations tend to average out.

Those plots are almost a decade out of date.  The more recent trend is  
here:

	http://tycho.usno.navy.mil/leapsec.html

Obviously we already knew it had leveled off (even risen a little) in  
the last few years since we've had two leap seconds in three years.

> msec in a year or so.  If that happened right now, it would go to ~  
> -4 msec negative, and we would be seeing 2 negative leap seconds or  
> more per year.

What am I missing here?  Wasn't the episode near 1905 first a big  
deceleration before it returned to "normal"?  A slower Earth leads to  
an additional accumulation of positive leap seconds.  Here's a plot  
from Steve Allen's page that shows the large positive area under the  
curve for the 1905 event:

	http://www.ucolick.org/~sla/leapsecs/lod.png

It looks like the fall took more like 2 decades than "a year or so",  
and that the initial rise was significantly steeper.

Perhaps the USNO or IERS has some other view of this event?  References?

> Even if the decrease from 1975 to 1985 happened again, it would be  
> at -1 msec, and we would have a negative leap second every two years  
> or so.

It depends what the baseline is doing before such a decrease.  Which  
is just to say, I guess, that length of day is not well modeled by a  
Markov process.

> What is a reasonable assumption is that we would likely have a year  
> or  more warning of the likelihood of a negative leap second.

Yes, but why is this left as an assumption?  As the result of  
integrating the LOD curve, leap seconds are stabilized relative to the  
variations in the curve itself.  Figure 5 from the Arias, et.al. paper  
from Torino:

	http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf

suggests that predictions as long as three years should be possible  
even using what seems from the paper to be a fairly simple minded  
approach.  Since the Bulletin A methodology has presumably been  
optimized for six month predictions, it seems likely this could be  
extended by a year or two even without relaxing the DUT1 < 0.9s limit.

Figure 4 from Arias shows residual baseline trends extending over  
several six month windows.  A purely phenomenological detrending might  
behave better in practice than some attempt at unbiased fitting of  
physical models.

Leap seconds are an engineering issue, not science - a thumb on the  
scale isn't out of the question.

Rob Seaman
National Optical Astronomy Observatory

---

From: Pavel Machek <[email-masked]>
Date: Mon, 12 Jan 2009 17:11:15 +0100

> message that indicates the current leap-second offset

Offset is not enough; you'd have to provide list of all previous leap
seconds with 'when it happened' timestamps.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "M. Warner Losh" <[email-masked]>
Date: Mon, 12 Jan 2009 10:07:12 -0700 (MST)

In message: <[email-masked]>
            Pavel Machek <[email-masked]> writes:
: On Mon 2009-01-05 11:42:35, Linas Vepstas wrote:
: > 2009/1/5  <[email-masked]>:
: > > On Mon, 5 Jan 2009, Linas Vepstas wrote:
: > >
: > >>> Arguably the kernel's responsibility should be to keep track of the
: > >>> most fundamental representation of time possible for a machine (that's
: > >>> probably TAI) and it is a userspace responsibility to map from that
: > >>> value to other time standards including UTC,
: > >>
: > >> Yes, this really does seem like the right solution.
: > >>
: > >>> using control files
: > >>> which are updated as leap seconds are declared.
: > >>
: > >> Lets be clear on what "control files" means.  This does
: > >> *NOT* mean some config file shipped by some distro
: > >> for some package. That would be a horrid solution.
: > >> People don't install updates, patches, etc.  Distros
: > >> ship them late, or never, if the distro is old enough.
: > >>
: > >> A more appropriate solution would be to have
: > >> either the kernel or ntpd track the leap seconds
: > >> automatically.  First, the ntp protocol already provides
: > >> the needed notification of a leap second to anyone
: > >> who cares about it (i.e. there is no point in getting a
: > >> Linux distro involved in this -- a distribution mechanism
: > >> already exists, and works *better* than having a distro
: > >> do it).
: > >
: > > I disagree with this. NTP will only know about leap seconds if it was
: > > running and connected to a server that advertised the leap seconds during
: > > that month.
: > >
: > > for example, if you installed a new server today, how would it ever know
: > > that there was a leap second a couple of days ago?
: > 
: > OK, good point.  Unless your distro was less
: > than a few days old (unlikely), you are faced with the
: > same problem.  Sure, eventually, the distro will publish
: > an update (which will add to the existing list of 36 leap
: > seconds -- which is needed in any case, since no one
: > has a server that's been up since 1958),  but this is
: > unlikely to happen during this install window.
: > 
: > The long term solution would be write an RFC to extend
: > NTP to also provide TAI information -- e.g. to add a
: > message that indicates the current leap-second offset
: > between UTC and TAI.
: 
: Offset is not enough; you'd have to provide list of all previous leap
: seconds with 'when it happened' timestamps.

Well, today you can ftp the leapseconds.txt file from NIST.  Of
course, that assumes your machine is on the network, and not a dumb
slave of a smart head-end that's off the net...

Warner

---

From: [email-masked]
Date: Mon, 12 Jan 2009 16:45:40 -0500

> slave of a smart head-end that's off the net...

If you're a dumb slave off a smart head-end, the sysadmin has already solved
the problem of getting files from the outside to the dumb slave, just for their
own sanity in pushing patches and *other* config file updates.

And if you're *not* getting updates pushed to you for all the *other* stuff,
the leapseconds is probably the least of your worries.