Unruh wrote: > Evandro Menezes <evan...@mailinator.com> writes: > >> On Jul 12, 3:21=A0pm, Unruh <unruh-s...@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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
