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

Unruh unruh-spam at physics.ubc.ca
Tue Oct 21 19:43:15 UTC 2008

nb at komeda-berlin.de (Nicola Berndt) writes:

>Unruh schrieb:

>>> I see, that's too bad then.. :( I am already using minpoll 4 maxpoll 4
>> OK, But that should have a convergence of minutes not hours. Mind you NTPs
>> habit of throwing away 7 out of 8 queries of the clock does not help.
>> (clock filter). Especially for a pps that is pretty extreme.

>Today I moved the computer to a different location to work there and I 
>found it to set its clock right after start and keep it within ms-range! 
>I didn't change anything, just shut down, drove there and turned it on, 
>so I am really confused about that. Both locations are normal rooms with 
>normal room-temerature. Well, I duplicated the system (that was why I 
>was there..) and came back home with mine and tomorrow I will see if it 
>behaves different again. Very very weird! It looks as if all of a sudden 
>the driftfile was used and before not! This is also very strange, since 
>the driftfile was (re)written yesterday, so ntp knew about it yesterday. 
>My ntp.conf also includes the driftfile location.

Sounds like the drift file was closer to being accurate. 

>>> No, the Soekris will run linux an d ntpd and the oscillator will just be 
>>> on an external little board. The computer is residing in an airport 
>>> hangar for MONTH sometimes with no powersource at all! There is 
>> Hard for it to be on all the time then. Or for it to have anthing like an
>> accurate time. And that ovenized oscillator will also be pretty useless (
>> much worse than the GPS) since it will have no power either and the crystal
>> will not be oscillating nor the oven keeping the temp constant. 

>Oh, so I got the word ovenized wrong: I understood it to be very immune 
>against varying temperature. Ok, so if it needs an heater and all, it's 
>useless in my case.

>> So, what you have is a free standing computer which must come out of a cold
>> shutdown (ie the oscillator frequency on startup will be way off its
>> frequency in steady state because it is cold) so will be far from
>> equilibrium. What is your time error requirement? Seconds, milliseconds,
>> microseconds? In such a situation ntp would probably give you a few
>> milliseconds. But it certainly is NOT designed to give you good accuracy in
>> such a situation during startup.  What are you finding?

>Well, one thing I can of course always do is to boot hte machine, let it 
>run for a flittle while and reboot it, so it boots with a warmed up 
>oscillator. This would give trouble with the driftfile, though..

>We target for millisecond accuracy. As I understand, the oscillators on 
>standard PCs are mostly cheapest crap and there are way better 
>oscillators I could use to replace the original. Is that correct?

But those cheap oscillators are actually pretty good. They have drifts of
the order of 10s of PPM (or paerhps up to 100PPM) and those are temp
sensitive. That is their main problem AFAIK. The temp sensitivity is
usually less than 1PPM/degree C.
The "way better oscillators" I think is primarily oscillators which are
temp controlled (yes heaters) and selected/adjusted.

>What I saw today was pretty much, what I was looking for: No running 
>away and stable within minutes. We also took a fan and heated up the 
>oscillator. We could watch a slow drift with ntpq -p, but nothing too 
>bad. It went away for a few ms and came back within minutes again.

>I'll look into that tomorrow..


More information about the questions mailing list