Re: Timers (was Trivial pc-speaker problem.)

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:  I'm a little curious.  What is the purpose of using multiple timers?
:
:
:I've read what Matt said:
:
:>    (TIMER0 is our fine-grained timer interrupt but TIMER1/TIMER2 is set
:>    to a full-count and serves as the timebase for the whole system).
:
:  ..but I'm not sure I get it.  So timer <not 0> is set for a longer
:interval (for stability?) and timer 0 works "as usual"?
:
:  But if I remember correctly, you don't have to reload the timers once
:they are set up, so you have the long-term stability anyway,
:
:  Or can timer 0 can be set for very short intervals, and timer <not 0> is
:the one that "runs the OS" N times per sec?
:...
:  A simple non-technical answer will do.  Or just point me in the
:direction of some part of the source that'll explain it.  (I did try to
:find it, but boot code .. sigh.)
:
:
:Magnus

    You got it.  Timer 0 is used for the SYSTIMERS kernel API, which is a 
    fine-grained (down to the microsecond) periodic and one-shot timer 
    subsystem.  This means that timer 0 is constantly being reprogrammed to
    whatever the next shortest interval in the queue is.  This makes timer 0 
    unsuitable for keeping track of 'real' time.

    In order to track 'real' time we use timer 1 or timer 2.  We simply set
    the timer to do a full cycle (65536 counts).  This allows us to figure
    out the current time down to approximately a ~1 uS resolution simply by
    reading the timer.  We detect overflows by noticing that the counter has
    cycled back past 0 and a fine-grained interrupt does the check often
    enough so we don't miss any.

    You might remember that FreeBSD has issues with regards to losing track
    of time when a fast 'hz' frequency is selected.  This is because FreeBSD
    uses timer 0 as a fixed periodic interrupt at 'hz' and if 'hz' is too
    high it can lose track of things.  FreeBSD implemented alternative 
    time counter detection (e.g. TSC, APM timer, APIC timer, etc...) and
    on machines which have reliable alternative timers that problem no longer
    exists, but it also means that different machine setups wind up with
    radically different timer characteristics which I think is a big mistake.
    It has caused them to pretty much ignore the 8254 problem they created.

    Since we use timer 1 or 2 with a fixed full-count interval, unrelated
    to hz, we don't have that problem. 

    Of course, we have other problems, like BIOSes which screw with timer 2,
    and slow boots when a high kern.hz is specified, but hopefully timer 1
    is reliable enough that we can just change our default to use timer 1
    to solve that issue, and the slow boot problem is also fixable (I think
    it's an issue with the DELAY function).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>