[ntp:hackers] More on the clock discipline algorithm

David L. Mills mills at udel.edu
Sun Oct 19 15:11:32 PDT 2003


P-H,

The problem is when the source is changed to one with significantly
different offset. The TSET state has initialized for the frequency
measurement in one source, but then some time later a switch to a
different source is made. I purposely avoided factoring in the clock
discipline any knowledge of the source or source change. This makes
little evil resonances when clockhopping.

It would be possible to have the local clock driver discipline only the
frequency and leave the offset where it was at the last real source
update, which of course could be as much as the step threshold in
amplitude. That's easy; don't do anything at all except clamp the
dispersion and fake the stratum. That still wouldn't fix the problem at
hand.

The issue is whether we try to fix a corrupt frequency file or make the
dumb operator fix it. The cleanest way is not to try to fix it and make
the operator read evil confusing documents to know why and how to fix
it. My experience is nobody ever reads anything; just hollers to the
newsgroup.

Dave

Poul-Henning Kamp wrote:
> 
> 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