cpufreqd as standard install?

[Phillip Susi]

-----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'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:  Dying hard drive/!\, dying
> IDE controller, dying RAID controller] /!\WARNING:  SEVERE DATA LOSS
> POSSIBLE".  Etc.  Looks like you really need a new computer...

That's not a bad idea, but a rather large undertaking.  You might work on hashing out some more details and write up a blueprint and see if it is accepted.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPVXFaAAoJEJrBOlT6nu758nEH/Atb8g+NowxzS9Z5R8ub1yLW
b//gxl3/KmgguiII9qtflf5LdWp8AvGLC1bSpG6hgYG7bp9dS5XdcV18DOmITrRq
/7r6m2l6Bn7Yb336tX8bgnjEc3B8+H2syWBXdFxXwaFEXZbV+xN2xw8SMH6iPh6y
+9fZRF8BLUqaVSMWMU9zhQJQvSc8q7uV8+FdUbd3uQI7FrgjW0O1vM2pYk/tfrAb
dzhiCQpFGz6JBireR3wFMLSvtb4GzDcE+pFge0KQCpjSeAx9n7oj7zWwnU43kvAl
k7SekCFCZKRLf6azGNUrBkcNDmsONZxclYWAkc1G2ggv6aRJ/8CYZF7VcTb/yLc=
=3cCb
-----END PGP SIGNATURE-----