The Time Lords transcended...
such simple mechanical devices many centuries ago.
The leap second did not break the internet, it wasn’t the second coming of the Y2K bug and nor did it challenge the world’s financial markets or make the Greek situation any worse. Neither did it kick Amazon.com, Netflix, Instagram or Pinterest offline. At most, the addition of a leap second to Universal Co-ordinated Time ( …
* National Physical Laboratory is still advertising the leap second
$ date; ntpq -c "mrv &1 &999 leap,srcadr,stratum"
Wed 1 Jul 15:07:44 BST 2015
srcadr=18.104.22.168, leap=01, stratum=2
$ host ntp2.npl.co.uk
ntpsvr2.npl.co.uk has address 22.214.171.124
* A large number of servers didn't, list of servers by country code:
* Google servers (time[1-4].google.com) didn't advertise the leap second, and slewed rather than stepped for the 12 hours before and after, (which was exactly by Google's design).
(Also an interesting "discussion" on systemd's use of them by default)
* And one server didn't advertise it, was OK for a while after 00:00:00 UTC, and is now about a second out
-ntp0.ovh.net .GPS. 1 u 337 1024 373 2.691 997.187 920.966
Probably due to an issue with its GPS interface
Interesting. But more disturbing is Lennart Poettering's attitude to all of this.
For a start, WTF is systemd doing controlling the time when ntpd has done so well over the years?
Secondly, his attitude is one of outstanding arrogance that (a) they are defaulting to Google's time servers that are not offered or guaranteed to work in the future, and not abiding by official NTP/UTC time keeping, and (b) he seems not to care that such defaults put in to systemd will most likely got used by others. If your defaults are not world-wide sane, DON'T PUT THEM IN AT ALL!
Interesting reading in this github thread.
Does anyone else understand NTP:
Open Source projects are of course particularly welcome to use the pool in their default setup, but we ask that you get a vendor zone when using the pool as a default configuration.
... to mean that they ask open source projects to register as a vendors, after which they are welcome to use their (vendor) pool? Or is it just my flawed understanding of the referred quote?
I think the goal of NTP's guidelines is to stop a major supplier hard-coding "generic" pool servers in to their product, as correcting any problems later is a major problem.
So what they are asking is vendors create their own pool (maybe providing their own servers as well, but I don't know if they have to, as they could be aliases of other pool servers) so the hard-coded server addresses are unique to their product(s). That way any problems it can be throttled or blocked, etc, without impacting on anyone else.
As for software projects defaulting to the generic "pool" of NTP servers, I kind of feel they should not - that anyone choosing to install such software should be made to configure it. Of course, when such software is part of an OS or application, you are back to the vendor issue again and it should be pre-configured with the vendor's pool of server names.
Incidentally, in this day and age why are ISPs not providing NTP servers and offering the address via DHCP?
What was proposed several times in that thread was that systemd, like other open source software, use the generic pool and distributions change that to their own vendor pool as part of incorporating systemd into their distribution.
And Poettering said no, he's going to carry on using Google's servers against their wishes because he's special and so is systemd. And then he locked his thread because it appeared on Reddit and he couldn't cope with the avalanche of comments saying he's wrong in addition to Google saying get off our lawn.
That's just the kind of stubbornness required to get systemd in every Linux distribution out there despite it being as welcome as as welcome as a bacon sandwich at a bar mitzvah.
And Google will probably end up doing a non-standard NTP implementation to authenticate clients and maybe if they're feeling generous get it into an RFC.
defaulting to Google's time servers that are not offered or guaranteed to work in the future
Not the first time (hah!). Doesn't seem that long ago that the Time Zone Database, providing an "everything you need to know about times and dates" service, got taken down due to some troll wielding its IP. Cue outrage.
My perspective at the time was that the rights and wrongs of the takedown were rather less important than the fact that use of said service was squirreled away in a load of software libraries, used by just about everything and yet was reliant on the good graces of one bloke maintaining it in his spare time for its existence.
As it turned out, ICANN picked up the service and the world carried on turning, although I still wonder what would have happened had the patent troll actually had legs to stand on......(!)
I finally got round to at least partly reading this paper:
In the list of 7 options in section 11.1 there's a possibility that I've not seen discussed much: instead of inserting one second at an unpredictable time, insert a variable number of seconds at a predictable time, for example on Feb 29 whenever that date occurs (every four or eight years). However, the easiest option is probably to stick with what we already have and is already implemented by the people who care about such things.
I prefer my own suggestion - make the insertion and removal of a leap second very frequent, say once per week, but arranged so they correct on average for the amount we need.
That way software developers will be forced to test their own damn code and the problems will be found and fixed.
I would say:
* make it like daylight changes only on Sat/Sun night (no less often than once a year, no more often than twice a year), e.g mid June and mid Dec
* also standardize very specific time window and slew procedure (say, one hour 00:00UTC - 01:00UTC) to be applied by all NTP servers and by all machines maintaining their own time
* anyone who really cares about precise time will apply TAI anyway
* from standarized slew procedure, accurate relation between TAI and UTC can be derived at any point during slew window (as well as after and before)
Weak point of my proposal that conversion between TAI and UTC will be more complex than it is now (due to slew), but it standarizes current practice and by virtue of this standarization it makes time between different sources comparable again. If exercised often enough, the kinks will be ironed out eventually.
My suggestion: decouple Earth Time (based on rotation, so yes it changes gradually) from Astronomical Time (based on atomic vibration, so it doesn't change), and at the same time (!) adopt a better system for Astronomical Time: we should have a decimal system for counting Astronomical Time. Because decimal is just better: it is our standardised counting system*. After all, once we leave Earth and head out into the vast nothingness of space, GMT/UTC is irrelevant anyway. So let's take this opportunity to have a more scientific way of doing things for Astronomical Time, and stick with when the sun rises and sets for our normal terrestrial business.
*please don't get started on the factorial advantages of base 12**: we have 10 fingers and that's that.
**or binary, or base 60, or anything else. Seriously. Everyone is used to decimal. End of story.
@Martin it's already decoupled, although they need to be somehow synchronized because you need (and will always need) to be able to perform conversion between the two. What you call Astronomical Time is actually Atomic Time, called TAI and what you call Earth Time is various timezones, all relative to UTC. Leap second is just one possible synchronization mechanism when one wants to keep the conversion between TAI and UTC simple. It is possible to imagine different mechanisms.
As for base-60 , well you do not have to use it. Everyone knows that counting number of seconds from midnight UTC of 1st January 1970 is perfectly accessible and universally accepted measure of time. Right?
My experience with secondocalypse: I woke up at 2am to get a glass of water. When I headed back to bed, the brightest clock in the living room - the cable TV DVR - was insistent that it was 541am, 41 minutes past my workday alarm. That set off the usual "S***! I overslept!" panic, plus a horrid, crushing despair that I wasn't going to get those 3 more hours of sleep I'd been anticipating. Then I noticed the VCR (yes, still have one) and microwave were insistent it was just after 2am.
My 2am brain couldn't handle the disagreement between the timekeeping authority figures in my life, so I tried to turn on the TV to check the DVR and found some channels dead. As best I could sort out, I hadn't left the TV on channel 541 (never go into the channel range anyway); I hadn't hit the DVR's "pause" on live TV, which was one explanation for the black screen; and some channels and the TV guide worked. A lot of squinting at a computer screen said my computer also thought it was 2am-ish, so I abandoned the mystery and went back to bed. The DVR was working fine by the time the real 5am (plus some snooze button slaps) arrived.
Would secondocalypse mess up with a cable TV network to that degree?
"A lot of squinting at a computer screen said my computer also thought it was 2am-ish, so I abandoned the mystery and went back to bed. The DVR was working fine by the time the real 5am (plus some snooze button slaps) arrived.
Would secondocalypse mess up with a cable TV network to that degree?"
Don't know but if I had been in that situation I'd just have looked at my (analogue) watch and rolled back to bed.
Broadcast days in Europe are typically defined as starting at either 05:00 or 06:00, mostly 06:00.
That might fit in with your observation of a duff time...
But most broadcasters lock to GPS and the automation software handles the differences.
I've seen really good and truly awful implementations of how this is handled.
Diskstation sent me two monthly disk health reports at shortly after midnight.
First time message time stamp 00:00:03 +0100 hit mail server at 23:44:10 +0100
Second time stap 00:00:03 +0100 hit mail server at 00:00:03 +0100
Looking back, they tend to hit the mail server at different times usually between 23:40:00 and 00:00:03, but there's always one of them.
Running version 5.1 which is a bit old.
A good number F5 boxes around the world started falling down yesterday. Turns out that some of the RH Enterprise Linux source trees they use didn't have the leap second patch applied. No customer impact in our shop since we deploy our F5 boxes in redundant pairs, but a good number of underpants were soiled during the workday.
We got this little gem of a warning about 35 minutes before showtime from F5. A team effort decoupling NTP from the F5s was finished 2 minutes before show time. 150 odd appliances....... wasn't a fun team building exercise.. F5 have some expaining to do for our company. The regional Manager i think had to have a boot surgically removed from his ar%#$....
Mikrotik's cloud core router all had the nix NTP bug and crashed.. fun for admins worldwide, including me :(
they were alerted to it in April but as usual they did nothing about it. You won't even find an apology from them on their forum to the many complaints..
but they plan to fix it soon (i.e. stop using an out dated linux kernel ! )
Biting the hand that feeds IT © 1998–2021