Re: DragonflyBSD kernel clock improvements

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Sat, 24 Jan 2004 12:31:13 -0800 (PST)
:I think this was subject to Brucification last it was raised on our
:lists.
:
:>    If you are using the 8254 as your wallclock, then you will see a
:>    significant 'speed up' of the wall clock at higher hz settings.
:
:Unless you have replaced timecounters this is not true.  Timecounters
:are insensitive to how your Hz ticks, as long as it does it often
:enough.  (You should probably pull in the code from -current though,
:the 4.x code has some marginal issues).

    The problem with the timecounters is that they create incredible 
    inconsistencies depending on which counter you use, various pieces of
    hardware, your hz frequency, and the phase of the moon.  The timecounter
    code is ridiculously complex and unnecessary junk and I will be ripping
    it all out soon.  Every last bit of it.  I'm just going to use the 8254's
    timer 0 for a general variable reload interrupt timer feature for which
    the hz tick will only be one compoenent, and either timer 1 (speaker
    gated off) or timer 2 to calculate the elapsed time in the timer 0
    interrupt or from other places.  The other timers, if available and
    considered more stable, could be used as a passive PLL to compensate
    for the 8254's drift but that's as far as I will go.

    By guarenteeing that the timer 0 interrupt rate is always at least
    full-counter-load divided by 3 (18.3ms), absolutely nothing fancy need
    ever be done to figure current real time from, e.g. 8253 timer 1 or 2
    if they are set with a full count reload.

    No apic timer.  No acpi timer.  No TSC garbage.  none of that.

						-Matt
Received on Sat Jan 24 2004 - 11:31:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC