[ntp:hackers] More on the clock discipline algorithm

Poul-Henning Kamp phk at phk.freebsd.dk
Sun Oct 19 10:50:34 PDT 2003


In message <3F92C785.B0ADCD6B at udel.edu>, "David L. Mills" writes:

>The rulse of the game are that in case of time step all past history is
>expunged. Security and reliability insist that no prior time values be
>believed, so the daemon starts from scratch. But, should the daemon
>assume the step was due to a frequency or time error or both?

I think the problem here is that we do not tell our code that the
localclock refclock is really not a clock but only a frequency.

If after coasting on localclock for "t" seconds you find an offset
"o", the obvious thing is to calculate o/t and look at the size of
things.  If this is in the PPM range, the our frequency estimate in
localclock were not good enough or global warming threw us off and
we can just update our frequency estimate, slew (or step) our clock
and be happy we know better now.  If the o/t number is larger than
our frequency limits, then something is hosed and we forget everything
and start over.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



More information about the hackers mailing list