:-On [20050424 04:42], Matthew Dillon (dillon@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
:> Log:
:> Initial commit for the DragonFly home-made ntpd client. Why? Because
:> xntpd is ridiculously huge, and OpenBSD's ntpd doesn't handle frequency
:> correction properly.
:
:Doesn't this kind of nullify the work Joerg has been spending on OpenNTPD
:and liaisoning with the OpenBSD folks?
:
:--
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Yah, a little, and I apologize to Joerg for doing it, but the NTP
problem has been gnawing on me for several months now and *nobody*
seems to do it right. The OpenNTPD source was designed to be
a simple time synchronization mechanism... it was not designed for
and does not come close to the type of sophistication required to
synchronize a time base to a fine degree of accuracy, and Joerg's
been hacking it to pieces ever since he imported it to try to make
it work right.
Joerg's big beef is to write an algorithm that handles multiple
sources better. I've designed mine with that in mind... that is,
with the selection code modularized and with enough information
available to be able to code up an algorithm that makes good choices
when faced with multiple sources.
In just one day I've been able to get mine to work at least as
well as xntpd (and xntpd has the most sophisticated algorithm next
to mine). The longer the polling interval, the better it works.
With a two minute polling interval it can frequency-synchronize to
an internet time source to within +/-2ms and it's staggered linear
regressions all calculate the frequency drift to within 2 ppm of each
other on my test box.
I still have a bunch of work to do... stratum and precision recording,
variable length polling intervals, and leap year handling, and I'll
leave it to Joerg to finess the selection code. But basically the
hard part is done.
Time syncnronization sounds like it ought to be simple but it is
actually a pretty hard problem to solve properly.
-Matt