[ntp:questions] Slow convergence of NTP with GPS/PPS

Nicola Berndt nb at komeda-berlin.de
Fri Oct 24 08:33:50 UTC 2008


Unruh schrieb:
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
> 
>> David Woolley wrote:
>>> Richard B. Gilbert wrote:
>>>
>>>> To turn your equipment on after months of downtime and expect it to 
>>>> lock on to the correct time with millisecond accuracy within seconds 
>>>> is asking for a hell of a lot.
>>> Not really.  He's starting a GPS receiver at the same time and that has 
>>> to lock to 50ns.
>>>
>>> Doing it on a general purpose computer is more difficult, but not 
>>> particularly impossible.
> 
>> Even with GPS and a full four satellite fix, ten seconds to synchronize 
>> is extremely ambitious!!  You can set the time to within whatever 
>> precision the hardware and software support but that is only half the 
>> problem.  You also need to set the correct clock frequency.  On a cold 
>> start, the clock frequency is a moving target as the hardware warms up.
> 
> With a minpoll of 4, just setting the phase correctly with zero drift
> compensation would at worst be out by 1ms by the next reading. And you can
> get a pretty good estimate of the drift, even if it is changing. The temp
> coefficient is not 10PPM/degree C. More like 1 or less. That means the
> first few measurements gives a pretty good estimate of the drift ( ie to a
> few PPM) and then the finer corrections can come while things settle down. 
> 
> 
> 
> 
>> I would expect to wait at least thirty minutes for the system to 
>> stabilize with both the correct phase (time) and frequency.

So i could do some more tests: I could not reproduce the strange running 
off for 200 ms and more once it was gone! The thread-starter had right 
the same issue and gave up on ntp after all.. Any ideas on this, anyone?

So now things look somewhat better, if I boot the machine without a 
driftfile, (300 and something in there! ...) it runs away for a little 
while, but not very far, some ten ms i recall. If let run then and given 
the chance to write that driftfile, I can reboot and it sets time with 
an offset of around 20-30 ms and from there on slowly tears it to zero. 
So the good news is, the heavy drifting is in control! What looks 
unneccesary is the initial offset..

Btw, I have minpoll 4 maxpoll 4 in my ntp.conf and ntpq -p says: "poll 
16". Is it the poll of ntpq -p or of ntpd?

Best regards,
../nico



More information about the questions mailing list