From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21068 invoked by alias); 12 Mar 2009 01:57:58 -0000 Received: (qmail 20312 invoked by uid 48); 12 Mar 2009 01:57:45 -0000 Date: Thu, 12 Mar 2009 01:57:00 -0000 Message-ID: <20090312015745.20311.qmail@sourceware.org> From: "adam at consulting dot net dot nz" To: glibc-bugs@sources.redhat.com In-Reply-To: <20090312002952.9942.adam@consulting.net.nz> References: <20090312002952.9942.adam@consulting.net.nz> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/9942] clock_gettime CLOCK_MONOTONIC nanosecond calculation is broken X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00028.txt.bz2 ------- 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.