Taken from the -user post in the URL. In the printf line "doubl" should be "double" and CLOCK should be CLOCKS, I believe. Hllo, recently I reported a problem regarding lame and calculated cpu time. After reading a note in the 2.5.25 release notes I wondered if the gentoo kernel could have a problem with clock_t and CLOCKS_PER_SEC, and indeed it has. If I write the following simple program: --- #include <time.h> int main() { clock_t c; double d; for (d = 0; d < (double)10000000;d++) { test(d); } c = clock(); printf("%f\n",((doubl)c)/CLOCK_PER_SEC); } int test(double d) { return 0; } It will report that the program took 2.81 secs of cpu time on my athlon 2000xp+, where in reallity it takes 0.281 seconds. It appears that clock() on gentoo returns a number ten time as high as my redhat, but clocks_per_sec has not been adjusted. Henk,
looking into it =)
HZ problem... I think
Created attachment 4191 [details, diff] hz.diff; kernel patch to pass the right value on to glibc to get times() and clock() working right Yes, this is a kernel bug relating to changing HZ from the default of 100. The kernel is not correctly passing the new value on to glibc via ELF. This patch works for me. This patch changes the i386 definition of CLOCKS_PER_SEC to be the same as almost every other platform, so I consider this low risk.
Im suprised to have no followups to this after 2 weeks.... Is anyone tracking this?
Please include this patch on the new kernels... I did see the error in the lame output too, which doesn't hurt much indeed... But the error is apparent too using numerous benches (for example pari-gp, root...) in which my gentoo system is measured as horribly slow...
Hmm... well what has been done is to change the default value of the HZ to 100 in the current series of gentoo kernels, because there may be other issues than this brought up by using other values, I'll go ahead and add this patch to the current Jiffies patch though for my development sources (lolo-sources- 2.4.20.1_pre1 should be out sometime in the next few days with all sorts of goodies.
I like unified diffs, and therefore I want things in diff -u from now on. Thanks a lot though, if this works as expected we can go ahead and go back to defaulting to 1000 for the jiffies.
This might be of interest: Robert Love Explains Variable HZ (including patch) http://kerneltrap.org/node.php?id=464
**embarassed... I'm the one who's supposed to watch this stuff as it shoots past my eyes on LKML... Thanks... I'll use RML's patch on the next gentoo kernel.
patch in latest lolo-sources, please test and have a party.
Can we close this ?
ok, so in gentoo-sources < 2.4.20 it is important to keep HZ set to 100, closing bug.
