From owner-freebsd-acpi@FreeBSD.ORG Sun Apr 10 21:04:39 2005 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BB8C16A4D8 for ; Sun, 10 Apr 2005 21:04:39 +0000 (GMT) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3875043D48 for ; Sun, 10 Apr 2005 21:04:38 +0000 (GMT) (envelope-from nate@root.org) Received: from pimout6-ext.prodigy.net (pimout6-ext.prodigy.net [207.115.63.78])j3AL4bcm003893 for ; Sun, 10 Apr 2005 17:04:37 -0400 X-ORBL: [64.171.186.189] Received: from [10.0.5.51] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189])j3AL4Y5j042350; Sun, 10 Apr 2005 17:04:34 -0400 Message-ID: <4259945C.4020904@root.org> Date: Sun, 10 Apr 2005 14:02:20 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050408215912.E65115D07@ptavv.es.net> In-Reply-To: <20050408215912.E65115D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: Re: Further testing of power management X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 21:04:39 -0000 Kevin Oberman wrote: > 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. Thanks for your testing. I agree that settings like the 900 mhz value don't make sense to use when the 1050 value has lower heat. Do you have known values for power consumption (sysctl dev.cpu.0.freq_levels, look for the second number after the /)? Unknown values are marked -1. Is the power consumption for 900 higher than 1050? If so, we could add a test that compares power consumption and discards levels that have lower frequencies but higher power consumption than their neighbors. If you check today's CVS email, you'll see that I committed support to powerd to add up all power usage when in verbose mode. This lets you test a fixed workload with different algorithms like this: sysctl dev.cpu.0.freq=[your highest] powerd -v > powerd_output & time -o load_output ./load_generator killall powerd I've found with my testing that the current algorithm saves much more power and has no worse performance loss than any other algorithm I tried. I tried various forms of linear and exponential growth/decay as well as adding the "stickiness" patch. Two workloads I tried were a random IO with pauses and a random CPU burner with pauses. On a P4-M laptop I was able to borrow, I ran the test at 1700 and 600 Mhz (fixed) to get a baseline. The 600 Mhz test ran 37% slower (wall time) than the full speed test. The current adaptive algorithm ran only 2.3% slower than full speed and saved a whopping 75% on power (energy consumed, really). The best performing algorithm (lazy linear step-up/step-down similar to your patch) gave performance only 0.7% slower than full speed but used 2.6X more power than the current adaptive algorithm. I did find that interrupt latency was not significantly affected by the slower clock frequencies so I've dropped the default running level to 65%. This should keep us from jumping to full speed prematurely. I welcome further testing with different workloads. Be sure to benchmark your performance with time(1) as well as power consumed (via powerd -v) and compare to full speed and slow speed. You can get the power consumed for constant speeds by using powerd's fixed mode (powerd -v -a max -b max) -- Nate