New information about clock fuzzing

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > *blink*   I think I just achieved enlightenment.  Gary, Hal, please review
> > the following carefully to ensure that I haven't updated my beliefs wrongly.
> 
> If there is any discussion, it's just nit-picking.  Some of it might be 
> interesting, but you have the big picture correct.

And thank you for finally saying the thing that made it all fall into place.
You have a knack for that.

> > Therefore I *deduce* that the PLL correction (the one NTP does, not the
> > in-kernel one Hal tells us is associated with PPS) requires a monotonically
> > increasing clock.  It's the simplest explanation for the way libntp/
> > systime.c works, and it explains *everything* that has puzzled me about that
> > code. 
> 
> I don't believe there is any fundamental reason why a PLL requires monotonic 
> clocks.  I don't think the concept even makes sense to a PLL.  What would be 
> the equivalent in a hardware PLL?  What if you were controlling temperature?

I dunno, but Gary said:

>Yeah.  Negative duration is pretty hard to process.  Zero duration
>leads to infinities here and there.

That sounds like he might know something we don't. Maybe he'll explain.

Aha.  I held off on sending this because I wanted to look at the code again,
and I found two interesting things:

(1) A way to hoist some code out of the time-setting critical path in
    step_systime()

(2) This Millsian comment:

 * In order to improve the apparent resolution, provide unbiased
 * rounding and most importantly ensure that the readings cannot be
 * predicted, the low-order unused portion of the time below the minimum
 * time to read the clock is filled with an unbiased random fuzz.

Interesting what he says about the relative priorities there.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>