Re: Timers (was Trivial pc-speaker problem.)
: 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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 2 之 5 篇)：