Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Leaping seconds and looping servers
Posted Jul 3, 2012 8:51 UTC (Tue) by gevaerts (subscriber, #21521)
Posted Jul 3, 2012 12:51 UTC (Tue) by nix (subscriber, #2304)
Posted Jul 3, 2012 13:18 UTC (Tue) by Thue (subscriber, #14277)
Posted Jul 3, 2012 19:02 UTC (Tue) by kleptog (subscriber, #1183)
I read somewhere that an NTP server (it might have been OpenBSDs) handled it by smearing it over 10 seconds, since the adjtime interface specifies a maximum slew of 10%.
Frankly I think Google's smearing algorithm is a brilliant idea. You could implement it with a handful of lines in the NTP server. (You don't need to do the lying-to-downstream bit).
Our systems were apparently protected by an upstream old OpenBSD server losing the leap-second bit so they spent the next day resyncing their clock back in line with the new time (the munin graphs are interesting). Unfortunately, the OpenBSD servers themselves didn't do quite so well, they stepped the clock back a whole second which apparently threw OpenVPN for a loop.
Posted Jul 3, 2012 19:28 UTC (Tue) by drag (subscriber, #31333)
Posted Jul 3, 2012 19:54 UTC (Tue) by paulj (subscriber, #341)
Posted Jul 3, 2012 19:59 UTC (Tue) by drag (subscriber, #31333)
I expect that for a whole host of applications having a second that is randomly different from all other seconds would be irritating. Anything dealing with automation on a assembly line would probably be irritated to know that their devices are going to have to deal with time units that are shifting goal posts. Avionics was mentioned above as well as a couple other things that I won't bother repeating.
The whole point of the leap second is to keep a second a second. When a second is not a second then what do you do to deal with that?
Posted Jul 3, 2012 20:08 UTC (Tue) by paulj (subscriber, #341)
For timestamps for record keeping, with similar requirements, surely they should be using epoch-based kernel interfaces, and doing any remaining formatting to and conversion for calendar times in userspace?
Posted Jul 3, 2012 21:03 UTC (Tue) by drag (subscriber, #31333)
Well if I was following the discussion correctly it's those 'epoch-based kernel interfaces' that are the things being 'smeared'.
If it was up to me all the programs I use would only see time in epoch UTC. That would be the only time supported by anything. It's the userspace's responsibility to present time in a human-readable format. Unfortunately that is not how people do things.
Posted Jul 3, 2012 23:53 UTC (Tue) by xman (subscriber, #46972)
TAI is the way to go.
Posted Jul 4, 2012 3:28 UTC (Wed) by drag (subscriber, #31333)
As far as scientific time keeping it's already been found to be fundamentally flawed due to the fact that they didn't take the effect of gravity into it. and is probably going to be replaced by something else eventually that is adjusted for altitude.
Posted Jul 4, 2012 13:26 UTC (Wed) by andreasb (subscriber, #80258)
Posted Jul 4, 2012 18:32 UTC (Wed) by cesarb (subscriber, #6266)
GPS does. The GPS timestamp is TAI with a fixed offset.
Posted Jul 17, 2012 17:59 UTC (Tue) by Baylink (subscriber, #755)
The problem here is not the *choice of timescale*: UTC is monotonic even over leap seconds; 58, 59, 60, 00.
The *problem* is that the kernel isn't following UTC *either*; not if it's ticking backwards. It's that *ticking backwards* part that is the problem, and I've yet to see a truly compelling reason why it should do so.
Posted Jul 4, 2012 11:49 UTC (Wed) by paulj (subscriber, #341)
Anyway, the question remains: exactly who needs to have the leap-second occur as an inserted second, rather than a spaced out smear?
People who need precise control/responses: They definitely don't want it, they need accurate relative time.
People who need 1±0.1 second accuracy to the global reference of UTC: well, that must be because they need to compare time across systems. In which case, they need some *other* system to synchronise time across those systems, such as NTP. If those systems are within one organisation, they can use NTP to do the slew in a relatively co-ordinated fashion.
So whose left? It seems to me that it must be organisations who wish to compare time to ±0.1s accuracy across systems distributed over multiple organisations, who do not normally work closely enough together that they can arrange to synchronise to anything other than UTC.
So how many such organisations exist with those kinds of requirements? What is the application? Is it even realistic to expect ±0.1s accuracy in timestamps at such scales?
Why hold the reliability of our software hostage to requirements that few likely need or care about? Would it be possible to punt to userspace, and have NTP handle the method, through an interface that allows the kernel to be agnostic about it? Wouldn't that be much much better for pretty much everyone? (Don't you need to run NTP in the first place in order to get the leap-second?).
Posted Jul 4, 2012 14:01 UTC (Wed) by faramir (subscriber, #2327)
Posted Jul 4, 2012 14:22 UTC (Wed) by paulj (subscriber, #341)
Posted Jul 4, 2012 17:56 UTC (Wed) by jwakely (subscriber, #60262)
Posted Jul 7, 2012 1:13 UTC (Sat) by BenHutchings (subscriber, #37955)
Posted Jul 6, 2012 17:31 UTC (Fri) by giraffedata (subscriber, #1954)
Ah yes, the damn POSIX epoch specifies time since in Epoch in UTC. I thought it was just "seconds since epoch". :(
Well, to be precise, there's no such thing as time since X in UTC. UTC is means of identifying a moment in time that involves year, month, day, etc. It implicitly provides a means of identifying certain intervals too, for example tells you what "February 1992" is. It doesn't deal with lengths of time (periods).
The relationship between the POSIX time representation and UTC is that the POSIX count assumes 60 seconds in every UTC minute, regardless of how long that minute actually lasts.
Posted Jul 12, 2012 18:59 UTC (Thu) by VITTUIX-MAN (guest, #82895)
Any system that has heterogenous hardware and software that nevertheless passes around time stamps, could get upset if different machines used heterogenous sources of time as well, so that this smearing wont happen in unison. That is, different ntp servers some of which smear, others not or they use different smear period and interwall.
Rare - surely, as rare as leap second problems, but have a million systems, and a few gets hitten by this hard.
Posted Jul 3, 2012 20:04 UTC (Tue) by kleptog (subscriber, #1183)
leap_second_handling = smear|strict
I'd use the 'smear' setting. Alternatively, if there was a syscall that gave me the TAI I might use that. But monotonic time is just one of those assumptions that creeps in very easily.
Interestingly, you could define a smeared time which would be mostly UTC but be convertible exactly to both UTC and TAI on demand. But for me monotonicity is the most important bit really.
Posted Jul 3, 2012 21:47 UTC (Tue) by lindi (subscriber, #53135)
Posted Jul 4, 2012 18:49 UTC (Wed) by kleptog (subscriber, #1183)
$ TZ="right/UTC" date ; TZ="posix/UTC" date
Wed Jul 4 18:26:24 UTC 2012
Wed Jul 4 18:26:49 UTC 2012
Posted Jul 4, 2012 19:38 UTC (Wed) by lindi (subscriber, #53135)
tai.c - why return t + 10?
Posted Jul 6, 2012 4:48 UTC (Fri) by pr1268 (subscriber, #24648)
Why return t + 10;?
I'm also curious about the curl braces creating a new scope but no if() / do / while() code.
I'm not trying to be critical; just a little curious...
Posted Jul 6, 2012 5:43 UTC (Fri) by lindi (subscriber, #53135)
The new block was just for clarity.
why t + 10?
Posted Jul 8, 2012 1:53 UTC (Sun) by pr1268 (subscriber, #24648)
I was then going to ask why add ten seconds, but then I found out what the ten seconds were about (scroll down to the image titled "Time scales since the cesium atomic frequency standard").
Posted Jul 4, 2012 9:40 UTC (Wed) by Tobu (subscriber, #24111)
Posted Jul 3, 2012 23:52 UTC (Tue) by xman (subscriber, #46972)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds