David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: > I have discovered that on a cold start my Resolution SMT GPS receiver > outputs the time in GPS time, until it has downloaded enough information > to determine the GSP offset, when it switches to UTC. This particular > receiver has no battery backup (it's an evaluation board). > > I'm feeding this into gpsd, from which NTP gets its coarse seconds. > This is no problem when I have other Internet or LAN servers telling NTP > what the time actually is - NTP isn't fooled and sticks with UTC. > > However, suppose I had /only/ the GPS receiver? NTP has the GPS time > and the PPS signal for the exact second, syncs, and then a few minutes > in the time suddenly changes by 16 seconds. I would hope that then > causes NTP to step the clock onto UTC rather than GPS time. I realise > that the time for the GPS receiver to be sending UTC rather than GPS > time varies, but how long might it then take NTP to react to the 16 > second change, and alter the system clock? Both the PPS and the gpsd > are being polled at fixed 16 second intervals.
When I wrote that part of gpsd, I implemented the proper checks so that the time is only put in the SHM after the GPS receiver has indicated that it has a valid fix on the satellites. I would hope that the receiver has collected the GPS offset by that time, so that it will not put the wrong time value in SHM during a short interval. However, it has been a couple of years and many changes have been made to the code, I cannot tell you if it may have been broken. Do you really see the problem you describe above, or is it only a hypothesis of what might happen? _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
