OSDev.org

If a scheduler orders the timer to tick unnecessarily isn't it garbage? =)

You should only have timer IRQ (PIT, etc) when you need it, like when it's time for scheduler to switch task. What's the benefit of the extra ticks? As for accounting purposes (whether for Task Manager stats or "fairer" scheduling) you shouldn't use timer for that, use something else, like RDTSC, etc.

As for better timestamps, that's (mostly*) wallclock time, which can be handled in different ways (RDTSC, reading remaining count from timer when needed, etc).

*) Haven't really decided, but I've thought about possibly ensuring that within a system (or possibly finer grained, within a file system) the file timestamps are guaranteed unique, so there's always ordering and no two files ever have the same timestamp. Not sure though..



That is quite interesting. I'm aware that tilde has been around here a long time (I've read pretty much all of the theory forum posts), and do mostly disagree with him on most topics, but that specific topic (detecting memory) is a bit odd... Though even in the earlier (2007) post he wants to probe, so in this case I don't really see any regression, but seems there's no progress either.

At least in the first post tilde is saying he wants to only support 64-bit, at which point isn't it guaranteed that either BIOS E820 is supported or UEFI is supported? Why would anyone want to probe at that point? The fact is that you have to rely on the BIOS/UEFI to a relatively large degree during boot anyway, so I don't really see much reason to not "trust" it, given that there's very little reasonable choice available.

It looks deeply like development of a schizoaffective disorder of some sort over the past decade, at least to me, having worked with people in such situations a fair bit.


Also re: ticks and different OSes, I'll throw in my NT kernel knowledge as I usually do. Windows uses a sliding scale where scheduling is based around a unit called the quantum. Out of the box on client systems, a quantum is two clock ticks, and on server systems, a quantum is twelve clock ticks. You can change which quantum size is used by switching the "Adjust for best performance of" setting in System -> Advanced -> Performance Options between Programs and Background Services, the former being the default client setting and the latter being the default sever setting.

The clock tick interval actually changes, though, and so the quantum is more of a target than a hard and fast rule. When high resolution timers are requested, the clock tick changes and the interval timer is reprogrammed. The number of clock cycles per quantum is recalculated and that is used as the new target for estimating when to see if a context switch is needed.

It gets a bit weirder internally because a thread's quantum reset value is represented in thirds of a clock tick -- in other words, the quantum reset value of a thread on a client system is 6 (two quantums broken into thirds) and on a server system, 36 (twelve quantums broken into thirds).

That's fixed quantums. Variable quantums also exist, where foreground processes have their threads' quantum reset values increased dynamically on client systems based on CPU usage and thread and process priority class. This is before priority boosts, which slide various processes up or down within their priority class to change their position in the scheduler.

A little digression:
The programmable interval timer is by far the easiest one to enable. It might be old, crude, not precise enough, but still it is relatively easy to enable and use. For every other new timer you've mentioned you need to have a working ACPI implementation. (which is tough by itself, not a thing you would want to work on just to enable some timer) In my case being easy to work with beats functionality. Sure, once (in a couple of years) I get a proper ACPI implementation I will most likely implement the other timers. This was just a little side point view, you don't need to agree, but this is what I think.

The local APIC timer is very easy to configure and doesn't require an ACPI implementation.

Is it worth compared to the PIT? I mean some of the older CPU's don't quite support it and/or disable it. Would it be a safe choice considering compatibility?

Yes. Most current CPUs have LAPICs, and that's good enough for me.

Even if it did require ACPI, or anything for that matter, cheat..

Create a APIC driver and a CPU driver, where the CPU driver informs the OS that there's a LAPIC (hardcode it to the CPU driver for now (this is the cheating part), with all needed details, so no ACPI needed)..

You co do this for everything else as well. For me, the MoBo driver will also know all of the "magic" numbers for all the I/O ports, etc. This allows you to postpone ACPI until the very end, and so if you never reach the end (probably most won't), then you never waste time on ACPI and if you do reach the end you can use ACPI to create a generic MoBo/CPU/etc drivers where ACPI is used to fetch values and do things.

Hi,



You can think of ACPI as having 2 parts - the tables (which are easy) and the AML (which is hard). For local APIC timer and HPET you only need tables (which are easy).

For a summary...

RTC
Discovery: Standard (assumed to exist)
Calibration: Not necessary
Access speed: Slow ISA IO ports
Counter: Not really (1 Hz if you use RTC's date/time)
Fixed frequency IRQ: Yes, up to 8 KHz (125 us) becoming unreliable at faster frequencies
IRQ on terminal count: No

PIT
Discovery: Standard (assumed to exist, but may be emulated by HPET)
Calibration: Not necessary
Access speed: Slow ISA IO ports (or slow SMM emulation of ISA ports)
Counter: No
Fixed frequency IRQ: Yes, up to 596.591 KHz (1.676 us)
IRQ on terminal count: Yes, 828 ns precision

ACPI Power Management Timer
Discovery: ACPI tables (FADT)
Calibration: Not necessary
Access speed: IO ports (may or may not be "faster, non-ISA IO ports")
Counter: Yes, 24-bit or 32-bit, monotonically increasing at 3.579545 MHz
Fixed frequency IRQ: No
IRQ on terminal count: No

HPET
Discovery: ACPI tables (HPET)
Calibration: Not necessary
Access speed: Fast (typically memory mapped device)
Counter: Yes, 64-bit monotonically increasing at 10 MHz or better
Fixed frequency IRQ: Yes, up to 10 Mhz or better (100 ns or better)
IRQ on terminal count: Yes, 100 ns or better precision

TSC
Discovery: CPUID
Calibration: Yes
Access speed: Very fast (built into CPU)
Counter: Yes, 64-bit monotonically increasing at CPU's clock speed (which can vary on old CPUs)
Fixed frequency IRQ: No
IRQ on terminal count: No

Local APIC timer (older)
Discovery: MP specification table, ACPI tables (APIC/MADT)
Calibration: Yes
Access speed: Very fast (built into CPU)
Counter: No
Fixed frequency IRQ: Yes, depends on CPU's bus/link speed, typically 100 Mhz or better (10 ns or better)
IRQ on terminal count: Yes, depends on CPU's bus/link speed, typically 10 ns or better

Local APIC timer (newer, with TSC deadline mode)
Discovery: MP specification table, ACPI tables (APIC/MADT)
Calibration: Yes
Access speed: Very fast (built into CPU)
Counter: Yes, 64-bit monotonically increasing at CPU's clock speed (which can vary on old CPUs)
Fixed frequency IRQ: No
IRQ on terminal count: Yes, depends on CPU's clock speed, typically 1 ns or better precision


Precision

For counters; ignoring "emulated with something else", the options in order of best precision are: TSC, HPET, ACPI power management timer

For fixed frequency IRQ; ignoring "emulated with something else", the options in order of best precision are: local APIC timer, HPET, PIT, RTC

For IRQ on terminal count (e.g. needed for "tickless"); ignoring "emulated with something else", in order of best precision are: local APIC timer in TSC deadline mode, local APIC timer without TSC deadline mode, HPET, PIT

Emulation

Counters can be emulated in software using a fixed frequency IRQ (e.g. doing "tick++;" in the IRQ handler).

Fixed frequency IRQ can be emulated in software using IRQ on terminal count (e.g. just set the new count to the same value each time).

IRQ on terminal count can be emulated in software using a fixed frequency IRQ (e.g. doing "count--; if(count == 0)" in the IRQ handler).


Notes

A "counter" is something you poll when you need to know how much time has passed (e.g. for file system timestamps, measuring how much CPU time each thread consumed, etc).

For local APIC timer, there's one per CPU. This is important for scalability (rather than many CPUs fighting to access the same single timer).

A good OS would detect which timers exist and determine their capabilities; then use this information to select the best timers to use for each different purposes.


Cheers,

Brendan

That last post needs to be copy/pasted into the Wiki