My understanding is that version requires the local clock to be within +/- 68 years of the correct time before ntpd starts, top be able to to step once at startup beyond the panic threshold using a network source.
If you're using a refclock, my guess would be the reference clock driver or common ntpd reference clock code may be imposing a tighter requirement. This sounds like fodder for a http://bugs.ntp.org/ report. Cheers, Dave Hart On Wed, Feb 22, 2012 at 23:58, Echols Jr, Thomas <[email protected]> wrote: > I am using 4.2.6p5. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of E-Mail Sent to this address will be added to the BlackLists > Sent: Tuesday, February 21, 2012 3:43 PM > To: [email protected] > Subject: Re: [ntp:questions] ntpd -g option > > Echols Jr, Thomas wrote: >> my only conclusion to make is that ntp is rejecting the >> times because they are several years ahead of the system clock. >> When the system clock is set to something closer to the >> times coming in from the reference clocks, >> ntp will recognize them and sync the clock which means >> the -g option isn't doing what I would expect. > > Which release of ntpd 4.2.6p5 , 4.2.7p258 ? > > -- > E-Mail Sent to this address <[email protected]> > will be added to the BlackLists. > > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
