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
