[ntp:questions] Speed of ntp convergence

Unruh unruh-spam at physics.ubc.ca
Wed Nov 5 23:49:36 UTC 2008


I will top post this reply since there is too much garbled nonesense.

ntp is capable of disciplining the local clock on a run of the mill PC with
a $60 GPS receiver to a few microseconds. So lets take that as the
standard. 

The question I have is why, given a poll interval of 16 seconds, the time
constant of the convergence  of ntp is 1 hour. This is a technical
question, which you seem incapable of answering. 

Could I, if I designed a thermally issolated system and a better clock
source get that long term accuracy of the system  down to 1 ns? Yes. I could. It would
be stupid  for the purpose ( keeping other machines on time) since the transfer of 
time to any other computer via the net  would degrade
that accuracy to tens of microseconds, so all of the work to get the machine down to nanosecond 
accuracy would be wasted,  but I could do so.  But that would still be
irrelevant to the question. 

ntp has a slow convergence, a slow reaction to errors. But as I thought I
understood the algorithm, that timescale was of 
the order of 16 times the poll interval. Mine is 200 times
the poll interval. That indicates one of three things. 
a) I do not properly understand the design of ntp and a time constant of
200 times the poll interval meets the design criteria. 
b) There is some parameter in my ntp that has been misconfigured 
c) There is a bug in ntp.  I would think that even you should be
interested in bugs in ntp being fixed.

The only reason I post here is because of the third possiblity. No-one,
except perhaps me, is interested in the first two nor do I expect them to
be. 


Speechless <noone at nowhere.com> writes:

>On Mon, 03 Nov 2008 06:25:15 +0000, Unruh wrote:

>> Speechless <noone at nowhere.com> writes:
>> 
>>>On Sat, 01 Nov 2008 03:17:15 +0000, Unruh wrote:
>> 
>>>> Just another data point on the behaviour of ntp. My ntp went down (
>>>> due to something removing the ntp user from the password file).
>> 
>>>Something?  FULL STOP!  I'd consider the machine to be compromised and
>>>in need of a rebuild from scratch.
>> 
>> Nope. It was probably the fact that on Mandriva ntp is given the uid of
>> 498, while my user uids start at 200. Thus when my script changes the
>> users,  from a master file, it wiped out the ntp user from the one
>> machine on which ntp was running. It is stupid that ntp was assigned
>> such a high uid.
>> 

>Okay, that reduces but does not eliminate the possibility.  

>> 
>> 
>>>Root Kits are known to diddle with the machine's clocks/timers in order
>>>to steal machine cycles undetected.  In order to make the root kit work,
>>>the intruder most likely had to disable ntp, because it also diddles
>>>with the machines clocks/timers and interferes with the functioning of
>>>the root kit.
>> 
>>>[snip]
>> 
>>>> But never mind my concern about the markovian system feedback system
>>>> ntp uses. That argument I am sure everyone is tired of. What concerns
>>>> me is the long (1hr) time constant of the feedback loop, about 200
>>>> times longer than the poll interval. Ie, it does not seem to me that
>>>> ntp is fulfilling its design criteria.
>> 
>>>If you've had a root kit installed on your machine before starting ntp,
>>>ntp will no longer be seeing the time in your machine, it will most
>>>likely be seeing whatever fake time the root kit decides to show it at
>>>any given instant, so it really should not be a surprise that ntp might
>>>take a bit longer to figure out what it is converging to. :)  The fact
>>>that ntp actually does converge under these conditions only attests to
>>>the robustness of its design.
>> 
>> You are riding off into the desert on your false assumptions.

>The only assumptions I've made so far are that:
>a) you possess a modicum of intelligence and
>b) you are experiencing a genuine problem not encountered by anyone else

>Thank you for setting me straight about my assumptions...you'll be added
>to my kill file in a moment...

>> 
>>>If you are serious about having accurate and reliable time, you ought to
>>>be running on dedicated hardware with an embedded Operating System that
>>>can not be compromised.  There is a good How-To Build A Stratum One Time
>>>Server published here:  http://www.febo.com/pages/soekris/
>> 
>> All systems can be comprimized. But that is irrelevant. An ordinary run
>> of the mill computer with $60 worth of parts can nowadays be a good
>> stratum 1 server. And even your dedicated machine can go down-- disk
>> error, hardware wearout, long power failure, .....
>> 

>You obviously have not looked at the web site above to study in depth 
>and learn what it really takes to build a stratum one time server that 
>meets the requirements of a discriminating time freak.  If the $60 pile 
>of parts running your ntp was good enough to meet _your_ requirements, 
>you would not be in this news group moaning and groaning about ntp.

>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.

>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
>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.

>Your other opportunity, to do something DIFFERENT, might be to put the 
>pile of crap running your ntp into the thrash bin and to acquire 
>timekeeping hardware with a proven track record for meeting the 
>requirements of a discriminating time freak and, to run a DIFFERENT 
>Operating System on said hardware that has a proven track record in 
>demanding timekeeping applications.  For the discriminating time freak, 
>Linux is not the Operating System to use.  Yes, some do use Linux, 
>but not the discriminating connoisseurs of time.

>There are a number of resources on the web, in addition to the one I've 
>referenced, that provide a step-by-step how-to for building a stratum 
>one time server capable of tracking true UTC within a bandwidth 
>of less than 150 nanoseconds, all within the budget of a typical cash 
>strapped university researcher; however, building such a project entails 
>allocating and expending a bit more in effort and resources than just 
>$60 for a pile of parts slapped together by someone who is unable to 
>demonstrate that there is some congruence between academic credentials
>and innate intelligence he might possess.

>> 
>>>And, if you are going to go as far as to build a stratum one server
>>>described above, then make sure you go all the way and plug it into a
>>>good UPS to ensure that your time server never goes down.  That way, ntp
>>>will just do its thing and you won't have to deal with the short
>>>comings, perceived or otherwise, of ntp at start up.
>> 
>> "That's not a bug-- that is just something to avoid asking the program
>> to do."
>> 
>> But still no answer-- why is the time constant 1 hour when the poll
>> interval is 16sec?

>In your case, the answer most likely lies in the realm of the ephemeral...
>perhaps better known to you as the Heisenberg uncertainty principle.


>> Note that this ALSO affects the ability of the system to respond to temp
>> changes.
>> 

>Time freaks keep their time servers at a stable temperature.  An 
>inexpensive way to stabilize the temperature is to place the time server 
>into a cavity of a large thermal mass.  What you use for a thermal mass
>is left to your creative imagination.  One example comes in the form of 
>a 250kg cast iron truck engine block, that can be sourced from a local 
>auto wrecking shop for little more than the cost of delivery.  Add some 
>fiber glass bat insulation at strategic places to limit air circulation 
>and you are good to go.  




More information about the questions mailing list