New blog draft on the TESTFRAME debacle

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> > Alas, "say more" is not really actionable advice.  Can you tell me what
> > seemed bogus to you?
> 
> Using the term PLL.

But that's how the code is organized.  In the absence of a PLL it
doesn't slew.  Or am I missing something here?

> > MacOS, Windows, and ... damn, I don't remember which BSD it was (not
> > FreeBSD).  What the oddballs lack is ntp_adjtime().  They can only step, not
> > slew. 
> 
> Slewing the clock is not a PLL.  PLL's need feedback.  There is no feedback 
> involved in a simple slew.
> 
> What's the real problem with step rather than slew?

*Really* slow convergence, like on the order of days.  We tried this.
I remember you expressing surprise at the time that the no-PLL case
still worked at all.

> > Complexification #1.
> > Complexification #2.
> > Complexification #3
> 
> I didn't get the message from that blog that the problem was that making it 
> work was going to involve too many complexities rather than a can't-fix road 
> block.  But I probably wasn't looking for it.

I think both things are true with respect to different blockers.

> How close did you get?

I just about got past the first blocker - complexity of the network-plumbing
hairball - after I realized that the async-IO code code could go away.  That
ran me up against the second blocker, the code-path split.  While I was trying
to work my way around that one, studying replay logs in detail, I grasped the
free-variable issue.

> How much could we learn if we had something working to experiment with?

Depends on your definition of "working".  At this point I think the
odds are against check files having enough long-term stability to make
replay really useful.

While I could turn out to be wrong about that, getting to the point where
I could check it would have time and complexity costs large enough that
I don't want to go there.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>