Mprime is faster on lower CPU clock speed

[drewster1829]

I'm running mprime on several of my machines, including the laptop I'm typing this on (I need to hurry, so I can kill gdm and get back to text mode!). It's a 3 year old Toshiba Satellite M55-S331 (1.73 GHz Pentium M) with 1.5 GB of DDR RAM. I'm running Ubuntu 8.04 (Hardy Heron) on it, and mprime 25.5 as a background startup daemon with the output ported to a log file.

I'm using cpufreq-set and cpufreq-info as frontends for CPU frequency scaling (this processor comes with 4 steps, 800 MHz, 1.07 GHz, 1.33 GHz, and 1.73GHz). What struck me as curious one day as I was running without gdm, was that on the conservative governor (which increases the cpu speed smoothly as needed...ondemand will leave it at 800MHz for just mprime, I'm assuming because it's priority is so low, but conservative will raise it) it would sometimes only crank the clock speed up to 1.33 GHz. I checked the range of frequencies, and it was correct, and even tried the performance governor (which is supposed to max the clock speed out), and it would only go to 1.33.

So I changed the minimum clock speed to 1.73 to force it to run at 1.73 GHz (and you can tell, because the fan cranks up to high speed and it puts out quite a bit more heat), and then I noticed something very interesting...the iteration times (I'm assuming it's doing LL testing...I'm an mprime newbie, so go easy on me) are consistently about 25% higher at 1.73 GHz than at 1.33 GHz (without GNOME or gdm running). And it is without fail...on M19643627, each iteration takes about .134 seconds at best at 1.73 GHz...all I have to do is change the clock speed to 1.33 GHz, and the fan speed comes down (as well as the heat level), and the times drop to .114 sec per iteration....how can this be?

Is it affecting a clock multiplier somewhere on the FPU (does the FPU use the same clock as the rest of the CPU?) or the system bus, resutling in a higher clock speed somewhere else at the lower CPU clock speed? Or is the readout of the clock speed wrong (but like I said, fan speed and heat production seem to be proportional to the indicated clock speed, and power consumption increases to max at 1.73 GHz, too...courtesy of a Kill-A-Watt meter). What am I missing here?

Thanks for all your help!

[Cruelty]

I'm guessing that at 1.73 your CPU is overheating and therefore throttling.

[sylvester]

I don't know about Pentium M, but some model of Mobile Pentium 4 have thermal throttling. They up the clock speed but then as soon as they hit temperature limit they start inserting HALT cycles. This causes reduced computational throughput without saving much energy. I had that happen on one of my laptops when one of two fans had been blocked.

On Linux the information about thermal throttlins is somewhere in /proc/acpi and was readable by just cat-ing the appropriate file in one of the subdirectories.

I've fixed the fan since, and I never experienced that aftererwards.

The other possibility is that only at 1.33 GHz your CPU speed matches your memory timings. At 1.73 GHz the CPU may require additional wait states to get the data from the memory.

This whole issue of running CPU asynchronously from the memory banks causes all kinds of strange performance issues. Especially with George's program where he carefully optimized the cache prefetches.

[S485122]

Originally Posted by drewster1829

It's (a) 3 year old
(...)

Did you check the ventilation vents to see if they are clear of dust ?

Jacob

[drewster1829]

Originally Posted by S485122

Did you check the ventilation vents to see if they are clear of dust ?

Jacob

Yeah, thanks for asking. I cleaned it just a couple months ago. I had problems with overheating under nominal CPU load, and I ended up dismantling my whole laptop and blowing out the dust (probably overkill, but it worked). I could check it again, though, but I haven't had problems with thermal shutdown like I did before (unless I do something dumb and set the thing on a towel).

[drewster1829]

Originally Posted by sylvester

I don't know about Pentium M, but some model of Mobile Pentium 4 have thermal throttling. They up the clock speed but then as soon as they hit temperature limit they start inserting HALT cycles. This causes reduced computational throughput without saving much energy. I had that happen on one of my laptops when one of two fans had been blocked.

On Linux the information about thermal throttlins is somewhere in /proc/acpi and was readable by just cat-ing the appropriate file in one of the subdirectories.

I've fixed the fan since, and I never experienced that aftererwards.

The other possibility is that only at 1.33 GHz your CPU speed matches your memory timings. At 1.73 GHz the CPU may require additional wait states to get the data from the memory.

This whole issue of running CPU asynchronously from the memory banks causes all kinds of strange performance issues. Especially with George's program where he carefully optimized the cache prefetches.

I'll have to check it out. There's a good possibility it is thermal throttling, since I noticed at 1.73 the fan speed seems to vary a bit, while a the other clock speeds, it's constant. Also, it would make more sense (to me) for memory timings to match the highest clock speed of the processor, but I could be wrong (there may be reasons why it would be matched at 1.33GHz instead of 1.73, but that's beyond my scope of knowledge). Thanks for your help! :)

[drewster1829]

Okay, apparently it's not due to thermal protection...throttling seems to not be supported on my processor:

laptop:/proc/acpi/processor/CPU0$ cat throttling
<not supported>
laptop:/proc/acpi/processor/CPU0$ cat info
processor id:            0
acpi id:                 0
bus mastering control:   yes
power management:        yes
throttling control:      no
limit interface:         no

Unless of course I'm barking up the wrong tree, and am misinterpreting the output (the /proc/acpi/thermal_zone directory is empty). Perhaps it is due to mismatched processor and RAM clocks at 1.73 GHz, then...very interesting.