[ntp:questions] Keeping NTP Honest

David Lord snews at lordynet.org
Mon Jul 20 03:37:03 UTC 2009


Unruh wrote:
> Evandro Menezes <evandro at mailinator.com> writes:
> 
>> On Jul 12, 3:21=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>>> The way ntp works, faster polling also means worse rate estimation and
>>> more annoyance of the providers of the time. The current setup is done
>>> that way to try to minimize the rate error, so if your sconnection to
>>> ntp goes down, your system can freewheel with the greatest accuracy.
> 
>> But that's the issue: NTP allows for good freewheeling if it comes to
>> that, provided that the system maintained in STP and in a vacuum.
> 
>> In the real world, ambient temperature changes frequently even in
>> conditioned environments, network load affects packet jitter, etc.
>> And all this also affects a system's peers, compounding the issue of
>> NTP's slow reaction time.
> 
> Use chrony. Much much faster reaction time and better clock control.
> However you must be running Linux (yet another reason to change).
> It now also has harware clock support (shm refclock) in git.
> Or use the temperature controlled ntp ( reads the temp and uses that to
> estimate the clock rate changes due to temp variations)

Well I've bitten and just in process of setting up chrony
on p4-2666 desktop that multiboots NetBSD/Ubuntu/DOS/XP the
latter two very rarely.

It's will not be too much of a task as I find all my scripts
from when I used chrony on dialup, along with chrony.conf are
still present.

Running NetBSD with ntpd, after 93 min uptime the offset is
down to 28ms vs local ntp servers at about 1ms.

Chrony started at about 120 min uptime. After 160 min, offset
is given as 1177us and I can't imagine ntp getting there that
quickly.

10 min later I'm shutting down.


David




More information about the questions mailing list