From: "M. Warner Losh" <imp@bsdimp.com>
To: alan@lxorguk.ukuu.org.uk
Cc: mayer@ntp.isc.org, linasvepstas@gmail.com, david@lang.hm,
hancockr@shaw.ca, kyle@moffetthome.net,
slashdot@jameshallam.info, goodgerster@gmail.com,
davidn@davidnewall.com, linux-kernel@vger.kernel.org,
ntpwg@lists.ntp.isc.org, pretzalz@techhouse.org,
burdell@iruntheinter.net, nick@nick-andrew.net,
jeff@kosowsky.org
Subject: Re: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
Date: Wed, 07 Jan 2009 12:42:01 -0700 (MST) [thread overview]
Message-ID: <20090107.124201.-1760127186.imp@bsdimp.com> (raw)
In-Reply-To: <20090107193127.0bec8ad8@lxorguk.ukuu.org.uk>
In message: <20090107193127.0bec8ad8@lxorguk.ukuu.org.uk>
Alan Cox <alan@lxorguk.ukuu.org.uk> 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
next prev parent reply other threads:[~2009-01-07 19:44 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-02 19:25 Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009 Linas Vepstas
2009-01-02 20:04 ` Diego Calleja
2009-01-02 20:25 ` Robert Hancock
2009-01-03 6:32 ` David Newall
2009-01-03 6:37 ` Ben Goodger
2009-01-04 8:43 ` David Newall
2009-01-04 9:00 ` Kyle Moffett
2009-01-04 10:03 ` David Newall
2009-01-04 11:13 ` david
2009-01-04 23:15 ` David Newall
2009-01-04 23:25 ` Chris Adams
2009-01-05 0:01 ` David Newall
2009-01-05 0:41 ` Alan Cox
2009-01-05 8:43 ` David Newall
2009-01-05 19:47 ` Alan Cox
2009-01-05 0:29 ` david
2009-01-04 23:37 ` David Newall
2009-01-05 1:05 ` david
2009-01-05 0:14 ` David Newall
2009-01-05 0:21 ` Ben Goodger
2009-01-05 6:34 ` David Newall
2009-01-05 23:03 ` Linas Vepstas
2009-01-05 0:44 ` Alan Cox
2009-01-05 5:48 ` Linas Vepstas
2009-01-05 14:33 ` Nick Andrew
2009-01-05 16:08 ` Linas Vepstas
2009-01-05 17:51 ` david
2009-01-05 17:42 ` Linas Vepstas
2009-01-06 2:27 ` john stultz-lkml
2009-01-06 4:53 ` Linas Vepstas
2009-01-06 5:00 ` Linas Vepstas
2009-01-06 19:40 ` [ntpwg] " M. Warner Losh
2009-01-06 19:50 ` M. Warner Losh
2009-01-07 3:50 ` Danny Mayer
2009-01-07 4:52 ` Linas Vepstas
2009-01-07 10:03 ` David Newall
2009-01-07 17:24 ` M. Warner Losh
2009-01-08 16:51 ` Magnus Danielson
2009-01-07 14:34 ` Danny Mayer
2009-01-07 15:42 ` Linas Vepstas
2009-01-07 19:23 ` Danny Mayer
2009-01-07 16:04 ` john stultz
2009-01-07 17:36 ` M. Warner Losh
2009-01-07 17:39 ` M. Warner Losh
2009-01-07 19:31 ` Alan Cox
2009-01-07 19:42 ` M. Warner Losh [this message]
2009-01-08 3:57 ` Danny Mayer
2009-01-08 4:42 ` M. Warner Losh
2009-01-08 10:48 ` Alan Cox
2009-01-08 10:56 ` Alan Cox
2009-01-08 22:22 ` David Mills
2009-01-08 15:02 ` M. Warner Losh
2009-01-08 18:57 ` Marshall Eubanks
2009-01-08 20:09 ` Steve Allen
2009-01-12 16:11 ` Pavel Machek
2009-01-12 17:07 ` [ntpwg] " M. Warner Losh
2009-01-12 21:45 ` Valdis.Kletnieks
2009-01-06 2:31 ` Nick Andrew
2009-01-06 1:59 ` David Newall
2009-01-06 2:18 ` Chris Adams
2009-01-06 2:51 ` Nick Andrew
2009-01-06 9:40 ` Alan Cox
2009-01-07 1:17 ` Nick Andrew
2009-01-07 9:37 ` Alan Cox
2009-01-07 9:46 ` David Newall
2009-01-07 9:54 ` Alan Cox
2009-01-07 10:18 ` David Newall
2009-01-07 10:52 ` Alan Cox
2009-01-07 13:45 ` David Newall
2009-01-07 14:10 ` Alan Cox
2009-01-07 14:36 ` David Newall
2009-01-07 15:40 ` Alan Cox
2009-01-10 9:46 ` David Newall
2009-01-07 22:13 ` Chris Adams
2009-01-07 13:33 ` Chris Adams
2009-01-07 13:37 ` Alan Cox
2009-01-07 14:12 ` David Newall
2009-01-07 14:09 ` David Newall
2009-01-07 21:42 ` Chris Adams
2009-01-04 11:35 ` Valdis.Kletnieks
2009-01-05 0:08 ` David Newall
2009-01-06 3:53 ` Valdis.Kletnieks
2009-01-04 17:20 ` Kyle Moffett
2009-01-03 7:00 ` Chris Adams
2009-01-04 8:41 ` David Newall
2009-01-02 20:29 ` Linas Vepstas
[not found] ` <8752a8760901021328t545a0327v58faebe1e921680a@mail.gmail.com>
2009-01-02 21:29 ` Ben Goodger
2009-01-03 0:21 ` Chris Adams
2009-01-03 2:23 ` Duane Griffin
2009-01-03 3:45 ` Linas Vepstas
2009-01-03 4:41 ` [PATCH] " Chris Adams
2009-01-03 4:52 ` Duane Griffin
2009-01-03 18:01 ` [PATCH] v2 " Chris Adams
2009-01-03 19:04 ` Duane Griffin
2009-01-03 20:01 ` Linas Vepstas
2009-06-08 2:18 ` Ben Hutchings
2009-06-18 22:34 ` Chris Friesen
2009-06-18 22:58 ` Ben Hutchings
2009-06-18 23:48 ` Chris Friesen
2009-01-06 2:21 ` john stultz-lkml
2009-01-06 2:25 ` Chris Adams
2009-01-06 4:35 ` Linas Vepstas
2009-01-03 3:49 ` Linas Vepstas
2009-01-03 4:02 ` Ben Goodger
2009-01-03 4:46 ` Duane Griffin
2009-01-03 4:50 ` Ben Goodger
2009-01-03 22:58 ` Jeffrey J. Kosowsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090107.124201.-1760127186.imp@bsdimp.com \
--to=imp@bsdimp.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=burdell@iruntheinter.net \
--cc=david@lang.hm \
--cc=davidn@davidnewall.com \
--cc=goodgerster@gmail.com \
--cc=hancockr@shaw.ca \
--cc=jeff@kosowsky.org \
--cc=kyle@moffetthome.net \
--cc=linasvepstas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mayer@ntp.isc.org \
--cc=nick@nick-andrew.net \
--cc=ntpwg@lists.ntp.isc.org \
--cc=pretzalz@techhouse.org \
--cc=slashdot@jameshallam.info \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox