Date: Fri, 08 Apr 2005 14:59:12 -0700 From: "Kevin Oberman" <oberman@es.net> To: nate@root.org Cc: acpi@freebsd.org Subject: Further testing of power management Message-ID: <20050408215912.E65115D07@ptavv.es.net>
next in thread | raw e-mail | index | archive | help
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@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050408215912.E65115D07>