[ntp:questions] Speed of ntp convergence

Nicola Berndt nb at komeda-berlin.de
Wed Nov 5 22:08:33 UTC 2008

David Woolley schrieb:
> Speechless wrote:
>> b) you are experiencing a genuine problem not encountered by anyone else
> Lots of people report poor startup behaviour.  Two have abandoned ntpd 
> on this newsgroup in the last few weeks because of this.
>> It should not be necessary to spell it out for you that if you are
>> dissatisfied with the results you are getting, then you need to DO
>> SOMETHING DIFFERENT to GET DIFFERENT RESULTS that might be more to your
>> liking.
> It is perfectly valid to try and get the product improved, rather than 
> simply encouraging everyone to vote with their feet.
>> For example, my assistant runs ntp on her budget priced general purpose
>> machine and she is absolutely thrilled that her machine is able to keep 
>> time with an accuracy of "within one second" of her wrist watch.  She is
> ntpd considers accuracies of worse than about 128ms to be broken, so 
> anyone who is only interested in 1 second accuracy is either getting a 
> lot better than they expect, or doesn't really need ntpd.
> If you are only interested in 1 second accuracy, you don't get 
> convergence issues, because ntpd will go into error recovery long before 
> you reach a second.  If you are out by that much at startup, you will be 
> rapidly brought into that range.  If you go out during operation, there 
> will be an upwards of 15 minutes delay, but that will start at 128ms, 
> and the time will be abruptly corrected, normally long before it reaches 
> 1 second.  None of that really depends on the algorithms that make ntpd 
> what it is.
>> not in this news group complaining about ntp and you are.  One of the 
>> things you might try to do DIFFERENT, is to use a better quality wrist 
>> watch when checking the time on your machine.
Ok, I am not currently following the list on a per mail basis (WORK, a 
LOT, out of office, too..), but just caught this.. Still I want to 
reply, since it became a rather big topic, as it looks..

I just recently tested my ntp-(pps-)machine in a large open hall and 
found it to be unable to settle down even after a day! It looks like the 
temperature changes in this open hall environment make the machine 
jitter with values between -200 and 200 ms regularly and unpredictable. 
Whenever I checked it, values were wildly varying inbetween those.. The 
same machine was able to at least settle down after an hour or so in a 
heated inside environment. I slowly come to believe that ntp simply 
lacks switches for adjusting how drastically the slewing is done in case 
the environmental temperature is varying drastically as well.

What really bothers me is that ntp is totally capable of telling me its 
offset (and so how wrong the time /being served/ is) but not capable of 
reacting to it, due to it's programmed slowness, wich as we prove in 
some cases leads to the software being unusable.

That's too bad and not neccesary :( - I wish I was a programmer...

Best regards,
../nico berndt

More information about the questions mailing list