[ntp:questions] Re: NTP server with Rubidium PPS
maarten at kittensandcats.net
Tue Oct 11 14:26:09 UTC 2005
"Mauro Fiacco" <Mauro.Fiacco at ipaccess.com> wrote in message
news:20051011122731.GA12755 at ipaccess.com...
> 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.
More information about the questions