[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


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 <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
> https://lists.ntp.isc.org/mailman/listinfo/questions




More information about the questions mailing list