[ntp:questions] Re: NTP server with Rubidium PPS

Mauro Fiacco Mauro.Fiacco at ipaccess.com
Tue Oct 11 15:46:19 UTC 2005


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  




More information about the questions mailing list