[ntp:questions] Speed of ntp convergence

Unruh unruh-spam at physics.ubc.ca
Mon Nov 3 06:25:15 UTC 2008


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. 



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

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


>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?
Note that this ALSO affects the ability of the system to respond to temp
changes. 



>> 
>> 
>> Here after 5.5 hours after startup is the ouput of ntpq -p
>> 
>> string[root]>ntpq -p
>>      remote           refid      st t when poll reach   delay   offset
>>      jitter
>> ==============================================================================
>> +tick.usask.ca   .GPS.            1 u   18   64  377   44.925    1.455
>> 4.252 +ntp.ubc.ca      140.142.16.34    2 u   44   64  343    0.672   
>> 0.260 0.767 *SHM(0)          .PPS.            0 l    1   16  377   
>> 0.000    1.136 0.023




More information about the questions mailing list