Re: Timer in DFly vs FBSD

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Why is the timer in DFly handled differently between the 2 OSes?  I noticed
:the main web page says that gives us fine grained timer abstraction.  How
:so?  And why does DFly want Timer 2?
:
:jm

FreeBSD uses timer 0 for its 'hz' hardclock interrupt, which is usually a
fixed 100hz or 1000hz interrupt.  But FreeBSD does *not* have a fine-grained
timer interrupt.  That is, if you want a timer interrupt to occur in 500uS
you are S.O.L.  The best you can do is +/- 1/hz.  Because FreeBSD uses a
fixed interval for timer 0 it means that it can also use timer 0 to as a
real-time clock, to calculate seconds and microseconds, though FreeBSD will
use other timers instead (TSC, LAPIC, ACPI) if possible.

DragonFly uses timer 0 for its SYSTIMER fine-grained timer interrupt, which
means that DragonFly is constantly reprogramming timer 0 for whatever the
next requested interval is.  This means that DragonFly cannot use timer 0
to calculate real time.  So what DragonFly does is program timer 2 to a
full periodic count (65536 counts then rolls and starts over).  DragonFly
can theoretically use other system timers (TSC, LAPIC, ACPI) for this,
though each has its quirks (including timer 2 which can be interfered with
by the BIOS).

At the moment I've got alternative timer support ripped out of DragonFly in
order to be able to focus on creating a consistent and reliable API.  But,
eventually, we will definitely want to add support for the other timers back
in.

The problem with these alternative timers is that they have some rather
serious quirks.  The TSC, for example, often runs slower when the cpu
is throttled.  The ACPI timer is often not properly latched by hardware and
it takes multiple reads to get a stable count out of it.  The LAPIC timer
might not exist (if there is no APIC), and so forth.  And the BIOS may munge
the 8254 timer 2.  It's really a pretty dreadful situation.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>