[ntp:questions] Re: NTP server with Rubidium PPS
Paul.Croome at softwareag.com
Paul.Croome at softwareag.com
Wed Oct 12 07:02:16 UTC 2005
This display looks fine to me. The "o" in the first column of the
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 18.104.22.168?
Did you specify that in ntp.conf?
Normally I would expect to see something like ".PPS." in the refid
Mauro Fiacco schrieb:
> this is the strange situation I have:
> >> ntpq -p
> remote refid st t when poll reach delay offset jitter
> oPPS(0) 22.214.171.124 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. 126.96.36.199 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?
> 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 <maarten at kittensandcats.net>
> > To: questions at lists.ntp.isc.org
> > Subject: [ntp:questions] Re: NTP server with Rubidium PPS
> > "Mauro Fiacco" <Mauro.Fiacco at ipaccess.com> wrote in message
> > news:20051011122731.GA12755 at ipaccess.com...
> > > 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
> > questions at lists.ntp.isc.org
> > https://lists.ntp.isc.org/mailman/listinfo/questions
> Mauro Fiacco
> ip.access Ltd
> URL: www.ipaccess.com
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions