[ntp:questions] Speed of ntp convergence
Speechless
noone at nowhere.com
Mon Nov 3 05:17:00 UTC 2008
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.
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.
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/
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.
>
>
> 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