0

As part of the linux kernel course we are explained that high resolution timers or may may not be supported by the hardware. The hardware that affects this support is only the CPU.

So I took my time and opened one of the intel CPUs specs I am trying to understand If by reading the specs of a given CPU, I can determine if the OS can support high resolution timers.

In that specific manual I am uncertain what to look for, but my first guess is the "Clock Topology" section (2.6 in the link). The section lists under it three types of HW clocks: Base Clock reference clock (100MHz), PCIe reference clock and fixed clock 38.4MHz.

Now if the high high resolution clock support is based solely on the hardware, and not by some complex computation of multiple clocks and so forth, then the base reference clock's 100Hz is 10 nanoseconds, not 1. High resolution timers are supposedly support 1 nanoseconds resolutions.

I assume INTEL high-end CPU do support high resolution timers, but it seems I lack knowledge in how to read the manual and what is needed for that support.

Can someone elaborate more? does nanosecond resolution actually mean 1 nanosecond resolution? If this CPU does support HR-timers, what mechanisms are used to compensate the lack of HW support. Can this information be obtained from the OS itself?

Aviv
  • 414
  • 4
  • 16
  • You mean timers that can be programmed to fire interrupts, like the HPET? If you mean as a timesource, all CPUs since the mid to late 2000s (like Core2 or so) have had invariant TSC. A generation or two after that, it doesn't halt even when the core clock halts, although I think that may not matter the way Linux uses it as a timesource, just with a scale/offset to interpolate since the last timer interrupt tick. See [this answer](//stackoverflow.com/a/51907627/224132) for lots of details about RDTSC. The instruction is guaranteed available, but CPU features govern its usability for time – Peter Cordes Nov 10 '21 at 16:47
  • @PeterCordes invariant TSC as in not affected by P-states? I think what OP is after is the timer used for Linux's "hrtimer" APIs e.g. `CLOCK_MONOTONIC` just to name one. Not sure exactly at what level they want to obtain the supported/not-supported information though (kernel API, kernel machine code, userspace API, userspace machine code)... – Marco Bonelli Nov 10 '21 at 17:02
  • 1
    @MarcoBonelli: Right, like I said, see [How to get the CPU cycle count in x86\_64 from C++?](https://stackoverflow.com/a/51907627). My answer enumerates the various CPUID features that tell you things about how the TSC works, including `constant_tsc` which means it ticks at a reference frequency unrelated to the current P-state. And a separate feature bit for support of the `IA32_TSC_DEADLINE` MSR, which lets the kernel set a one-shot wakeup interrupt timer with the LAPIC. – Peter Cordes Nov 10 '21 at 17:49
  • @PeterCordes You are way off my intended topic. I want to understand how read CPU specs to realize if I can have nanosecond interrupts (i.e., high resolution timer). I don't ask after the TSC register or any of the higher level implementation or any of its invariants (as explained in this link I find easy to understand http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/) – Aviv Nov 10 '21 at 19:24
  • Then what x86 feature *are* you asking about? HPET? – Peter Cordes Nov 11 '21 at 02:15
  • 1
    Examine **/proc/timer_list** of a running system. High resolution timer support will be obvious with `.resolution: 1 nsecs` reported for each clock/timer. Don't know about x86, but on the Atmel/Microchip SoCs I'm familiar with, HR timers use a timer/counter peripheral integrated into the SoC, distinct from the ARM processor. When there is no HW support for hrtimers, then you have low-res timers based on the same HW clock used for jiffies. – sawdust Nov 11 '21 at 02:38
  • 1
    @Aviv you should make your question clearer then. It's hard to understand if you want 1) help with the intel manual 2) help with linux kernel features 3) help with kernel userspace APIs 4) help with writing machine code to determine if hrtimers are available. – Marco Bonelli Nov 11 '21 at 14:29
  • @PeterCordes I am asking in how to read to intel manual, or any CPU manual, to realize if the OS can actually support hr timers at all. – Aviv Nov 13 '21 at 09:39
  • see the link https://elinux.org/High_Resolution_Timers. it mentions that first one needs to see if such support exists for their "target processor" (i.e., read the manual). I am asking this question to understand this requirement After that verified, the next thing is configure the kernel with CONFIG_HIGH_RES_TIMERS support. but I won't be surprised if this can be configured without the actual CPU support – Aviv Nov 13 '21 at 09:42
  • @MarcoBonelli Ok, i think I have made it clearer in the last comments. Please let me know what you think – Aviv Nov 13 '21 at 09:45
  • *100Hz is 10 nanoseconds, not 1* is still a very weird phrase. 10 nanoseconds is the period of a 100 MHz clock, not 100 Hz, so that's off by a factor of a million. – Peter Cordes Nov 13 '21 at 15:47
  • @PeterCordes The online convertors state explicitly 100MHz == 10 nanoseconds. I don't understand your statement at all. what's wrong with this equivalency? Plus, This still doesn't explain how to read a CPU spec to understand such support – Aviv Nov 13 '21 at 23:14
  • 1
    In your question, you wrote 100 HZ, not 100 MHz (Hertz, not Megahertz) in the paragraph after you wrote 100MHz. I see now that was just a typo, and the previous paragraph discussed some clocks with frequencies that make sense. – Peter Cordes Nov 13 '21 at 23:25

0 Answers0