So the timers in the cpu use crystals too?

@obobskivich. My HPET also registers slightly later than the APIC. But the RTC appears much later, about 4 minutes (are the whole numbers minutes?) into the boot, presumably because it's only accessible through a bus.

I didn't realise there were so many different timers available or that some of them are baked into the cpu. Presumably the kernel does some kind of optimisation logic to decide which of these to use as its system clock.

What I believed about the kernel using the cpu frequency may simply be out of date. Perhaps that's just what used to happen back in the day when cpu frequency was a fixed number.

That's my understanding as well - that the RTC itself is not linked to CPU frequency.

According to Wikipedia, the standard RTC runs at 32.768 kHz. Wikipedia goes on to explain this is chosen because it is 2^15 cycles/second, which allows binary counting of time to be easier.

Adding a link:
https://en.wikipedia.org/wiki/Real-time_clock#Timing



The CPU clocking is independent of RTC crystal, and if I remember right historically they did use crystals, but modern systems use clock gen chips (I know there's a nicer acronym for this chip), which are commodity ICs (those ICs may have an external crystal reference as well). Those (the IC) provide the 'reference clock' which is then used to derive the CPU/bus speeds. As business_kid alludes to, this is incredibly complicated to layout and manage in modern systems, because of all the potential sources of interference, latency, etc coupled with the very high speeds that we expect nowadays (the era of being able to hand-wire this stuff and have a CPU the size of a shoebox is long since gone).

The 'whole numbers' are seconds, and the trailing is fractions of seconds (out to whatever nth). My guess is on very modern systems RTC is made available through some sort of legacy chipset/controller - just like how PS/2, PCI, RS-232, etc are implemented now vs 'back in the day' (like the 1980s). There's a lot more integration with modern hardware (as in single chips doing multiple features).

See this is what I'm curious about now too - the timers are all available but I've never really thought about 'what is being used by who' in terms of application space. So for example take a videogame with a timer in it, and its counting down 30 seconds or something - what's the actual hardware line-up for that 30 second count? Is it just asking the system for time (which comes from RTC/NTP), or is it using its own internal code to figure out 1 second intervals, and if so, what function is it calling (is this a standard API feature or are they creating a new method), and what does that function map to in the OS, and what hardware underlies that? I know in practice this doesn't matter for the vast majority of high-level code - just accept the abstraction and it is 'good enough' - but it's still interesting to think about.

Well it still figures bogomips on start-up, and uses that value somewhere presumably, and it can still grab TSC from the CPU as well - just looking at dmesg on an Opteron-based system I'm using, when virtualbox starts up it grabs a TSC for its driver, which is reported as 'invariant' and fixed at 2.7GHz, for example. So that *is* the CPU frequency (or some variation thereof) being used as a timer, but you're right in that it doesn't cleanly line-up with the actual hardware implementation you'd find in say, an orignal IBM PC from the 1980s, although to the application software it should look pretty much the same at runtime.

Aha! Look what I found:
So that's the actual clock that my kernel uses. YMMV.
The system only gets its absolute time from the rtc. Once this is set by a startup script at boot, the rtc is never consulted again (whereas Windows uses it all the time). And for this kind of count-down, absolute time isn't required, only relative time. So it would be the TSC or HPET that matters.

The second post in this thread deals with sleep functions in application code if you're interested. It's way over my head, but I just checked the man pages, and these functions are in chapter 3 but require unistd.h, which is the header for system calls. So at some point they must use a system call that references the kernel's internal clock.

I found the same entry (clocksource) just poking around as well - on my system it shows hpet being registered/initialized early-on, but does not end up selecting it. Read on for more...

This is/was a bit obtuse question, I know; my reasoning wasn't so much 'is it using RTC or system time' but 'is it forced to a specific timer when multiple are available?' (and perhaps RTC was a bad example there because, as you say, that's a one-and-done read)

Just doing some more looking for this, I found that gamers apparently do worry about this (I was just using 'a game' as an example because it was something with a 'real time' timer that, as you point out, doesn't rely on absolute time, but turns out there are documentable performance differences). Here's some example discussions (mostly in Windows but you can see the conceptual carryover to other OSes - I don't know if there is carryover to other applications, and in some cases they use bad language):

https://www.reddit.com/r/GlobalOffen...g_tsc_vs_hpet/
https://www.anandtech.com/show/12678...yzen-results/5
https://www.overclock.net/forum/78-p...o-you-use.html

And more linux-specific discussions which include a console command to query what the current clocksource is for the system and more (conceptually) about how it is selected at boot.
https://sourceforge.net/p/astlinux/m...sage/30287391/
https://unix.stackexchange.com/quest...urce-influence

On my system which shows hpet for 'clocksource' in dmesg at 0.00, it still reports tsc as clocksource0 after boot-up is complete, with hpet also available. This can be checked with


This leads me to the conclusion that: applications should probably default to whatever is defined as 'current_clocksource' but there seems to be no restriction on either changing the system's clocksource (to another available timer that is) or registering additional clocksources/timers on the system (And this seems to be likely the case for linux and Windows). How linux chooses hpet or tsc or [whatever] is likely governed by more hardware-specific knowledge on the part of the kernel (e.g. you observed one of your Intel systems blacklisting its hpet time and in the sourceforge link above they discuss a system blacklisting tsc with multiple processors). To add this on to the original reply: modern tsc implementations will be 'fixed' at some clockspeed for stability/sanity (so a 'fake' but constant cpu clock) which is a derived clock based on clock generation for the CPU's reference clock, while HPET and RTC are derived from their own sources off-CPU. I'm wondering, finally, if the performance differences between hpet and tsc are (at least partially) the result of software timing events accounting for tsc set at CPU speed N, when the CPU is capable of operating at speeds >N with dynamic clocking, while hpet is a fixed point (albeit potentially an unreliable one).

Just to add another twist to this:

AMD are now very serious competition for Intel, and did a nice little video explaining their cooling system. They had a 'safe area triangle' and control heat by among other things, Vcore and clock frequency. The heat sensor is a silicon junction on the silicon wafer, and the core voltage and frequency are infinitely variable. It's just the frequency, which concerns us here. I'll throw in 2 Hardware techniques in Electronics to explain this:

1. VCO = Voltage Controlled Oscillator gives a frequency dependent on the input voltage. They can work either way up=faster, or down=faster.
2. PLL, which AMD throw about plenty stands for Phase Locked Loop. This basically phase locks with the last copy of itself, and adjusts the frequency to keep locked in phase, which makes a very stable output. PLL was/is a central part of all tuners, fm radio, etc.

No matter how you look at it, you're unlikely to get an exact report on what you're doing frequency wise, as all this is going on in real time INSIDE the core. Whereas AMD might be infinitely variable, some cpus are clunkier and have 'gear changes for temperature regulation.

On timers - you're right, they use cpu clocks. In the old days they would use the crystal. They can be polled (What's it at now?) but mostly they're used to generate an interrupt when they hit 0. They would have to be predictable, because otherwise how would a programmer set the initial value?