[ntp:questions] Re: NTP server with Rubidium PPS
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) 126.96.36.199 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. 188.8.131.52 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.
> Maarten Wiltink
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions