> That said NTP is very conservative in validating the stability of > clock sources. I have not delved into the code, but it is obvious > that even a refclock like a GPS receiver doesn't get any favours. Why > should it? Who knows whether the clock is dodgy or not?
The NMEA strings from low cost GPS units have a lot of noise/jitter. In particular, the SiRF units are horrible. (They are also low cost and widely available.) The time offset has a sawtooth pattern with a long time constant that would be nasty to filter out. Think of hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif > However the times he was reporting for the offsets to drop to less > than 1ms did look excessive. I've seen lots of comments about ntpd being slow to converge. I haven't investigated carefully, but they seem credible. One way to get in trouble is to have a bad drift file. You can get that if you have a warm system, shut it down, wait for it to cool off, then restart it. -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.