cpufreqd as standard install?
Has anyone considered cpufreqd in standard install? I have a 1.9GHz Athlon 64 X-2 with stock heat sink (recently cleaned and inspected) and fan (operating at 3200RPM). Its clock rates are 1.9GHz, 1.8GHz, and 1.0GHz. At full load (encoding a video), it eventually reaches 80C and the system shuts down. I currently have cpufreqd configured to clock to 1.8GHz at 73C, and move to the ondemand governor at 70C. At 73C, the system switches from 1.9GHz to 1.8GHz. Ten seconds later, it's at 70C and switches back to 1.9GHz. 41 seconds after that, it reaches 73C again and switches to 1.8GHz. That means at stock frequency (1.9GHz) with stock cooling equipment, the CPU overheats under full load. Clocked 0.1GHz slower than its rated speed, it rapidly cools. Which is ridiculous; who designed this thing? Besides this, it would be possible to enter power save mode on laptops and UPS based on battery life remaining. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On 03/03/2012 12:13 AM, Phillip Susi wrote: On 02/29/2012 04:40 PM, John Moser wrote: At full load (encoding a video), it eventually reaches 80C and the system shuts down. It sounds like you have some broken hardware. The stock heatsink and fan are designed to keep the cpu from overheating under full load at the design frequency and voltage. You might want to verify that your motherboard is driving the cpu at the correct frequency and voltage. Possibly. The only other use case I can think of is when ambient temperature is hot. Remember server rooms use air conditioning; I did find that for a while my machine would quickly overheat if the room temperature was above 79F, and so kept the room at 75F. The heat sink was completely clogged with dust at the time, though, which is why I recently cleaned and inspected it and checked all the fan speed monitors and motherboard settings to make sure everything was running as appropriate. In any case if the A/C goes down in a server room, it would be nice to have the system CPU frequency scaling kick in and take the clock speed down before the chip overheats. Modern servers--for example, the new revision of the Dell PowerEdge II and III as per 4 or 5 years ago--lean on their low-power capabilities, and modern data centers use a centralized DC converter and high voltage (220V) DC mains in the data center to reduce power waste because of the high cost of electricity. It's extremely likely that said servers would provide a low enough clock speed to not overheat without air conditioning, which is an emergency situation. Of course, the side benefit of not overheating desktops with inadequate cooling or faulty motherboard behavior is simply a bonus. Still, I believe in fault tolerance. I currently have cpufreqd configured to clock to 1.8GHz at 73C, and move to the ondemand governor at 70C. This need for manual configuring is a good reason why it is not a candidate for standard install. I've attached a configuration that generically uses sensors (i.e. if the program 'sensors' gives useful output, this works). It's just one core though (a multi-core system reads the same temperature for them all, as it's per-CPU); you can easily automatically generate this. Mind you on the topic of automatic generation, 80C is a hard limit. It just is. My machine reports (through sensors) +95.0C as "Critical", but my BIOS shuts down the system at +80.0C immediately. Silicon physically does not tolerate temperatures above 80.0C well at all; if a chip claims it can run at 95.0C it's lying. Even SOD-CMOS doesn't tolerate those temperatures. As well, again, you could write some generic profiles that detect when the system is running on battery (UPS, laptop) and make appreciable adjustments based on how much battery life is left. At 73C, the system switches from 1.9GHz to 1.8GHz. Ten seconds later, it's at 70C and switches back to 1.9GHz. 41 seconds after that, it reaches 73C again and switches to 1.8GHz. That means at stock frequency (1.9GHz) with stock cooling equipment, the CPU overheats under full load. Clocked 0.1GHz slower than its rated speed, it rapidly cools. Which is ridiculous; who designed this thing? This sounds like your motherboard is overvolting the cpu in that 1.9 GHz stepping. Possibly, but the settings are all default, nothing set to overclock (it has jumper free overclocking configuration, but the option "Standard" is default for clock rate and voltage settings, which I assume the CPU supplies). Basically the argument here is between "Supply fault tolerance" and "Well your motherboard is [old|poorly designed] so buy a new one." That's an excellent argument for hard drives (I have, in fact, suggested in the past that Ubuntu monitor hard disks for behavior indicative of dying drives--SMART errors, IDE RESET commands because the drive hangs, etc--and begin annoying the user with messages about the SEVERE risk of extreme data loss if he doesn't back up his data), but really if my mobo/CPU is aging and the CPU runs a little hot I'm not going to cry when the CPU suddenly burns out and my machine shuts down. I'll be confused, annoyed, but I'll buy a new one--I might buy an entire new computer, unaware that just my CPU is broken, and shove the hard drive in there. So there's no harm in allowing the user's hardware to go ahead and burn itself out if you think that's what's going on here. By all means that doesn't mean you can't have a diagnostic center somewhere that the user can review and see the whole collection. "Ethernet: Lots of garbage [Possibly: Faulty switch, faulty NIC, another computer with a chattering NIC spewing packets]." "CPU: Overheats under high CPU load [Possibly: Dust-clogged CPU heat sink, failing CPU fan, overclocking, failing CPU, failing motherboard voltage regulators, buggy motherboard BIOS]." "/!\ Hard drive: Freezes and needs IDE Resets [Possibly
Re: cpufreqd as standard install?
On Sat, 2012-03-03 at 03:16 -0500, John Moser wrote: > On 03/03/2012 12:13 AM, Phillip Susi wrote: > > On 02/29/2012 04:40 PM, John Moser wrote: > >> At full load (encoding a video), it eventually reaches 80C and the > >> system shuts down. > > > > It sounds like you have some broken hardware. The stock heatsink and > > fan are designed to keep the cpu from overheating under full load at > > the design frequency and voltage. You might want to verify that your > > motherboard is driving the cpu at the correct frequency and voltage. > > > > Possibly. > > The only other use case I can think of is when ambient temperature is > hot. Remember server rooms use air conditioning; I did find that for a > while my machine would quickly overheat if the room temperature was > above 79F, and so kept the room at 75F. The heat sink was completely > clogged with dust at the time, though, which is why I recently cleaned > and inspected it and checked all the fan speed monitors and motherboard > settings to make sure everything was running as appropriate. > > In any case if the A/C goes down in a server room, it would be nice to > have the system CPU frequency scaling kick in and take the clock speed > down before the chip overheats. Modern servers--for example, the new > revision of the Dell PowerEdge II and III as per 4 or 5 years ago--lean > on their low-power capabilities, and modern data centers use a > centralized DC converter and high voltage (220V) DC mains in the data > center to reduce power waste because of the high cost of electricity. > It's extremely likely that said servers would provide a low enough clock > speed to not overheat without air conditioning, which is an emergency > situation. > > Of course, the side benefit of not overheating desktops with inadequate > cooling or faulty motherboard behavior is simply a bonus. Still, I > believe in fault tolerance. > > >> I currently have cpufreqd configured to clock to 1.8GHz at 73C, and move > >> to the ondemand governor at 70C. > > > > This need for manual configuring is a good reason why it is not a > > candidate for standard install. > > > > I've attached a configuration that generically uses sensors (i.e. if the > program 'sensors' gives useful output, this works). It's just one core > though (a multi-core system reads the same temperature for them all, as > it's per-CPU); you can easily automatically generate this. > > Mind you on the topic of automatic generation, 80C is a hard limit. It > just is. My machine reports (through sensors) +95.0C as "Critical", but > my BIOS shuts down the system at +80.0C immediately. Silicon physically > does not tolerate temperatures above 80.0C well at all; if a chip claims > it can run at 95.0C it's lying. Even SOD-CMOS doesn't tolerate those > temperatures. > > As well, again, you could write some generic profiles that detect when > the system is running on battery (UPS, laptop) and make appreciable > adjustments based on how much battery life is left. To restrict the maximum frequency when on battery / low battery? The last analysis I've seen, by Matthew Garrett, was that the most power-efficient way to run modern CPUs is to have them run as fast as possible - in order to do the pending work in the shortest possible time - then drop down to a low-power C-state. Thermal management is a different matter, and one which *should* be handled reasonably currently - either by the BIOS or by the kernel's ACPI subsystem. Restricting the CPU clock is not one of the things this will currently do, though. I recall when this has been brought up before the consensus has been that a robust solution would need to be implemented in the kernel, as there's no guarantee that userspace code will be run in time. Talking to the ARM guys at Plumbers 2011 it seems like this is something they'll be tackling. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2012 03:16 AM, John Moser wrote: > In any case if the A/C goes down in a server room, it would be nice > to have the system CPU frequency scaling kick in and take the clock > speed down before the chip overheats. Modern servers--for example, > the new revision of the Dell PowerEdge II and III as per 4 or 5 years > ago--lean on their low-power capabilities, and modern data centers > use a centralized DC converter and high voltage (220V) DC mains in > the data center to reduce power waste because of the high cost of > electricity. It's extremely likely that said servers would provide a > low enough clock speed to not overheat without air conditioning, > which is an emergency situation. AFAIK, DC distribution has not seen widespread adoption because it doesn't actually do any good. You still have to convert the power to 12v, 5v, and 3.3v to power the computer, and so adding a second conversion to high voltage dc makes things less efficient, not more, and adds expense both in the form of the central HVDC supply and having to replace the power supplies in the computers with DC ones. This is getting a bit off topic though. > Of course, the side benefit of not overheating desktops with > inadequate cooling or faulty motherboard behavior is simply a bonus. > Still, I believe in fault tolerance. It is nice in theory, and the ACPI standard provides ways to do this, unfortunately, basically nobody bothers to follow the spec so it generally doesn't work. More specifically, the bios is supposed to provide ACPI tables that define a temperature sensor that should be used to limit the cpu frequency, and at what threshold(s) the limit(s) should kick in. > I've attached a configuration that generically uses sensors (i.e. if > the program 'sensors' gives useful output, this works). It's just > one core though (a multi-core system reads the same temperature for > them all, as it's per-CPU); you can easily automatically generate > this. The need for manual configuration is the problem. You can't really automatically generate the configuration because different systems have completely different sets of temperature sensors ( many often are not even connected, they just return bogus values ), and so figuring out which one to use to trigger the cpu frequency throttling is necessarily a manual process. > Mind you on the topic of automatic generation, 80C is a hard limit. > It just is. My machine reports (through sensors) +95.0C as > "Critical", but my BIOS shuts down the system at +80.0C immediately. > Silicon physically does not tolerate temperatures above 80.0C well at > all; if a chip claims it can run at 95.0C it's lying. Even SOD-CMOS > doesn't tolerate those temperatures. If Intel says the silicon can handle 95.0C, then it can handle 95.0C. My ATI GPU regularly operates at 83-85C, and my CPU can hit that under ( very ) heavy load without a problem. > As well, again, you could write some generic profiles that detect > when the system is running on battery (UPS, laptop) and make > appreciable adjustments based on how much battery life is left. If you want to maximize battery life, then you can switch to the powersave governor. Slowing down the cpu by default can cause unexpected problems though, like dropped frames playing games or video, which would be highly undesirable. I am still not satisfied with the unity/gnome 3 replacements for the old cpu frequency panel app to allow for this. Fleshing those out a bit and making them easier to find and use would be nice. > Possibly, but the settings are all default, nothing set to overclock > (it has jumper free overclocking configuration, but the option > "Standard" is default for clock rate and voltage settings, which I > assume the CPU supplies). The CPU indicates to the motherboard what voltage it wants, but it is up to the motherboard to provide it. Yours may not be doing so correctly. Then again, 80C is a bit low so it may just be that the critical temperature trip point is set too low. > Basically the argument here is between "Supply fault tolerance" and > "Well your motherboard is [old|poorly designed] so buy a new one." > That's an excellent argument for hard drives (I have, in fact, > suggested in the past that Ubuntu monitor hard disks for behavior > indicative of dying drives--SMART errors, IDE RESET commands because > the drive hangs, etc--and begin annoying the user with messages about > the SEVERE risk of extreme data loss if he doesn't back up his data), > but really if my mobo/CPU is aging and the CPU runs a little hot I'm > not going to cry when the CPU suddenly burns out and my machine shuts > down. I'll be confused, annoyed, but I'll buy a new one--I might buy > an entire new computer, unaware that just my CPU is broken, and shove > the hard drive in there. So there's no harm in allowing the user's > hardware to go ahead and burn itself out if you think that'
Re: cpufreqd as standard install?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2012 08:10 PM, Christopher James Halse Rogers wrote: > To restrict the maximum frequency when on battery / low battery? The > last analysis I've seen, by Matthew Garrett, was that the most > power-efficient way to run modern CPUs is to have them run as fast as > possible - in order to do the pending work in the shortest possible time > - then drop down to a low-power C-state. This is incorrect. Lower frequency ( coupled with lower voltage ) provides less power per instruction. You may be confusing some of his writing about the p4clockmod driver, which doesn't actually lower the cpu voltage or frequency, but rather just forces the cpu to HLT as if it were idle for part of the time. This does not give better efficiency, which is why he patched that driver to refuse to bind to the ondemand governor. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPVXImAAoJEJrBOlT6nu75cNcH/jzL8H4AbrAa6sjva/W+cHyM ifhA8qmzVQGnTpZgK3OvUd7Z5nBD8k0RmhfLY5+ua7zWN/aIVga+lbxzURwqN+ez 50UG2MH7EIEpM9+U4OJbeTcKfvwOe/oQoCHFHHOnlGAMtgvw9WvSjUxr7J9HZdEc lZp8xpeHdE39/G/MGT6ARNkM6GXUJ9iGqBdTcZxY/Qnv+17NELX010x7GckeGBtC dd/trrsjvBHcjPwa5u+tj1Cnl9kJm+uctSuB0QXJq7mDDCMXLYwV7znVxwpj54cy XoOyBbyRnEtY9XQE6IFHold+/JpKOHeQFTiWWpKyTrsTXB+t4TNeBZ7+oQ7kanI= =Z2Mu -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Mon, 2012-03-05 at 21:10 -0500, Phillip Susi wrote: > On 03/05/2012 08:10 PM, Christopher James Halse Rogers wrote: > > To restrict the maximum frequency when on battery / low battery? The > > last analysis I've seen, by Matthew Garrett, was that the most > > power-efficient way to run modern CPUs is to have them run as fast as > > possible - in order to do the pending work in the shortest possible time > > - then drop down to a low-power C-state. > > This is incorrect. Lower frequency ( coupled with lower voltage ) > provides less power per instruction. You may be confusing some of his > writing about the p4clockmod driver, which doesn't actually lower the > cpu voltage or frequency, but rather just forces the cpu to HLT as if > it were idle for part of the time. This does not give better > efficiency, which is why he patched that driver to refuse to bind to > the ondemand governor. > Less power per instruction, or less power per instruction amortized over the run-time? My understanding was that hitting the low C-states was such a huge power win that the increased power per instruction was offset by the longer C-state residency¹. ¹: http://www.codon.org.uk/~mjg59/power/good_practices.html signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2012 09:19 PM, Christopher James Halse Rogers wrote: > Less power per instruction, or less power per instruction amortized over > the run-time? My understanding was that hitting the low C-states was > such a huge power win that the increased power per instruction was > offset by the longer C-state residency¹. > > ¹: http://www.codon.org.uk/~mjg59/power/good_practices.html That's the article that I was thinking of that is mostly about the p4clockmod driver. Using it means you have the same power per instruction, but also are spending less time in the deeper C states, and so is bad. With correct frequency management, the lower power per instruction of the lower frequencies outweighs the reduced time in the lower C states. There probably still is an optimal point somewhere between the min and max frequency where you get the benefit of both lower power per instruction when executing instructions, without giving up too much time in the lower C states, but finding that balance is tricky and highly hardware and load specific. My current CPU operates from 1600 to 3301 MHz ( where the last 1 MHz just enables turbo boost ). Disabling that turbo boost state would probably provide the most savings in power power per instruction with minimal loss of deep C6 time. At 1600 MHz with a load that keeps that frequency mostly busy very well may be more efficient at one of the intermediate frequencies, but figuring out which is tricky. One thing is almost certain: it isn't 3301 MHz. Of course, a load that keeps 1600 MHz rather busy would trigger the ondemand governor to shift to one of the intermediate frequencies anyway, so the default situation is probably quite near optimal. Load spikes that would cause the ondemand governor to shift to 3301 ( turbo boost ) would be best disabled when on battery power, but I believe that many laptops have proper ACPI bios that does disable turbo boost when on battery power, so we're good there too. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPVXjmAAoJEJrBOlT6nu751g0H/jX56H6Z2BySLaGb3n7Q5YmE I+iSFIgkIS0DqyKiaXLlr8c2doymUY20lam8D9U459RPV+dxMrxYAQ/rZxCeWEOm l/KdLPsF6+3PHPqAV3TgVwBt+NlvXvVhCvIMaLb8/IP0pOoibpKg65l+nhkpxRy/ QG04k5Fp3RjhPIyRiVm0KIhi5NVzyL8UJspzYlyFJbDrfdMShL3yhMZhRL+fPZxf vbO+2ZxkleaiD7iqHWpCb5l1DBmaOTaVoyr1zWShJ80+gBPsHAFX9ioJ8iuH0piw V8VJFqWC7Wx+w7PvtVyFInnUuQ8PQdy95XI1BYXCnesBW3gB+BpjivNN+q3pIYI= =/vKD -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Mon, 2012-03-05 at 21:39 -0500, Phillip Susi wrote: > On 03/05/2012 09:19 PM, Christopher James Halse Rogers wrote: > > Less power per instruction, or less power per instruction amortized over > > the run-time? My understanding was that hitting the low C-states was > > such a huge power win that the increased power per instruction was > > offset by the longer C-state residency¹. > > > > ¹: http://www.codon.org.uk/~mjg59/power/good_practices.html > > That's the article that I was thinking of that is mostly about the > p4clockmod driver. Using it means you have the same power per > instruction, but also are spending less time in the deeper C states, > and so is bad. With correct frequency management, the lower power per > instruction of the lower frequencies outweighs the reduced time in the > lower C states. There probably still is an optimal point somewhere > between the min and max frequency where you get the benefit of both > lower power per instruction when executing instructions, without > giving up too much time in the lower C states, but finding that > balance is tricky and highly hardware and load specific. My current > CPU operates from 1600 to 3301 MHz ( where the last 1 MHz just enables > turbo boost ). Disabling that turbo boost state would probably > provide the most savings in power power per instruction with minimal > loss of deep C6 time. At 1600 MHz with a load that keeps that > frequency mostly busy very well may be more effi > cient at > one of the intermediate frequencies, but figuring out which is tricky. > One thing is almost certain: it isn't 3301 MHz. Of course, a load > that keeps 1600 MHz rather busy would trigger the ondemand governor to > shift to one of the intermediate frequencies anyway, so the default > situation is probably quite near optimal. Load spikes that would > cause the ondemand governor to shift to 3301 ( turbo boost ) would be > best disabled when on battery power, but I believe that many laptops > have proper ACPI bios that does disable turbo boost when on battery > power, so we're good there too. > I think we might have wildly different interpretations of that article. The third paragraph is: “C states offer significant power savings, but cannot be entered when the CPU is executing instructions. The best power savings can be obtained by running the CPU as fast as possible until any outstanding work is completed and then allowing the CPU to go completely idle. The powersave governor will extend the time taken to complete the work and reduce the amount of time spent idle. On any modern CPU the benefit of carrying out the work at a lower clock and voltage will be outweighed by the loss of the idle time. In almost any workload, powersave will consume more energy than any other option.” And has: “Summary: Use ondemand. Conservative is a valid option for processors that take a sufficiently long time to switch performance states that ondemand will not work.” There's a *separate* dot-point about not using p4clockmod, but I read that as entirely separate. Of course, that was written in 2008; IIRC this is before the age of "turbo mode", so that might change the conclusions. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Mon, Mar 05, 2012 at 09:39:34PM -0500, Phillip Susi wrote: > With correct frequency management, the lower power per instruction of > the lower frequencies outweighs the reduced time in the lower C > states. This is (broadly speaking) untrue. There's a bunch of fixed costs that a naive P=IV² doesn't take into account. Assuming a fixed amount of work, race to idle is almost always the most power efficient strategy. -- Matthew Garrett | mj...@srcf.ucam.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On 3/8/2012 9:47 AM, Matthew Garrett wrote: This is (broadly speaking) untrue. There's a bunch of fixed costs that a naive P=IV² doesn't take into account. Assuming a fixed amount of work, race to idle is almost always the most power efficient strategy. What fixed costs? If you spend 5 seconds working at full throttle and consuming 100 watts, and then the next 25 seconds in deep C6 consuming 0 watts, you've spent 500 joules of energy. If you instead spend 10 seconds working at half frequency, consuming only 30 watts, then the next 20 seconds in deep C6, you've only spent 300 joules for the same work. When you factor in the typical increased execution efficiency you get at the lower frequencies, you probably could finish that work in only 9 seconds, cutting the energy expenditure down to 270 joules. Things are of course, quite different if your load involves waking up and doing some work every 10ms instead of the simple batch scenario. Here the time to enter and exit C6 becomes more significant so if you use the lowest frequency, you can end up having little to no time in C6, so using a higher frequency to get back into C6 might make sense, but using the highest, and most power hungry frequency ( power consumption tends to grow exponentially ) is highly unlikely to prove optimal unless using the next lower frequency would still leave the cpu very busy. If you can go down one step and the CPU can still spend the majority of its time in deep C6, then you should come out ahead. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Thu, Mar 08, 2012 at 11:03:42AM -0500, Phillip Susi wrote: > On 3/8/2012 9:47 AM, Matthew Garrett wrote: > >This is (broadly speaking) untrue. There's a bunch of fixed costs that a > >naive P=IV² doesn't take into account. Assuming a fixed amount of work, > >race to idle is almost always the most power efficient strategy. > > What fixed costs? If you spend 5 seconds working at full throttle > and consuming 100 watts, and then the next 25 seconds in deep C6 > consuming 0 watts, you've spent 500 joules of energy. If you > instead spend 10 seconds working at half frequency, consuming only > 30 watts, then the next 20 seconds in deep C6, you've only spent 300 > joules for the same work. When you factor in the typical increased > execution efficiency you get at the lower frequencies, you probably > could finish that work in only 9 seconds, cutting the energy > expenditure down to 270 joules. Yes, if those are the actual power figures. But they're typically not going to be. -- Matthew Garrett | mj...@srcf.ucam.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On 3/8/2012 11:10 AM, Matthew Garrett wrote: Yes, if those are the actual power figures. But they're typically not going to be. Can you be a little less vague and hand wavy? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Thu, Mar 08, 2012 at 11:22:04AM -0500, Phillip Susi wrote: > On 3/8/2012 11:10 AM, Matthew Garrett wrote: > >Yes, if those are the actual power figures. But they're typically not > >going to be. > > Can you be a little less vague and hand wavy? My i7 draws about 7W when fully loaded at 800MHz, and about 27W when fully loaded at 2.7GHz. That's a 3.4x performance improvement at a 3.9x power increase. So, naively, that does result in a fixed amount of work being carried out in a smaller amount of energy, although not anywhere near the extent that you're describing. But this is a very strange workload to be optimising for. First, it's entirely CPU-bound. If it involves IO then you're going to be keeping IO devices in a higher power state for longer, which wipes out the advantage. Second, it makes the assumption that the user doesn't care how much time it takes. That's basically never true. The only reason not to use race-to-idle is because you have an amazingly specific workload, one that's CPU bound and not user-interactive. That discounts pretty much every desktop, mobile and server use case. It's really not worth worrying about. -- Matthew Garrett | mj...@srcf.ucam.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2012 12:11 PM, Matthew Garrett wrote: > My i7 draws about 7W when fully loaded at 800MHz, and about 27W when > fully loaded at 2.7GHz. That's a 3.4x performance improvement at a > 3.9x power increase. So, naively, that does result in a fixed amount > of work being carried out in a smaller amount of energy, although not > anywhere near the extent that you're describing. You also need to remember that 3.4x the clock speed does not mean you actually end up finishing your work 3.4x faster. Intel recommends using the ondemand governor, so if you are claiming they are wrong, and you save more power using performance, that's going to take a little convincing. I checked on my desktop sandybridge core i5 system, and I found that running stress -c 4 with powersave draws 150 watts, and with ondemand, is nearly 200 watts. Idle, the system draws 125 watts. Factoring out that baseline gives a cpu load of 25 vs 75 watts depending on whether you run at 1600 MHz vs 3300 MHz, or 3x the power for twice the speed. I would expect the difference to be less marked on a laptop, since they tend to already have the higher frequencies disabled, keeping the whole range lower down on the exponential power vs performance curve, which would explain your results. On desktop systems with turbo boost enabled, you're going to climb pretty high up that exponential curve using the max frequency. I may have stumbled onto a bug because whenever I set the frequency to anything other than the lowest, the highest is used anyway. cpuinfo_cur_freq reports 3301 MHz even though scaling_cur_freq and scaling_setspeed report the requested lower value. I would expect the 3000 MHz setting to be a good bit more energy efficient while only giving up a negligible amount of real world performance, but I can't seem to get it to work, so I can't test. > But this is a very strange workload to be optimising for. First, it's > entirely CPU-bound. If it involves IO then you're going to be keeping IO > devices in a higher power state for longer, which wipes out the > advantage. Second, it makes the assumption that the user doesn't care > how much time it takes. That's basically never true. We're not talking about a 100% cpu bound workload of course; we're talking about typical loads where the cpu is mostly idle, and the question is whether it is better to spend a bit more time idle, and be less efficient when actually executing instructions, or be more efficient at the cost of a little less idle time. If you ignore the time it takes to enter/exit the deep C states, you can model the different execution speeds and how much energy they consume as a simple 100% busy period followed by a fully idle period, with a total duration being the same in both tests. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPWTLXAAoJEJrBOlT6nu75MWgH/iNkEmgvb3TK7iLxlcaz4zQg a+BbS2Cu9B4p3OORtG9k5RDTK5k9N5iLOTb1kvchRTJCw8t7XUmTeMzNCrL85JvV qWSoiEpqGqh1T3lKan2/79Uz3eADoqeY2pRVHHFoxgHjaWT4KXLl8ATozKpvfvJ5 /jYHLH6GbPyIW0IPFXVM329INGnsC0eOqZ43+EHKaWZ8c2kT8e9eXjGydBevvyhd flyk/R8fj5Iz/AtCIGYrY91/Hwp7A07WKjv81Elfb6BVpebLZjLTomsepKOfGt0T rayg/YRVjpO3OrO9kbkVbvQjCT9ZKbcG5MtE+6tv63qfajP7F0z2BlT+umBJ4L0= =QSGz -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: cpufreqd as standard install?
On Thu, Mar 08, 2012 at 05:29:47PM -0500, Phillip Susi wrote: > You also need to remember that 3.4x the clock speed does not mean you > actually end up finishing your work 3.4x faster. Intel recommends > using the ondemand governor, so if you are claiming they are wrong, > and you save more power using performance, that's going to take a > little convincing. I checked on my desktop sandybridge core i5 > system, and I found that running stress -c 4 with powersave draws 150 > watts, and with ondemand, is nearly 200 watts. Idle, the system draws > 125 watts. Factoring out that baseline gives a cpu load of 25 vs 75 > watts depending on whether you run at 1600 MHz vs 3300 MHz, or 3x the > power for twice the speed. Do a SpecPOWER run with performance and with ondemand and you'll see that there's very little difference on modern hardware. > > But this is a very strange workload to be optimising for. First, it's > > entirely CPU-bound. If it involves IO then you're going to be keeping IO > > devices in a higher power state for longer, which wipes out the > > advantage. Second, it makes the assumption that the user doesn't care > > how much time it takes. That's basically never true. > > We're not talking about a 100% cpu bound workload of course; we're > talking about typical loads where the cpu is mostly idle, and the > question is whether it is better to spend a bit more time idle, and be > less efficient when actually executing instructions, or be more > efficient at the cost of a little less idle time. If you ignore the > time it takes to enter/exit the deep C states, you can model the > different execution speeds and how much energy they consume as a > simple 100% busy period followed by a fully idle period, with a total > duration being the same in both tests. You're ignoring far too many factors for this to be terribly relevant. -- Matthew Garrett | mj...@srcf.ucam.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
