[ntp:questions] ntp & system without a rtc

unruh unruh at invalid.ca
Wed May 15 17:44:23 UTC 2013


On 2013-05-14, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 5/10/2013 8:30 PM, unruh wrote:
>> On 2013-05-10, Rick Jones <rick.jones2 at hp.com> wrote:
>>> Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>>>> I think you may be out of luck on this one.  If you can run NTPD 24x7
>>>> you can have the correct time 24x7.  If you can't do this, NTPD is a
>>>> poor choice.  The problem is that NTPD needs something like ten hours to
>>>> select a time source and match the time!
>>>
>>> NTPD is no speed daemon, and perhaps it is a subjective thing, or a
>>> mis-interpreation on my part, but I notice NTPD declaring sync rather
>>> sooner than 10 hours.  Rather sooner than one hour even (looking at
>>> ntpq -p output).  Now, it may indeed take it a long time to get the
>>> offset (term?) down to some acceptable level, but that depends on
>>> one's definition of acceptable and the initial distance no?
>>
>> Yes. The 10 hours is for achieving the ultimate accuracy of a few
>> microseconds offset. It has a halving time of a bit under an hour (lets
>> say 45 min) . Ie,
>> after 45 min, the size of the offsets is about 1/2 of what it
>> was before. Because of stepping it has an error of about 100ms to start
>> out.
>> If you are happy with few millisecond precision, it will only take an hour
>> or two.
>>
>> So if you start it out with the -g it will figure out is is way out
>> after a few seconds, and step. But the rate in general will still be
>> out, so it will rapidly drift away and ntpd will slowly bring the drift
>> into order.
>>
>> Thus to get from hours out to hundreds of milliseconds out should occur
>> very quickly.
>>>
>>> rick jones
>
> NTPD is NOT designed for fast convergence.  From start up to get the 
> minutes correct, NTPD will need about thirty minutes!  To get the best 
> time you are going to get, you will need to wait for about ten hours!

The question is whether this is a bug or not. Mills has bluntly stated
that, no matterr how people complain, he has no interest in making ntpd
fast. I think he thinks that this is somhow related to the stability of
ntpd, but the evidence is obscure (eg see chrony which does converge
much much faster, but it uses memory -- it remembers past measurements--
to do so. I tried to suggest that perhaps ntpd could lern something from
chrony, but that was shot down, despite the fact that the evidence is
that not only is chrony faster by a lot, but is also more accurate by
factors of 3-20 being reported. Mills is wedded to his "engineering"
Markovian model of control, which he feels has been thorougly tested to
work (probably true) and that chrony's model (which is equally
"engineering") has not been as thorughly tested (which is probably also
true, and needs to be fixed). But the people using chrony do not report
problems with instability and it is hard to see ( but that could of
course be a comment on my imagination rather than on chrony) how it
could go unstable. 


>
> If fast convergence is your goal, you can use a a program called
> CHRONY to achieve it.
>
> If your goal is to know the time +/- 50 nanoseconds You are expected to 
> operate your clock twenty-four hours a day.

tests have shown that chrony is actually more accurate than ntpd. In
part I believe this is due to its faster response. When the computer
clock slows down due to heat, chrony notices quicky, ntpd takes forever.

But it is true for eitehr that ultimate accuracy takes a while. 



>
> With a GPS Timing Receiver you can keep time +/- 50 nano-seconds. 
> Relatively few people NEED time with that sort of accuracy.  Many
> who DO need that accuracy use NTP and a Global Positioning Satellite
> to get the accuracy required.  A few of these people read this
> newsgroup.

No you cannot discipline your computer to that accuracy. While the
reports form the clock may have that precision, the interrupt latency
etc of the computer means that the best you can do is at the microsecond
level. With specialised hardware you could do better.


>
>



More information about the questions mailing list