Re: [LEAPSECS] Bulletin C and all that
I realized I hadn't updated the printed header: Domain Name IPv4 DecodedFlags bulletin-c.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0) latest.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0) In case it wasn't clear, these addresses are live now (with a short TTL): % dig +short bulletin-c.leapsec.com a c49.leapsec.com. 250.10.36.152 % dig +short latest.leapsec.com a c49.leapsec.com. 250.10.36.152 That is, TAI-UTC will equal 36s after 2015.5 where 2015.5 = 1972 + (10 + (250-248) * 256) / 12. If we converge on a different consensus encoding I'll update the zone file. Or will delete the entries at the end of the experiment if the consensus is that DNS is insufficiently persuasive. (And the owner of any domain that later can't commit to maintaining an up-to-date replica should do likewise.) Regarding usage the client code for retrieving an encoded address should be prepared for name resolution to fail, either because the network is inaccessible or the entry is missing / stale, e.g.: def get_addr(host): try: for res in socket.getaddrinfo(host, 0, socket.AF_INET, socket.SOCK_STREAM, 0, 0): af, socktype, proto, canonname, sa = res addr, port = sa break except socket.gaierror: addr = 0.0.0.0 return addr Decoding will then throw an error and the client does whatever is appropriate, e.g., read a locally cached value or try a different name / method. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Yes, there have been bugs (and shortcomings, or at least trade-offs) with leapsecond propagation in the NTP codebase over the decades. Upgrading software is a good thing. That can be ancient release + patches or current supported software that has patches. Please see http://queue.acm.org/detail.cfm?id=2717320 for more information. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The leap second, deep space and how we keep time -Brooks
The marketplace.org article quotes Bob Tjoelker as saying his team, and deep-space missions in general, can handle leap seconds. I've known Bob Tjoelker for years. He's a super-scientist designing super-clocks. Since some of those clocks are space-qualified, he is literally a rocket scientist. But it should also be noted that the marketplace.org article did not point out that most of us are not at his level. Also, they chose not to quote him about concerns he expressed about other systems. As an example, last week some GPS receivers (of different models) apparently implemented the coming leap second as soon as GPS began broadcasting its leapsecond-pending flag. While their jumps could have been due to something else, and the receivers did not jump with the last leap second, the coincidence raises strong suspicions that the receivers were misprogrammed.This failure was discovered because the receivers' associated NTP servers gave out the wrong time. For reference see http://lists.ntp.org/pipermail/pool/2015-January/007272.html. Equally unfortunate is that 30 servers in the NTP pool inserted a leap second last Dec 31. Even if a DNS-based reference helps with some of these issues, there would remain a host of other opportunities for failure, such as systems mis-programmed so they insert leap seconds after 23:59:59 local time instead of UTC. As always these are my personal opinions, and not those of my employer or the US Government. In that sense I note that NASA is very good at proactively preventing mistakes, and I suspect this consideration contributed to its anti-leapsecond position, which itself contributed the American government's decision to support the proposal calling for the elimination of future leap seconds after the suitable waiting period. -Original Message- From: LEAPSECS [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Brooks Harris Sent: Sunday, January 25, 2015 11:35 AM To: Leap Second Discussion List Subject: [LEAPSECS] The leap second, deep space and how we keep time -Brooks The leap second, deep space and how we keep time http://www.marketplace.org/topics/world/leap-second-deep-space-and-how-we-keep-time Much less stupid than many popular reports... -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On Jan 26, 2015, at 11:58 PM, Hal Murray hmur...@megapathdsl.net wrote: If Bulletin C contained a table of leap seconds for the next 6*N (for hopefully large values of N), a significant hassle to leap second implementation could be avoided as 6*N would approach the useful life of an embedded system for relatively small values of N and the embedded system wouldn?t have to guess based on incomplete or contradictory information like it does today (especially if this system isn?t connected to the internet). ... I don't understand this case. Can somebody give me an example of a system that needs accurate time and isn't connected to a place where it can get leap info? The simple example would be a clock, say with a nice display. But clocks drift, so it would need a way to track the current time. That means it is connected to something like WWVB or GPS, and they both provide leap-pending announcements. A “cold spare” that’s sitting on the shelf powered off for more than 6 months. When the original fails, the hot spare is returned to service and must wait an additional ~30 minutes to get the latest almanac before it can recover UTC time from GPS time. This 30 minutes of down time puts the system at 4 9’s of reliability, and is an unacceptable delay. With a pre-computed table of leaps for several years, this delay could be avoided, and the system can return to service much faster. GPS time can be recovered in 1 minute (and sometimes faster if you know your lat/lon a priori), so the potential savings here is rather large. Sure, you could power these units up from time to time to have them get the latest leap info, but that takes man power, time, planning, coordination as well. All that cost and bother would be eliminated with a table spanning several years. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On 27 January 2015 at 23:03, Warner Losh i...@bsdimp.com wrote: ... A cold spare that's sitting on the shelf powered off for more than 6 months. When the original fails, the hot spare is returned to service and must wait an additional ~30 minutes to get the latest almanac before it can recover UTC time from GPS time. This 30 minutes of down time puts the system at 4 9's of reliability, and is an unacceptable delay. ... That assumes you can instantly get the cold unit off the shelf and plugged in. I suspect that actually doing that will, in most cases, take well over half an hour, and hence there goes your 4 9's, regardless of how quickly the unit can give an accurate output. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On Jan 27, 2015, at 4:15 PM, Peter Vince petervince1...@gmail.com wrote: On 27 January 2015 at 23:03, Warner Losh i...@bsdimp.com wrote: ... A “cold spare” that’s sitting on the shelf powered off for more than 6 months. When the original fails, the hot spare is returned to service and must wait an additional ~30 minutes to get the latest almanac before it can recover UTC time from GPS time. This 30 minutes of down time puts the system at 4 9’s of reliability, and is an unacceptable delay. ... That assumes you can instantly get the cold unit off the shelf and plugged in. I suspect that actually doing that will, in most cases, take well over half an hour, and hence there goes your 4 9's, regardless of how quickly the unit can give an accurate output. The time to detect a full failure of the system is measured in tens of seconds. The time to dispatch remote hands to the rack with the system in it with a trip by the cold spares room is likewise measured in high single digit minutes. The time to power down the chassis, and swap out the failed system and boot the new system is measured again in single digit minutes. Time from failure to reboot can be less than 10 minutes in most cases (though not all). Having to wait the extra 30 minutes for the almanac thus quadrupled the outage time. The system had a number of redundant elements to it, and the ability to signal when it wasn’t running in fully redundant mode, but the time spent on ‘not fully redundant’ was counted against the reliability goals. And since the redundant elements weren’t supposed to know about each other, asking the redundant element for leap information wasn’t an option, though we did find a way to store the data in multiple places so that often (but not always) we could recover it and not pay the 30 minute penalty w/o forcing operator intervention. Since this was a military installation as well, that added its own set of arbitrarily complications which were better worked around in software. And since the military was involved, much analysis was done on worst case scenarios, rather than typical scenarios which would have made the problem simpler. And yes, I’ve actually deployed systems like this, and argued for the simplifications and information sharing that would obviate the need for an almanac download. While clever and all that, they didn’t survive a worst case scenario analysis. It was utterly stupid, but also utterly avoidable if you had 5 years of leap seconds available. To make matters worse, this was the primary timing system for a well known navigation system, so any outage was amplified well in excess of its actual effect, not to mention requirements for data logging that were fundamentally at odds with fast restart. This is a real-life example of the law of unintended consequences and well-meaning good ideas... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Harlan, Harlan Stenn wrote: Yes, there have been bugs (and shortcomings, or at least trade-offs) with leapsecond propagation in the NTP codebase over the decades. Upgrading software is a good thing. That can be ancient release + patches or current supported software that has patches. Please see http://queue.acm.org/detail.cfm?id=2717320 for more information. Thanks, this is a very nice overview on the history of NTP. Anyway, we need to distinguish if there's a bug in the NTP code, or if ntpd just receives wrong data from faulty refclocks. Martin ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Tom Van Baak wrote: The truncated week numbers are a good source for potential errors I agree, but... If the current week number is off by more than +-127 then this is ambiguous. No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and there's no problem with that. In fact, in 2003 everyone got it right except for one(?) model of Motorola GPS timing receiver. So the spec is fine, GPS is fine, wrapping is fine. But yes, it is a source for errors, and one engineer at Motorola fell for it. What I mean with ambiguous is that you can't even *display* the correct leap second date if there has been no leap second for more than the number of weeks covered by the 8 bit week number. For example, IIRC the GPS satellites sent the same 8 bit WNlsf number of the last leap date for seven years when no leap second was scheduled for that long time, and after some years you had no chance to expand these 8 bits unambiguously to 10 or more bits to convert this to the real date of the last leap second event. Of course, if you only evaluate WNlsf and DNt if tls and tlsf differ (i.e. a leap second is actually scheduled) then everything is fine since the numbers have been updated accordingly. Of course this can still fail if you evaluate this in a wrong way, which is probably the problem with the GPS receivers in fact doing it wrong. The only limitation of using an 7- or 8-bit WN field like this is that it prevents GPS from announcing a leap second more than 2.5 or 5 years in advance. That's not much of a limitation. Or display the correct date of a leap second more than 2.5 or 5 years in the past. ;-) Martin ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Brooks Harris bro...@edlmax.com wrote: Agreed. Its really easier to implement end of (any) month. Checking for June and December just risks bugs and is not comprehensive anyway. But there have been real bugs due to leap indicators remaining set too long, leading to bogus leaps at the end of July. So in practice there is less risk in allowing leaps only in June and December. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin, Hebrides, Bailey: Southwest 5 to 7, occasionally gale 8, veering west 7 to severe gale 9, perhaps storm 10 in Rockall and Bailey later. Very rough becoming high, occasionally very high in Rockall and Bailey later. Rain, then squally wintry showers. Moderate or poor, occasionally good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Tim Shepard wrote: While you're at it, make sure the words June and December are also never written into the standard. Only IERS gets to pick the month, and everyone one else follows what they tell us. That goes for code, tables, scripts, standards, man pages, etc. We can assume with near-term modest earth rotation rate offsets that IERS will pick June and December, but as the offset grows then March and September, and then other 8 months are fair game as well. So if you want a standard to be robust, please avoid any hard-coded reference to preferred months. Note that the current 6 month advance warning is also not set in stone so no one standard should ever depend on that either. And also we might someday get more than one leap second scheduled in the same Bulletin C. For example, maybe someday a bulletin C might be issued that says no leap second at the end of June, there will be a leap second a the end of September, there will be a leap second at the end of December, no leap second at the end of March, and there will be a leap second at then end of *next* June.' Maybe something like all that in the same bulletin C. And maybe the next bulletin C shortly after the beginning of June would reiterate the schedule through next June and also announce what will happen at the end of September. (This is all speculation, but it would be nice if code that is written this year and deployed later doesn't become broken if changes like that happen some day.) At least the new leap second code in ntpd 4.2.8 should be able to handle this correctly, if I have understood Juergen Perlinger correctly who wrote this code. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309-14 Fax: +49 (0)5281 9309-30 Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Web: http://www.meinberg.de ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
But there have been real bugs due to leap indicators remaining set too long, leading to bogus leaps at the end of July. So in practice there is less risk in allowing leaps only in June and December. Those real bugs are better fixed at their source than worked around in this manner. Ok, easy to say and hard to do, I know. Perhaps leap indicators should not be booleans but small wrapping integers. For example GPS makes use the low order 8 bits of the week number for almanac version checks. Perhaps the same could be done for leaps, especially if they are encoded as a TAI offset integer instead of +/- yes/no booleans. Another approach is to stop distributing leap seconds as a monthly flag and instead issue a yearly set of 12 values. That way not only does everyone gets the leap schedule a year in advance but no years or months get special treatment. The TAI-UTC leap second tables simply grow by one line per year. Also, Rob, et al, did you consider sorting your tables down instead of up? That is, put 1972 at the bottom instead of the top. Most people want to know the current year and not the entire history. /tvb Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin, Hebrides, Bailey: Southwest 5 to 7, occasionally gale 8, veering west 7 to severe gale 9, perhaps storm 10 in Rockall and Bailey later. Very rough becoming high, occasionally very high in Rockall and Bailey later. Rain, then squally wintry showers. Moderate or poor, occasionally good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On Jan 27, 2015, at 8:47 PM, Tim Shepard s...@alum.mit.edu wrote: If Bulletin C contained a table of leap seconds for the next 6*N (for hopefully large values of N), a significant hassle to leap second implementation could be avoided as 6*N would approach the useful life of an embedded system for relatively small values of N and the embedded system wouldn?t have to guess based on incomplete or contradictory information like it does today (especially if this system isn?t connected to the internet). ... I don't understand this case. Can somebody give me an example of a system that needs accurate time and isn't connected to a place where it can get leap info? The simple example would be a clock, say with a nice display. But clocks drift, so it would need a way to track the current time. That means it is connected to something like WWVB or GPS, and they both provide leap-pending announcements. A “cold spare” that’s sitting on the shelf powered off for more than 6 months. When the original fails, the hot spare is returned to service and must wait an additional ~30 minutes to get the latest almanac before it can recover UTC time from GPS time. This 30 minutes of down time puts the system at 4 9’s of reliability, and is an unacceptable delay. With a pre-computed table of leaps for several years, this delay could be avoided, and the system can return to service much faster. GPS time can be recovered in 1 minute (and sometimes faster if you know your lat/lon a priori), so the potential savings here is rather large. Why does such a system need to know what time it is UTC? It seems to me if knowing what time it is UTC matters, then it must be in communication of some sort with something, otherwise why would the UTC time matter? And if it is in communication with something else, why not just fetch a table of recent leap seconds that way. Because it does. Why is this even questioned. It has to set the time on the atomic clocks to UTC. And if it is not in communication with something else, then why would it need to know what time it is in UTC? Why isn't GPS time good enough for whatever it is that it needs time for? Because it is the base time for the LORAN transmitters? It’s at the top of the food chain. And even if it is in communication with something else, why not just use GPS time? Why must it recover UTC time from GPS time?Why does it need UTC time? Because the contract said that all logging must be in UTC, even early logging, and the LEDs on the front panel of the atomic clock must be set to UTC. These items were non-negotiable. And even if it needs UTC time, why does it need it to be so accurate? Because it is the timing source for the LORAN-C transmitter, and the spec says you have to be within 10ns. It seems to me a robust system would need methods of recovering from erroneous situations where some component's notion of the time was off by a few seconds (if not tens or hundreds of seconds). If some important system cannot handle a leap second without disruption, then perhaps we should be worried about what else it can not handle, or how brittle the system is to begin with. You’d think that, but you’d be wrong. It’s a lot less brittle than you think. It’s *VERY*HARD* to restart the pulse trains if you figure out later that your notion of UTC was wrong. And you have to do it before you can start transmitting, or you’re broadcasting the wrong positions. But rather than carp at why the system wasn’t designed in a way that you think is correct, learn from this that UTC with leap seconds can present very real problems because it tends to be specified top to bottom. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On Jan 27, 2015, at 9:03 PM, Steve Allen s...@ucolick.org wrote: On Tue 2015-01-27T22:47:48 -0500, Tim Shepard hath writ: Why does such a system need to know what time it is UTC? For some devices I would expect it is because of statutory or regulatory requirements which require that it should do so. Not everyone feels able to take the course of GPS, Galileo, IEEE 1588, BeiDou, and IRNSS and 'Just Say No' to UTC. In our case, it was contractual language that was non-negotiable. There was one time, and it was UTC and that’s what was externally visible, end of discussion. They didn’t care if this made some other contractual requirements hard: time was UTC and that’s that. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] CEPT ECC viewpoint on leap seconds
The European CEPT Electronic Communications Committee ruminates on the leap second situation at ITU-R WRC-15 http://apps.ero.dk/eccnews/jan-2015/wrc-15-universal-time.html -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Tom and I seem to keep the same (early) hours... On Jan 27, 2015, at 4:49 AM, Tom Van Baak t...@leapsecond.com wrote: But there have been real bugs due to leap indicators remaining set too long, leading to bogus leaps at the end of July. So in practice there is less risk in allowing leaps only in June and December. Those real bugs are better fixed at their source than worked around in this manner. Ok, easy to say and hard to do, I know. The issue is policy versus implementation. The standard allows the end of every month, so any implementation (whether DNS or otherwise) should do likewise. The IERS June / December policy is appropriate for the current epoch - i.e., oversamples the UTC waveform - so only some of the months permitted by this encoding will correspond to leaps. One could argue - and many of us on this list did - that a better policy would be to issue a leap second every month, alternating plus and minus. Introducing a positive leap second would be to omit a negative one. This would make sure the leap code worldwide was well exercised and maintained. That is not the current policy, but the encoding would support it. If I had a time machine I might make a side trip to convince the old boys of that: http://media.npr.org/assets/img/2015/01/25/tomtoro02_custom-72d86a0f1d2051eaeebdb97cc5ce2edbdf1f7533-s1200.jpg Perhaps leap indicators should not be booleans but small wrapping integers. For example GPS makes use the low order 8 bits of the week number for almanac version checks. Perhaps the same could be done for leaps, especially if they are encoded as a TAI offset integer instead of +/- yes/no booleans. If the two flags in my suggested encoding (negative? and leap?) are concatenated they are the same as PHK's 2-bit signed 2's-complement integer. Another approach is to stop distributing leap seconds as a monthly flag and instead issue a yearly set of 12 values. That way not only does everyone gets the leap schedule a year in advance but no years or months get special treatment. The TAI-UTC leap second tables simply grow by one line per year. Or like Bulletin A which announces a year in advance every week. Prior discussions have suggested that UT1 is well-modeled enough to predict leap seconds 2-3 years (or maybe a bit more) in advance. The modeling has improved dramatically since leap seconds were introduced, it is perfectly reasonable to consider implementing a new policy. The current TF.460 standard permits this, and the proposed DNS encoding can publish information for a given month whenever it becomes available. Also, Rob, et al, did you consider sorting your tables down instead of up? That is, put 1972 at the bottom instead of the top. DNS doesn't care about order. The table is just a result of iterating over the different domain names in the client python script. See appended, with range(26,0,-1) instead of range(27). (And the final of the five values in the Decoded columns is the same as PHK's example - I concatenate the separate flags to make the same 2-bit int internally for the offset.) Most people want to know the current year and not the entire history. We don't have to choose between supporting most people and all people. Each use case can correspond to a different method. PHK wants bulletin-c.leapsec.com (or more likely his own trusted domain). This corresponds to just that, whether the bulletin announces a leap second or not. Somebody else might need only the latest / pending leap seconds, called latest.leapsec.com. Etc. These two methods happen to correspond at the moment: bulletin-c.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0) latest.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0) But they will presumably differ when Bulletin C50 is announced. Rob -- MM before after encoded crc IP Decodedflags leap26.leapsec.com - 250.10.36.152 - OK 2015 7 36 1 (1, 0) leap25.leapsec.com - 249.230.35.254 - OK 2012 7 35 1 (1, 0) leap24.leapsec.com - 249.188.34.161 - OK 2009 1 34 1 (1, 0) leap23.leapsec.com - 249.152.33.233 - OK 2006 1 33 1 (1, 0) leap22.leapsec.com - 249.68.32.220 - OK 1999 1 32 1 (1, 0) leap21.leapsec.com - 249.50.31.138 - OK 1997 7 31 1 (1, 0) leap20.leapsec.com - 249.32.30.45- OK 1996 1 30 1 (1, 0) leap19.leapsec.com - 249.14.29.193 - OK 1994 7 29 1 (1, 0) leap18.leapsec.com - 249.2.28.21 - OK 1993 7 28 1 (1, 0) leap17.leapsec.com - 248.246.27.9- OK 1992 7 27 1 (1, 0) leap16.leapsec.com - 248.228.26.174 - OK 1991 1 26 1 (1, 0) leap15.leapsec.com - 248.216.25.124 - OK 1990 1 25 1 (1, 0)
Re: [LEAPSECS] Bulletin C and all that
Tom Van Baak wrote: But there have been real bugs due to leap indicators remaining set too long, leading to bogus leaps at the end of July. So in practice there is less risk in allowing leaps only in June and December. Those real bugs are better fixed at their source than worked around in this manner. Ok, easy to say and hard to do, I know. Perhaps leap indicators should not be booleans but small wrapping integers. For example GPS makes use the low order 8 bits of the week number for almanac version checks. Perhaps the same could be done for leaps, especially if they are encoded as a TAI offset integer instead of +/- yes/no booleans. The truncated week numbers are a good source for potential errors. Especially the 8 bit WNls week number in the GPS UTC parameter set has to be untruncated to 10 or more bits by the firmware to compute the real point in time for a leap second. If the current week number is off by more than +-127 then this is ambiguous. This has rolled over several time in the period where no leap second had been scheduled for 7 years, and all the time the 8 bit week number of the last recent leap second was broadcast. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH Co. KG Email: martin.burni...@meinberg.de Phone: +49 (0)5281 9309-14 Fax: +49 (0)5281 9309-30 Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Web: http://www.meinberg.de ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
Rob Seaman sea...@noao.edu wrote: The issue is policy versus implementation. The standard allows the end of every month, so any implementation (whether DNS or otherwise) should do likewise. The IERS June / December policy is appropriate for the current epoch - i.e., oversamples the UTC waveform - so only some of the months permitted by this encoding will correspond to leaps. Exactly. (I should have said that in my original message.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: North 4 or 5, backing west 5 or 6. Moderate or rough. Rain or drizzle later. Good, occasionally moderate. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
The truncated week numbers are a good source for potential errors I agree, but... If the current week number is off by more than +-127 then this is ambiguous. No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and there's no problem with that. In fact, in 2003 everyone got it right except for one(?) model of Motorola GPS timing receiver. So the spec is fine, GPS is fine, wrapping is fine. But yes, it is a source for errors, and one engineer at Motorola fell for it. The only limitation of using an 7- or 8-bit WN field like this is that it prevents GPS from announcing a leap second more than 2.5 or 5 years in advance. That's not much of a limitation. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
If the current week number is off by more than +-127 then this is ambiguous. This has rolled over several time in the period where no leap second had been scheduled for 7 years, and all the time the 8 bit week number of the last recent leap second was broadcast. Yes, see http://leapsecond.com/notes/leapsec256.htm for a full explanation of that one. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
On Tue 2015-01-27T22:47:48 -0500, Tim Shepard hath writ: Why does such a system need to know what time it is UTC? For some devices I would expect it is because of statutory or regulatory requirements which require that it should do so. Not everyone feels able to take the course of GPS, Galileo, IEEE 1588, BeiDou, and IRNSS and 'Just Say No' to UTC. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Future Leap Seconds
If Bulletin C contained a table of leap seconds for the next 6*N (for hopefully large values of N), a significant hassle to leap second implementation could be avoided as 6*N would approach the useful life of an embedded system for relatively small values of N and the embedded system wouldn?t have to guess based on incomplete or contradictory information like it does today (especially if this system isn?t connected to the internet). ... I don't understand this case. Can somebody give me an example of a system that needs accurate time and isn't connected to a place where it can get leap info? The simple example would be a clock, say with a nice display. But clocks drift, so it would need a way to track the current time. That means it is connected to something like WWVB or GPS, and they both provide leap-pending announcements. A âcold spareâ thatâs sitting on the shelf powered off for more than 6 months. When the original fails, the hot spare is returned to service and must wait an additional ~30 minutes to get the latest almanac before it can recover UTC time from GPS time. This 30 minutes of down time puts the system at 4 9âs of reliability, and is an unacceptable delay. With a pre-computed table of leaps for several years, this delay could be avoided, and the system can return to service much faster. GPS time can be recovered in 1 minute (and sometimes faster if you know your lat/lon a priori), so the potential savings here is rather large. Why does such a system need to know what time it is UTC? It seems to me if knowing what time it is UTC matters, then it must be in communication of some sort with something, otherwise why would the UTC time matter? And if it is in communication with something else, why not just fetch a table of recent leap seconds that way. And if it is not in communication with something else, then why would it need to know what time it is in UTC? Why isn't GPS time good enough for whatever it is that it needs time for? And even if it is in communication with something else, why not just use GPS time? Why must it recover UTC time from GPS time?Why does it need UTC time? And even if it needs UTC time, why does it need it to be so accurate? It seems to me a robust system would need methods of recovering from erroneous situations where some component's notion of the time was off by a few seconds (if not tens or hundreds of seconds). If some important system cannot handle a leap second without disruption, then perhaps we should be worried about what else it can not handle, or how brittle the system is to begin with. -Tim Shepard s...@alum.mit.edu ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The leap second, deep space and how we keep time -Brooks
On Tue 2015-01-27T21:41:17 +, Matsakis, Demetrios hath writ: Equally unfortunate is that 30 servers in the NTP pool inserted a leap second last Dec 31. There is no action that the ITU-R can take which will change this kind of misbehavior in these already-deployed systems. Therefore this is irrelevant to the activities which will happen at ITU-R WRC-15, and I don't think that misdirecting attention will help the ITU-R decide what to do. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The leap second, deep space and how we keep time -Brooks
On Jan 27, 2015, at 7:18 PM, Steve Allen s...@ucolick.org wrote: On Tue 2015-01-27T21:41:17 +, Matsakis, Demetrios hath writ: Equally unfortunate is that 30 servers in the NTP pool inserted a leap second last Dec 31. There is no action that the ITU-R can take which will change this kind of misbehavior in these already-deployed systems. Therefore this is irrelevant to the activities which will happen at ITU-R WRC-15, and I don't think that misdirecting attention will help the ITU-R decide what to do. One of the arguments against leap seconds are that they are hard to get right. How many machines inserted an April 31st by mistake? Has an error like that ever happened? No. Or more likely, has anybody thought it was Feb 29th in a non-leap year? No. There have been some applications that mistakenly though Y2K wasn’t a leap year. And there were some issues with the Zune music player. And there was that unfortunate Feb 30th incident, but that was in a transition to Gregorian… :) By comparison, the list of mistaken leap second issues is legion… Isn’t that relevant to the practicability of any standard under discussion? Or am I missing your point? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The leap second, deep space and how we keep time -Brooks
On Tue 2015-01-27T20:19:14 -0700, Warner Losh hath writ: By comparison, the list of mistaken leap second issues is legion Isn't that relevant to the practicability of any standard under discussion? Or am I missing your point? Regulatory action saying that there will be no more leap seconds in radio broadcast time signals will not fix devices which are claiming the existence of leap seconds which were never announced nor implemented by the radio broadcast time signals. The false servers in the NTP pool cannot be fixed by issuing a document. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
