Date: Sat, 24 Jan 2004 12:31:13 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: current@freebsd.org Subject: Re: DragonflyBSD kernel clock improvements Message-ID: <200401242031.i0OKVD8A037265@apollo.backplane.com> References: <44827.1074974041@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401242031.i0OKVD8A037265>