Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Power Input Devices Portables Hardware Technology

Measuring the User For CPU Frequency Scaling 190

An anonymous reader writes "The Empathic Systems Project a Northwestern University demonstrate up to 50% power savings by controlling CPU frequency scaling based upon the end user. They measure the user with eye trackers, galvanic skin response, and force sensors to find a CPU frequency that the user is satisfied with. They are currently studying user activity and system performance on mobile architectures, specifically the Android G1 phone."
This discussion has been archived. No new comments can be posted.

Measuring the User For CPU Frequency Scaling

Comments Filter:
  • Re:Waste of Time (Score:5, Interesting)

    by tlhIngan ( 30335 ) <slashdot.worf@net> on Wednesday May 13, 2009 @06:24PM (#27944991)

    So if I walk away from my machine to let it process a job, it'll go slower?

    If this is to save power, then reducing speed when an intensive task is performed is retarded, since you'll waste energy (having to run the task proportionately longer).

    If we're only taking into account saving power when idle/mostly idle, then basing this off of metrics from the user is a waste of effort. Just test your apps and see what a user feels is "fast" for certain tasks, then attach those target times to those tasks, and let the CPU try to hit that target.

    You'll waste less energy monitoring a user's behavior and galvanic boner response, and you won't annoy the user when your system behaves inconsistently.

    If you want, you can let users specify whether or not they want to emphasize battery life or performance, or turn the feature off entirely and let shit work as it should.

    The trick would be getting this shit implemented at level low enough that each app would be able to specify target times and specific tasks. Of course, if you're the fuckers worried about battery life, you're the one designing the hardware/platform, so you've got control.

    Except, this technology is NOT for computing applications, but for mobile applications - e.g., a phone.

    For a phone, you do not want background processing tasks - they force the processor to stay "awake" and drain the battery very quickly. Even a simple task that wakes the CPU up every second will easily cause battery life to diminish from the 2+ weeks standby to a few days. (Take your battery capacity and divide it by the standby time - you'll find you have around 2-3mA to play with, which is just enough to maintain the radio connectivity).

    Mobile processors have a technique known as DVFS - dynamic voltage and frequency scaling. The goal is to keep the voltage as low as possible (power consumed is proportional to voltage squared), which may mean you run the CPU at a lower frequency. There's a bit of overhead in switching frequencies, including having to ramp up core voltages and adjusting clocks, waiting for them to stabilize, etc.

    The trick though, is to realize when the user really doesn't care for speed, and thus keep the CPU in a lower frequency (e.g., playing music), versus the user is actively doing stuff, and it would be desirable to have it finish as fast as possible (e.g., browsing the web) so while the user ponders, you can put the CPU into a low power state immediately, versus keep it at a slow clock and have the user wait. Also, you have to figure out when the user is doing something that really is requiring a lot of CPU power (playing movies), so you have to bump the speed up and hold it there, and not at the first instance of idleness, drop back down.

    Basically, having this feedback ltes you find out what is going on - is the user not caring, and thus you should pick the slowest speed that'll get things done? Is the user actively engaged in the device, but the usage is bursty, so you should go into a low power state after the processing is done, or is the user doing something that requires processor, and dropping down wastes power due to overhead?

  • by Darkness404 ( 1287218 ) on Wednesday May 13, 2009 @06:36PM (#27945129)
    3 year old? I'm sorry but I expect all programs that aren't games (and some CPU intensive programs) to run perfectly well on an early P4 with 512 MB of RAM. I currently use a 4-5 year old computer for most day-to-day work.

    All programs/OSes should work perfectly on hardware made in ~2003, many people still have these (or older) computers, especially if they live outside of high speed internet access, or aren't very computer literate.
  • Re:Overhead? (Score:5, Interesting)

    by tkw954 ( 709413 ) on Wednesday May 13, 2009 @07:40PM (#27945741)
    I recently did a test on a fanless VIA Eden system (CPU + mobo + RAM + notebook hd + 2 Delta 1010LT soundcards with a switch mode PSU). The power consumption was 29.1 W with the system idling and throttled down (600 MHz) and 31.9 W with a full 'ping -f localhost' load (1200 MHz). I know it's not an embedded ARM system, but this does give an idea of the nearly negligible power savings available by halving your clock speed.
  • Re:Rent costs (Score:3, Interesting)

    by MrCrassic ( 994046 ) <<li.ame> <ta> <detacerped>> on Wednesday May 13, 2009 @09:28PM (#27946551) Journal
    Actually, I choose job locations far from my home because it's more miles for me to bike, but we're the minority.

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...