[Bug libc/9942] clock_gettime CLOCK_MONOTONIC nanosecond calculation is broken

[Bug libc/9942] clock_gettime CLOCK_MONOTONIC nanosecond calculation is broken

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=9942

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/9942] clock_gettime CLOCK_MONOTONIC nanosecond calculation is broken

[ldv at altlinux dot org]

------- Additional Comments From ldv at altlinux dot org  2009-03-12 02:02 -------
Hint: struct timespec also contains tv_sec field.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=9942

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/9942] clock_gettime CLOCK_MONOTONIC nanosecond calculation is broken

[adam at consulting dot net dot nz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]


------- Additional Comments From adam at consulting dot net dot nz  2009-03-12 01:57 -------
Is the correct frequency divisor being reliably read? My processor has a
constant_tsc, as verified by grepping the flags in /proc/cpuinfo.

__get_clockfreq extracts the frequency divisor from the "cpu MHz" entry of
/proc/cpuinfo.

Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System
Programming Guide, Part 2:

18.11 TIME-STAMP COUNTER:

"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], display_model [17H]); for Intel Atom processors (family [06H],
display_model [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
maximum qualified frequency of the processor, see Section 18.20.5 for more
detail."


18.20 COUNTING CLOCKS:

"For Intel processors that support Intel Dynamic Acceleration or XE operation,
the processor core clocks may operate at a frequency that differs from the
maximum qualified frequency (as indicated by brand string information reported
by CPUID instruction). See Section 18.20.5 for more detail."


18.20.5 Cycle Counting and Opportunistic Processor Operation:

"The TSC, IA32_MPERF, and IA32_FIXED_CTR2 operate at the same, maximum resolved
frequency of the platform, which is equal to the product of scalable bus
frequency and maximum resolved bus ratio."


Thus the "cpu MHz" entry for a core will not be equal to the constant frequency
that TSC increments when the core is operating at a frequency that differs from
the maximum qualified frequency. Most of the time my cores are running at an
on-demand frequency of 1998.000 MHz. This only rises to 2997.000 MHz (obtained
from /proc/cpuinfo) when the cores are under load. If /proc/cpuinfo is read for
a core that is not under load the wrong frequency divisor will be extracted.

With Linux kernel 2.6.28 even maxing out one core only gives a 50% chance (on a
dual-core processor) of reading the correct "cpu MHz":

$ echo "Before:" && cat /proc/cpuinfo | grep 'cpu MHz' && for ((i=0; i<1000000;
i+=1)); do true; done && echo "After:" && cat /proc/cpuinfo | grep 'cpu MHz'
Before:
cpu MHz		: 1998.000
cpu MHz		: 1998.000
After:
cpu MHz		: 1998.000
cpu MHz		: 2997.000

$ echo "Before:" && cat /proc/cpuinfo | grep 'cpu MHz' && for ((i=0; i<1000000;
i+=1)); do true; done && echo "After:" && cat /proc/cpuinfo | grep 'cpu MHz'
Before:
cpu MHz		: 1998.000
cpu MHz		: 1998.000
After:
cpu MHz		: 2997.000
cpu MHz		: 1998.000

Workaround: Read all "cpu MHz" entries and return the maximum value found.

Workaround will still fail if a cpufreq scaling governor is used that does not
permit the processor to reach maximum qualified frequency.

Potential workaround: Read maximum qualified frequency from "model name", e.g.:
model name	: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Maximum qualified frequency is 3.00GHz. Compare this to maximum cpu MHz read
under load. If they differ significantly use the maximum qualified frequency
read from the model name. If they are very similar (within say 50MHz) use the
maximum "cpu MHz" entry.

This approach would be appropriate for an overclocked processor if constant_tsc
runs at the same rate even when the processor is overlocked [otherwise it is
inappropriate and the highest "cpu MHz" entry should be used instead of the
maximum qualified frequency].

Regards,
Adam

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9942

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.