Re: DragonflyBSD kernel clock improvements

:If Matt is only interested in the PC platform with sufficiently
:clued users, he can afford to make the choice of timekeeping a
:boot-time or even compile-time fixable just like it is in so many
:other UNIX kernels.

    Since you can't seem to stop attributing nonsense to my name, I'll
    elucidate a bit.

    The problem with the timecounter API is that it takes a kitchen sink
    approach to a problem that doesn't need a kitchen sink approach to solve.
    You are fiddling with fractional calculations on 64 bit values in three
    different numerical domains and you have switching logic to switch 
    time counters on the fly that is all entirely unnecessary.  ALL YOU
    NEED to be able to use a stable time source to calculate phase drift
    against, say, an NTP time source, is a relative count value.  No
    microseconds, nanoseconds, seconds, or fractional 2^X junk is required.
    You certainly don't need to be calling nanotime() or friends.  You
    have an API to do that, the problem is that it's mixed in with everything
    else.

    You just need a count value.  That value, say from a TSC, can be used
    as the basis for phase drift calculations from things like NTP sources
    and then used to compensate the master clock (e.g. say the 8254) without 
    'switching timecounters' or doing anything fancy.  In fact, you could
    use *several* time sources in parallel and choose the one with the 
    lowest drift on an ongoing basis... all without having to mess with
    the system's core clock functions.  Even without a temperature
    compensation resistor a crystal oscillator is not going to drift so
    quickly that software can't compensate for it a few times a second
    given another more accurate time source.  There is no reason and no
    need to 'integrate' that alternate time source into the core of the
    system.  It's unnecessary, it's a waste of time, and it introduces
    an excessive amount of complexity.

    So, yes, I am ripping timecounter out of DFly... because it's ridiculous
    overkill.  

					-Matt