Mauro, This display looks fine to me. The "o" in the first column of the "PPS(0)" line means that NTP is synced to the PPS. Forget the LOCAL(0) line -- that's just a last-resort fallback and in your application it would probably be better to delete it from the ntp.conf file. If you ever see a "*" in the first column of the LOCAL(0) line, NTP has lost sync with reality and it's time to ring the alarm bells.
One thing is curious: why is the refid of the PPS server 195.66.241.3? Did you specify that in ntp.conf? Normally I would expect to see something like ".PPS." in the refid column. Paul --------------------- Mauro Fiacco schrieb: > this is the strange situation I have: > > >> ntpq -p > remote refid st t when poll reach delay offset > jitter > > ============================================================================== > oPPS(0) 195.66.241.3 1 l 45 64 63 0.000 333.850 > 0.002 > +ntp1.linx.net .1PPS. 1 u 16 64 377 10.274 333.869 > 6.482 > +ntp2.eu.level3. 195.66.241.3 2 u 18 64 377 5.707 333.990 > 19.435 > ... > LOCAL(0) LOCAL(0) 13 l 34 64 377 0.000 0.000 > 0.001 > > note that the PPS has a fudge time1 of 0.33385 > > All the offset are very similar... but the local clock is not > synchronised to any of them. > > The frequency is synchronised to the PPS through the kernel. > > ntpd will not synchronise because the offset is > 128msec. > > This server cannot be chosen as primary server because its offset is too > large (even if it has PPS)! > > Is this the way NTP is suppose to work? > > Regards, > > Mauro > > On Tue, Oct 11, 2005 at 04:26:09PM +0200, Maarten Wiltink wrote: > > Date: Tue, 11 Oct 2005 16:26:09 +0200 > > From: Maarten Wiltink <[EMAIL PROTECTED]> > > To: [email protected] > > Subject: [ntp:questions] Re: NTP server with Rubidium PPS > > > "Mauro Fiacco" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > Maarten, > > > > thank you for your answer. > > > $%&*!!! I thought I didn't send it, after realising halfway through > > that you were talking about an _unsynchronised_ PPS source. I was > > answering a different question all the time. > > > > > I understand that my NTP client should not synchronise to an offset > > > larger than the threshold. However, Rubidium sources are often > > > un-synchronised... They only offer a frequency correction signal! > > > > I was expecting to be able to use a fudge factor (time1) in order tell > > > ntpd the offset of my pps source... but without much success. > > > That all sounds right to me. I certainly have no better ideas. > > > > > I use "iburst" on my timeservers, and although I have not tested > > > without it, I expect that the results is to calculate the inital > > > offset very quickly (as you suggested). But as the offset is very > > > large... the server won't synchronise to any of the timeservers ... > > > "Initial offset" sounds suspicious. Does your NTP startup sequence > > include an ntpdate step before starting the daemon, or (much the same > > thing but preferred) start the daemon itself with the "-g" flag? > > > If the daemon is started with an offset between 128ms and 1000s and > > without that flag, it will exit. Or rather, IIUC, it will _step and > > exit_. So after then restarting it, you should have an offset below > > 128ms, from which synchronisation should be reached (assuming iburst) > > well within a minute. > > > Groetjes, > > Maarten Wiltink > > > > _______________________________________________ > > questions mailing list > > [email protected] > > https://lists.ntp.isc.org/mailman/listinfo/questions > > > -- > Mauro Fiacco > > ip.access Ltd > URL: www.ipaccess.com > > _______________________________________________ > questions mailing list > [email protected] > https://lists.ntp.isc.org/mailman/listinfo/questions _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
