These days, CPUs can adjust their frequency to lower energy consumption. However, many ways to do high precision duration measurements rely not directly on measuring time, but on getting ticks count. For example assembly instructions such as RDTSC/RDTSCP seem to access a tick count that is monotonically incremented at each clock cycle. Or the C constant CLOCKS_PER_SEC which is... a constant. For a processor with adjustable frequency, how tick counts and real durations are related? And how one can be deduced from another?
0
votes
This was fixed a long time ago, the odds your machine still has a processor with this issue are quite low today. We can't see it from here. en.wikipedia.org/wiki/…
- Hans Passant
The hardware has a real-time clock that counts separately from processor clock cycles. In any processor with a variable processor speed, there is no constant correlation between real time and processor cycles.
- Eric Postpischil
cpu clocks at any frequency are important measurements to have. And wall clock time as well, so you need to look for both. If these instructions give you processor clock counts, great, excellent. Now find one that gives an accurate measurement of wall clock time (I am speaking generically not x86 specific, actually so are you as you have not tagged a cpu/arch) these chips you speak of are often driven by a reference clock say 100Mhz then the GHz speeds are done internally with a pll, hopefully the designers provided a counter/timer based on ref clock not the multiplied clock. (unlikely)
- old_timer
@EricPostpischil: That's true for modern x86, but some earlier CPUs with variable frequency didn't have constant / nonstop TSC, so it wasn't a usable timesource. There are CPUID feature bits for both things: that RDTSC counts reference cycles, and that it doesn't stop when the CPU core clock is halted (sleep C-state). Linux prefers RDTSC as a timesource, but if the CPU doesn't have both those features, it falls back to another source, like HPET. My old Core2 system uses the TSC as a clocksource, but it might have been one of the first generations to have the necessary features.
- Peter Cordes
@PeterCordes: That’s why I said the “hardware” has a real-time clock that counts separately, not the processor. Old stuff had a discrete clock on the motherboard, sometimes as an extra option. Before that, you had to enter the time when the system booted.
- Eric Postpischil
1 Answers
1
votes
Looking into the documenttion from Intel (Intel® 64 and IA-32 Architectures Software Developer’s Manual / Volume 3 (3A, 3B, 3C & 3D): System Programming Guide) in section 17.17 the documentation reads
For Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H and higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model [0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family [06H], DisplayModel [17H]); for Intel Atom processors (family [06H], DisplayModel [1CH]): the time-stamp counter increments at a constant rate. That rate may be set by the maximum core-clock to bus-clock ratio of the processor or may be set by the maximum resolved frequency at which the processor is booted. The maximum resolved frequency may differ from the processor base frequency, see Section 18.7.2 for more detail. On certain processors, the TSC frequency may not be the same as the frequency in the brand string.
So the TSC is running at a constant rate. So the different frequencies do not matter. This is since Pentium 4 the case.
Please read the complete section 17.17 to know what procesors do to give you a constant rate timer.
Also the comments below your questions are right: You have to differentiate between such a short term timer and the wall clock time.
