Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:How do they know how accurate atomic clocks are (Score 1) 55

And indeed, this makes timekeeping difficult in general -- no two atomic clocks, no matter how precise and accurate, tick the same way, because of even minor variations in local gravity, latitude, etc. Even, like, UTC is measured in terms of a calculation based on hundreds of atomic clocks all around the world.

(also random trivia: partially because of the above, the UTC that we all sync our clocks to isn't actually UTC, it's an _approximation_ of UTC (which is why in some situations, you need to specify which UTC approximation you're using (e.g. "UTC(USNO)"). You can only get "true" UTC timestamps for events after all the various clock data around the world has been processed)

Comment Re:...and Accuracy (Score 1) 111

I guess I should also add that the clocks on the individual SVs (satellites) are also both corrected and compensated (the references above are about the GPS timescale itself, which the SVs still individually drift from). So that's at least three places there are compensations and two there are corrections. ;)

Comment Re:...and Accuracy (Score 4, Informative) 111

Well, it depends on how you define "accuracy". A clock can only ever be accurate in its own reference frame. As soon as you reach outside of the local reference frame, though, there's nothing directly tying the ticking of this clock to any other. So while atomic clocks are great for knowing how much time has passed locally, they are (in and of themselves) generally pretty useless at knowing what time it is.

"What time it is" is effectively a fabrication. UTC (the most common version of "what time it is") combines the measurements of several hundred atomic clocks around the world to get an "official" time. Several hundred clocks that are all accurate to parts-per-billion, but all existing in different reference frames, and thus all ticking slightly differently. (And as a bonus, those reference frames change as materials deep in the earth move, underground water tables change, etc, so you can't even just program an offset into each clock so that everything lines up...)

GPS clocks are actually corrected. There's at least three different corrections and compensations going on:

  1. The clocks were configured so that they would run at the right speed in orbit, by making them run at the wrong speed on the ground (this is a compensation)
  2. GPS time is 'steered' towards UTC(USNO) to keep GPS time and UTC as close as possible (this is a correction)
  3. The GPS system announces that the time differential between UTC(USNO) and GPS time is, and how fast they are diverging -- this is the A0 and A1 parameters that caused the 13usec timing anomaly in January. (This is a compensation)

Anyhow, the best way to look at the long term 'accuracy' of an atomic clock is to consider the accuracy to be the amount of uncertainty existing in passage-of-time measurements in the clock's local reference frame. And that, in and of itself, has almost nothing to do with actually knowing what time it is.

Comment Re:(TFA != Headline) == 1 (Score 1) 62

"Unusable" is a standard field in the DECOM template, see https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcelestrak.com%2FGPS%2FNANU...

And doing a little browsing, I see that SVN32 had an earlier notice: http://www.navcen.uscg.gov/?Do...

The earlier notice was of type FCSTUUFN -- Forecast Unusuable Until Further Notice: Scheduled outage of indefinite duration. And that notice says that the start time of that unusability period was 025/1500. And the start time of the unusability period in the DECOM notice you linked was 36 minutes after that: 025/1536. So, they said that it was going to be unusable around 15:00 and it was actually unusable at 15:36. And the notice itself was posted on Jan 20.

So I'm going to update my response from "I don't read that as a failure" to "definitely not a failure", barring an explicit statement otherwise by someone actually running the GPS constellation.

Comment Re:Wouldn't RAIM work around this issue? (Score 1) 62

Not in this case, because the particular error was a configuration error that multiple satellites were broadcasting (and they agreed with each other). RAIM works by noticing that a satellite differs a lot from what is expected based on what the rest of the constellation is doing... when a chunk of the constellation is all saying the same (wrong) thing, RAIM can't really do anything about it.

Comment Re:GPS WTF?! (Score 1) 62

This was not a problem where "one or two satellites" had something bad happen. Even well-designed GPSDOs had a problem with this one, since large chunks of the constellation were broadcasting a bad A0 parameter.

The best-designed, of course, went "uh, something really weird just happened with time, I'm gonna stop tracking GPS and throw an alarm," but that had nothing to do with getting disagreeing data from satellites and everything to do with good clocks realizing that a 13s jump in time meant something somewhere was wrong in ways that it's impossible to recover cleanly from.

Comment Re:(TFA != Headline) == 1 (Score 1) 62

You *could* assume that SVN23 was removed because of a hardware failure. But since SVN23 was scheduled to be decommissioned right about now (or, at least, before the launch of a new satellite next month), I'm not sure that's the assumption *I* would make.

Really, if it was a satellite failure, I'd expect the official statement to say "there was a satellite failure" rather than "the configs got screwed up when we decommissioned something". There's nothing anywhere that says there was any kind of failure (other than in process), so I'm not sure how "there was a failure" is any kind of valid interpretation of the available information.

Comment The actual problem: Bad data upload (Score 4, Interesting) 187

It looks like the actual problem was a bad data upload; Specifically, some satellites were transmitting incorrect parameters for UTC offset correction. https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.febo.com%2Fpipermail... is the posting from a gentlemen at Meinberg that has the details. http://www.usno.navy.mil/USNO/... has more information about the time offset parameters (A0 and A1) and how they interact with GPS and UTC time.

According to another message (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.febo.com%2Fpipermail%2Ftime-nuts%2F2016-January%2F095686.html), PRNs 2, 6, 7, 9, and 23 got hit. It is interesting to note that the satellite that was taken out of service this morning (PRN 32) is not in this list. It looks like the decommissioning of PRN32 was quite possibly scheduled (see http://gpsworld.com/last-block...), and even if not, a failure of that specific satellite could not have caused multiple satellites to start broadcasting incorrect offset data.

I'm really looking forward to the postmortem on this.

Comment Re:Sounds like a plan! (Score 1) 1067

Actually, the Ariane 5 loss was caused by an overflow, not a divide by zero (see first paragraph at https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2F%3Ftitl...).

Even if it were a divide by zero problem, though, the error was in the code handling flight trajectory computations; I dare say an uncaught error in the code computing your trajectory is going to put the rocket somewhere that you don't want it, regardless. So you fail in one way or you fail in a different way. I doubt there's any case where ignoring a divide by zero error (or an overflow error) would actually keep the rocket on a correct trajectory.

Comment Re:Ciphersuite Negotiation (Score 1) 89

No negotiation, replace the suite on both ends once per decade.

So, what... the Internet gets together and decides that January 1 of every year ending with '0' we'll upgrade every server, client, and embedded system in the world to the latest security protocol while disabling the previous decade's? And people whose systems are out of support or can't be patched (which would only be, what, 80% of the current internet?) are just SOL?

I think I see some flaws in your plan.

Slashdot Top Deals

Lend money to a bad debtor and he will hate you.

Working...