| |||||||||||||
Leaping seconds and looping serversLeaping seconds and looping serversPosted Jul 4, 2012 11:49 UTC (Wed) by paulj (subscriber, #341)In reply to: Leaping seconds and looping servers by drag Parent article: Leaping seconds and looping servers
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?).
(Log in to post comments)
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.
|
|||||||||||||