Eric S. Raymond esr at
Thu Oct 6 11:28:54 UTC 2016

Hal Murray <hmurray at>:
> esr at said:
> >> It might be useful to make sure that any workaround for
> >> OS X is general enough to handle another case.
> > It will be. We just fall back to the old BSD adjtime(2) call, which
> > everybody (even OS X) has. 
> Thanks.  That explains why/how it works and why the results are so crappy.  
> That procedure can only slew the clock, no drift correction.  The crappiness 
> will depend on your luck and/or temperature.  A crystal that happens to be 
> more accurate will drift less between corrections.

I keep finding out how much I don't know.

What is adjtimex/ntp_adjtime doing that is "drift correction" but not
clock slewing?  I thought clock slewing was wjat that call did.

Please explain so I can document this.

> In the context of TESTFRAME, we can have 2 sets of replay files.  One for 
> systems that implement ntp_adjtime, and another set for systems using adjtime 
> (no x).  So far, only OS X and OpenBSD are in the latter category.

Of course I'd already figured that out.

It's a massive drop in utility if the tests aren't really cross-platform.

It's another massive drop in utility if capture logs bit-rot rapidly
during normal development, which is what I think we're looking at now.

George Santayana famously defined a fanaticism as "redoubling your efforts
when you have forgotten your aim." I try not to be that guy.
		<a href="">Eric S. Raymond</a>

More information about the devel mailing list