On 2011-11-30, Harlan Stenn <[email protected]> wrote: > Pete wrote: >> "David J Taylor" <[email protected]> writes: >> >> >> Running with an Oncore GPS & a TAPR TAC. If I "ntpdate -b" a nearby >> >> synchronized server before I start ntpd, the offsets initially look >> >> pretty >> >> good: >> >[] >> >> Is there anything I can do to decrease the convergence time? >> >> >Peter, >> >> >Are you using a drift file, and allowing it to get a good value for the >> >drift? >> >> Yes, there is a drift file, and it was properly calculated. > > Then in this case if you use iburst ntpd should have your clock fully > sync'd to your upstream server in about 11 seconds' time. No need to > use ntpdate or sntpd to initially set the clock, just fire up ntpd with > the -g option. >
>From the looks of the data he presented, his GPS started out as 1 second offset (compared to external ntp sources) it then switched to roughly the same offset as the network sources. If his refclock source really is jumping around by 1 second interevals, then there is no way that ntpd can synchronize and he is going to get a mess. If he has peerstats log file, he can look at it and see what teh offset is of the oncore and the other ntp sources to see if it is really misbehaving that badly. Also, if it is out by 16 sec, why in the world has ntp not stepped the time? The threshold is 128ms. > H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
