Re: timecounters

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Nov 13, 2021 at 02:25:22AM +0000, Emmanuel Dreyfus wrote:
> x86 TSC: cycle count from CPU register. Very quick to read, but unreliable if 
> CPU frequency changes because of power saving. Also each CPU has its own
> value (how do we cope with that?)

It's even more complicated. For older x86 CPUs, different counts could
go at different frequencies, but this was fixed around the Netburst era
or so. That said, they frequently have issues when used in SMP systems.
It's a high resolution timer.

> x86 i8254: Plain old Intel clock chip, slow but reliable and needs locking
> to read.

Slow and limited resolution. You really want to avoid it if at all
possible. To put slow into perspective and from memory, it is an order
of magnitude slower than the PCI based timers and two orders of
magnitude slower than LAPIC and TSC.

> ACPI-Fast, ACPI-Safe: Needs multiple read to get a good value. 
> I have to read more of the paper to understand why. Also the
> difference between ACPI-Fast and ACPI-Safe is not yet clear to me.

You should only see the safe variation unless it is very old hardware.
This timecounter should be considered the safe default for x86 with a
reasonable good resolution (1MHz or higher) and not too slow access. The
first generation had some issues with possible 64bit read splits, but
those are not that relevant in practise.

> dummy: not documented. sys/kern/kern_tc.c says it is a fake timecounter
> for bootstrap, before a real one is used. .

Correct.

> clockinterrupt: not documented at all?  See sys/kern/kern_clock.c

This basically is a tick counter. Don't use at all if you have any
actual timecounter.

> lapic: not quite documented in lapic(4)

This uses the counter register of the LAPIC, which is based on the CPU
bus frequency and coherent even on older x86 CPUs. It's slower than the
TSC but still much faster than e.g. the HPET. Works reasonable well
until we switch away from the periodic time interrupt. Lower resolution
than TSC, but typically much higher than HPET.

> ichlpcib: loosely documented in ichlpcib(4)

This is the hardware also used by ACPI-Safe, but comes with a bit less
overhead.

> hpet: documented in hpet(4)

If TSC or LAPIC doesn't work, this is generally the best choice. It has
a decent resolution (in the MHz range) and often half the access time
than the PCI timecounters (ichlpcib).

> Ans that is only the beginning. grep tc_name sys/kern/arch sys/dev yields
> a lot of results. For instance, arm has  bcm2835_tmr, clpssoc, a9tmr, gtmr, dc21285_fclk, gpt, digctl, mvsoctmr, dmtimer, saost_count, MCT, hstimer, Timer 2, LOSC, timer2, timer3, tmr1_count
> 
> Does it make sense to document all of theat?

I don't think there is generally a point in documenting all the MD ones.
X86 is somewhat special as there are often two choices with different
advantages and disadvantages. Most other platforms have a pretty clear
winner.

Joerg