Re: cvs commit: src/usr.sbin/dntpd Makefile client.c client.h convert.c defs.h log.c main.c ntp.h ntpreq.c socket.c system.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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