Guenter Hein, Professor Emeritus of Excellence at the University FAF Munich told us, “As far as I know, it is a problem of the PTF [Precise Timing Facility] in Italy – time has an impact on the whole constellation!”
They do (that's literally how GPS/GNSS works), but they drift, for various reasons. One of the parameters that GNSS networks broadcast is a clock correction (how far off each individual satellite's clock is, how fast it's changing, and how fast how fast it's changing is changing), and those parameters come from the ground stations.
It seems like a little drift shouldn't make that much difference, but keep in mind that the speed of light in a vacuum (or air) is about 1 foot per nanosecond, so for every nanosecond one of those clocks has drifted, that's a foot of positional accuracy you no longer have...
Nominally, yes, but the positioning error (according to the spec) is expected to be up to 425m after 14 days, growing worse over time until it hits a positioning error of ~10km at 180 days.
(later generation satellites have an 'autonav' mode that presumably makes this less severe (by using SV-to-SV ranging and such so they're not completely blind to changes), but Galileo may not have that capability or there might not be enough SVs to use that capability yet)
Wouldn't be too surprised if that ground station's job (which I guess is compensating for relativistic effects to the clocks' timing) was extended to compensate for rebooting clocks.
They do, but they’re less accurate than the ground station’s clocks. If not updated regularly, they’ll drift, with a gradual loss of positional accuracy.
we had this issues on our EC2 servers getting out of sync with other systems. Had to schedule some crontabs to ntp update yo. Maybe them EU dudes forgot to sync their clocks?
Sounds like a bug we hit at AWS a while back. The clocks on several of our instances started running at incorrect speeds. One was gaining something like 10 seconds every minute or something ridiculous like that. The rate was steady, just very far off from one minute per minute.
The Linux timekeeping system can normally deal with a clock that is steady but not the right rate by learning what correction to apply, but these were far enough off to be well beyond the maximum correction.
This only affected particular instance types, so changing to a non-affect type could fix it, but all the working types were more expensive than the types we were using which was annoying. Sometimes you could change to a working type then back to the buggy type and end up with one that did not have the problem.
There were a few people asking about this in the support forums, but apparently it was only hitting cheapskates like us who had not paid extra for support. Finally, someone paid for incident support and opened a ticket and Amazon quickly found and fixed the problem.
Guenter Hein, Professor Emeritus of Excellence at the University FAF Munich told us, “As far as I know, it is a problem of the PTF [Precise Timing Facility] in Italy – time has an impact on the whole constellation!”