From quote:
The Time Stamp Counter (TSC) is a 64-bit present on all processors since the . It counts the number of since reset. The instruction RDTSC
returns the TSC in EDX:EAX. In mode, RDTSC
also clears the higher 32 bits of and . Its is 0F 31
. competitors such as the did not always have a TSC and may consider RDTSC
an illegal instruction. Cyrix included a Time Stamp Counter in their .
The Time Stamp Counter was once an excellent high-resolution, low-overhead way for a program to get CPU timing information. With the advent of / CPUs, systems with , and , the TSC cannot be relied upon to provide accurate results — unless great care is taken to correct the possible flaws: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. Therefore, a program can get reliable results only by limiting itself to run on one specific CPU. Even then, the CPU speed may change because of power-saving measures taken by the OS or , or the system may be hibernated and later resumed, resetting the TSC. In those latter cases, to stay relevant, the program must re-calibrate the counter periodically.
Relying on the TSC also reduces portability, as other processors may not have a similar feature. Recent Intel processors include a constant rate TSC (identified by the kern.timecounter.invariant_tsc sysctl on FreeBSD or by the "constant_tsc
" flag in Linux's /proc/cpuinfo
). With these processors, the TSC ticks at the processor's nominal frequency, regardless of the actual CPU clock frequency due to turbo or power saving states. Hence TSC ticks are counting the passage of time, not the number of CPU clock cycles elapsed.
Starting with the , Intel processors have practiced , where instructions are not necessarily performed in the order they appear in the program. This can cause the processor to execute RDTSC
later than a simple program expects, producing a misleading cycle count. The programmer can solve this problem by inserting a serializing instruction, such as , to force every preceding instruction to complete before allowing the program to continue, or by using the RDTSCP
instruction, which is a serializing variant of the RDTSC
instruction.
And from , if constant_tsc exist for cpu flag, TSC rate is the maximum CPU frequency.
Detailed kernel document about time-keeping is .
A detailed intro is .
And to note: constant_tsc + invariant_tsc = nonstop_tsc
Related kernel constant: CONFIG_HZ, HZ
Accoding to and , no matter what_tsc is capable of the cpu, hpet is better. So in user space program development, use hpet to record time!