Further testing of power management
Kevin Oberman
oberman at es.net
Fri Apr 8 14:59:14 PDT 2005
Nate,
I finally had time to do some careful testing of power management on
-current. All testing was done on my IBM T30 with a 1.8 GHz P4-M
Processor. CPU load was generated by the use of md5 on a long gatch of
zeros. (As you suggested.)
First, on power dissipation, while the use of TCC and adjusting actual
CPU frequency causes very predictable compute performance. They do not
produce the expected matching power dissipation.
Here is a chart of the CPU temperature against the value of
dev.cpu.0.freq. The third column list the actual clock frequency that
the CPU is using. The T30 supports only 2 frequencies, 1.8 GHz and 1.2
GHz.
dev.cpu.0.freq Temperature CPU Clock
1800 >_PSV 1800
1575 >_PSV 1800
1350 85 1800
1200 73 1200
1125 82 1800
1050 69 1200
900 77 1800
750 64 1200
675 72 1800
600 62 1200
450 66 1800
300 56 1200
225 61 1800
150 54 1200
As you can see, lowering the CPU cock speed is much more effective in
reducing CPU heat (and battery drain) than doing it with TCC. I can get
much better performance with lower battery consumption at 1200 MHz than
at 900 MHz. Clearly, if both clock and TCC can provide identical
performance, you want the slower clock. This is backwards from how it is
now running as both 900 MHZ and 450 MHz can be achieved at either 1800
MHZ or 1200MHz clocking, but are clocked at 1800 MHz.
It is also clear that clocking at 1125, 675, 450, or 225 makes no sense.
900 MHz and 450 MHz would make sense if the clock was set to 1200
instead of 1800.
I have yet to test with throttling in lieu of TCC, so I can't say if
that will produce the same result, but these results were significant
enough that I really want to try that, too. I have a feeling the IBM
knew all of this when setting up the power management under Windows and
that we can get much better battery life if we can take advantage of
this.
I'd also like to know if other laptops see similar performance when
throttling and clock rate are adjusted.
It can take several minutes for the temperature to stabilize. If TCC is
present, I would expect similar results to mine. Pentium-M CPU with ESS,
testing on P3-Ms which lack TCC and AMD PowerNow testing would also be
very nice to see. If we can find consistent behavior, we can eliminate
the use of the "bad" speeds and provide much better performance
vs. battery drain and make a lot of laptop users happy. At lower clock
rates, the count could be reduced to save time. For faster CPUs, a
larger count may be needed. Some machines may stabilize the temperature
more or less quickly than mine. I waited until the temperature was
steady for 1 minute or until it "bounced".
Here is the command sequence I used. It would be easy to turn it into a
shell script that steps through all speeds, I suspect, but I am a rotten
shell script writer and a co-worker has borrowed my Shell Programming
book. (I would do it in Perl, but people who do shell would laugh at
it.)
sysctl dev.cpu.0.freq=XXX && \
dd if=/dev/zero bs=1m count=2500 | md5 && \
sysctl he.acpi.thermal.tz0.temperature
Can someone refresh my memory on whether there is an easy way to prevent
TCC from being used on a CPU that supports it? Otherwise I can edit the
source code and force the use of throttling.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
More information about the freebsd-acpi
mailing list