Interesting. Thanks. That exit is what happens if you try to adjust the time by too large a step. It's just a sanity check -- assuming that exiting ntpd is better than making a large adjustment.
I forget what the default max-step is. You can change it via the config file. You can bypass that check for the first adjustment with a -g on the command line. >> Mar 18 05:10:10 gw1 ntpd[2200]: CLOCK: Panic: offset too big: -604800.000 What time zone is your logging using? >> 59655 86030.616 NMEA(0) $GPRMC,235350,A,____.____,_,_____.____,_,000.0,31= 5.7,170322,001.5,W*__ > Note the spurious "100322" date that is 1 week in the past. I don't see a "100322". I see 17 rather than 10. I'm assuming you copied the wrong chunk from the clockstats file. > I have never come across such an ntpd abort before. This is the first time > I'm seeing it. Mostly, GPS units don't lie. > Can this condition be handled in any other way, so that the service doesn't > terminate? How should ntpd decide if the GPS is lying or the time really is off by a week? Do you have any other servers in your config file? If there are several working servers, they should out-vote a lying GPS. But the GPS has a prefer so I'm not sure what would happen. You are using the PPS in the NMEA driver. I don't think that needs the prefer. I usually run with a separate PPS driver so I get the statistics from the PPS driver. That case does need the prefer. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel