| |||||||||||||
Leaping seconds and looping serversLeaping seconds and looping serversPosted Jul 3, 2012 6:48 UTC (Tue) by josh (subscriber, #17465)In reply to: Leaping seconds and looping servers by chip Parent article: Leaping seconds and looping servers
ntp does precisely that for most normal time adjustments, which makes me wonder why it doesn't do so for leap seconds.
(Log in to post comments)
Leaping seconds and looping servers Posted Jul 3, 2012 8:51 UTC (Tue) by gevaerts (subscriber, #21521) [Link]
Because leap seconds are defined as extra seconds, not as a one-second error that suddenly appears and must be corrected for.
Leaping seconds and looping servers Posted Jul 3, 2012 12:51 UTC (Tue) by nix (subscriber, #2304) [Link]
Quite. Slewing the time over an entire day and changing the length of a second for all that time would have scientists, avionics people and so on hiring assassins to take the proposers of such an insane idea down as fast as possible. Google can do this because Google only cares about time synch, not about its absolute value down to the second. A lot of entities care more deeply about time than that.
Leaping seconds and looping servers Posted Jul 3, 2012 13:18 UTC (Tue) by Thue (subscriber, #14277) [Link]
Hopefully anybody who really cares about time already uses TAI. The article mentions the kernel should use TAI internally - the same goes for user space programs such as databases, for the same reason.
Leaping seconds and looping servers Posted Jul 3, 2012 19:02 UTC (Tue) by kleptog (subscriber, #1183) [Link]
You don't have to smear it over a whole day. For example, you could at one second before set the clock at half speed. Then time still increases monotonically.
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.
Leaping seconds and looping servers Posted Jul 3, 2012 19:28 UTC (Tue) by drag (subscriber, #31333) [Link]
Like the man says the 'smearing' is only brilliant if you don't care that the leap second happens. For some people it does matter, although this is not typical.
Leaping seconds and looping servers Posted Jul 3, 2012 19:54 UTC (Tue) by paulj (subscriber, #341) [Link]
For whom would it matter, exactly?
Leaping seconds and looping servers Posted Jul 3, 2012 19:59 UTC (Tue) by drag (subscriber, #31333) [Link]
People that need to keep accurate time keeping, I suppose.
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?
Leaping seconds and looping servers Posted Jul 3, 2012 20:08 UTC (Tue) by paulj (subscriber, #341) [Link]
For control functionality that is compromised by 10% inaccuracy, surely they should be using monotonic timers?
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?
Leaping seconds and looping servers Posted Jul 3, 2012 21:03 UTC (Tue) by drag (subscriber, #31333) [Link]
> surely they should be using epoch-based kernel interfaces
Well if I was following the discussion correctly it's those 'epoch-based kernel interfaces' that are the things being 'smeared'.
Besides that,
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.
Leaping seconds and looping servers Posted Jul 3, 2012 23:53 UTC (Tue) by xman (subscriber, #46972) [Link]
The kernel's use of UTC time was why ntpd had to do what it did, which exposed the faulty logic.
TAI is the way to go.
Leaping seconds and looping servers Posted Jul 4, 2012 3:28 UTC (Wed) by drag (subscriber, #31333) [Link]
Does anybody actually use TAI for anything?
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.
Leaping seconds and looping servers Posted Jul 4, 2012 13:26 UTC (Wed) by andreasb (subscriber, #80258) [Link]
Going by what's on the Wikipedia page, it has been corrected for altitude (normalized to mean sea level) since 1/1/1977. The former uncorrected TAI got the new name EAL.
Leaping seconds and looping servers Posted Jul 4, 2012 18:32 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> Does anybody actually use TAI for anything?
GPS does. The GPS timestamp is TAI with a fixed offset.
Leaping seconds and looping servers Posted Jul 17, 2012 17:59 UTC (Tue) by Baylink (subscriber, #755) [Link]
No; that's factually incorrect, I'm afraid.
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.
Leaping seconds and looping servers Posted Jul 4, 2012 11:49 UTC (Wed) by paulj (subscriber, #341) [Link]
Ah yes, the damn POSIX epoch specifies time since in Epoch in UTC. I thought it was just "seconds since epoch". :(
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?).
Leaping seconds and looping servers Posted Jul 4, 2012 14:01 UTC (Wed) by faramir (subscriber, #2327) [Link]
I have this feeling that you have just described "the stock market". If true, that would pretty much explain why everyone ends up caring.
Leaping seconds and looping servers Posted Jul 4, 2012 14:22 UTC (Wed) by paulj (subscriber, #341) [Link]
Trading requires imposing an absolute ordering - not an absolute time. You could specify order with UTC time-stamps I guess, but still you'd want a central arbiter to provide those time-stamps. Otherwise you'd need an honour system to settle trades - which surely would be open to abuse?
Leaping seconds and looping servers Posted Jul 4, 2012 17:56 UTC (Wed) by jwakely (subscriber, #60262) [Link]
You only need an ordering at the matching engine. But most participants in the markets are not running matching engines. For measuring the age of quotes and your network latency and your software latency and the latency of messages from the exchange and the latency of messages from other sources and numerous other measurements you want accurate (definitely sub-0.1s!) timestamps, that agree across multiple organisations.
Leaping seconds and looping servers Posted Jul 7, 2012 1:13 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Some people were very happy that June 30 was not a trading day!
Leaping seconds and looping servers Posted Jul 6, 2012 17:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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.
Leaping seconds and looping servers Posted Jul 12, 2012 18:59 UTC (Thu) by VITTUIX-MAN (guest, #82895) [Link]
"Anyway, the question remains: exactly who needs to have the leap-second occur as an inserted second, rather than a spaced out smear?"
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.
Leaping seconds and looping servers Posted Jul 3, 2012 20:04 UTC (Tue) by kleptog (subscriber, #1183) [Link]
Let me put it this way, if there were an option in the NTP server:
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.
Leaping seconds and looping servers Posted Jul 3, 2012 21:47 UTC (Tue) by lindi (subscriber, #53135) [Link]
Getting TAI time under GNU/Linux seems to be quite challenging. I came up with a rather hacky approach that seems to work: http://iki.fi/lindi/tai.c -- can you figure out how to clean that up?
Leaping seconds and looping servers Posted Jul 4, 2012 18:49 UTC (Wed) by kleptog (subscriber, #1183) [Link] Well, you can demonstrate it fairly easily on the command-line:$ TZ="right/UTC" date ; TZ="posix/UTC" date Wed Jul 4 18:26:24 UTC 2012 Wed Jul 4 18:26:49 UTC 2012What you need is a library that can easily open multiple timezones at once. I thought glibc could do it, but it doesn't appear to, from reading the source. However, GLib seems to have support. I would have thought the g_time_zone_get_offset() would be enough, but apparently not. Actually, even though I can open both zones I can't convince GLib to give me the answer :(. Though it must be possible.
Leaping seconds and looping servers Posted Jul 4, 2012 19:38 UTC (Wed) by lindi (subscriber, #53135) [Link]
Thanks for the pointer! If we had an easy way to get TAI I'd seriously consider using it in our internal systems since many parts already assume they can use simple substraction to get lengths of time intervals.
tai.c - why return t + 10? Posted Jul 6, 2012 4:48 UTC (Fri) by pr1268 (subscriber, #24648) [Link] 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...
tai.c - why return t + 10? Posted Jul 6, 2012 5:43 UTC (Fri) by lindi (subscriber, #53135) [Link]
"1 January 1972 00:00:00 UTC was 1 January 1972 00:00:10 TAI exactly" -- http://en.wikipedia.org/wiki/Coordinated_Universal_Time
The new block was just for clarity.
why t + 10? Posted Jul 8, 2012 1:53 UTC (Sun) by pr1268 (subscriber, #24648) [Link] 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").
Leaping seconds and looping servers Posted Jul 4, 2012 9:40 UTC (Wed) by Tobu (subscriber, #24111) [Link] Here's a little about libtai. lindi's approach is interesting as well since it uses the leap seconds table implicitly precent in Olson's tzdata, which is already regularly updated in stable distributions.
Leaping seconds and looping servers Posted Jul 3, 2012 23:52 UTC (Tue) by xman (subscriber, #46972) [Link]
All this does though is change which assumptions about time break. For a particular use case, this might be the right thing to do, but in general, one approach has as much a chance of triggering a bug as the other.
|
|||||||||||||