Keeping cool

I’ve just installed CPUClock 2.04 without using a package manager

as have I today after learning of a later version, but on my RPi2 (ARMv7, fast mode).

Mine has retained the configured 600/1000 MHz settings and seems to be working just like my previous version, if that’s of any help.

I have the 1000MHz maximum speed set in my CONFIG/TXT, whereas I believe the 600MHz lower speed is dictated by CPUclock itself.

Edit: CPU temperature 48.6°C

2nd Edit: Hope it’s not that central heating controller gone awry, Dave!

Does the chip temperature limit the configured top speed?

CPUClock will reduce the high speed temporarily if the cpu die temperature exceeds the configured maximum temperature. With some boards there are several allowable cpu speeds (e.g. OMAP3, OMAP4, OMAP5). If this is the case then CPUClock will reduce the speed in stages. For other hardware, eg RaPi, there are only two speeds available. The configured max temp can be set by going into choices. For a BB-xm, 70C would be normally safe. I am not sure what the design limit is. I used 70C when using the BB without problem.

For what it’s worth, Pis are supported up to 85°.

Pis are supported up to 85°.

While a Pi can run at 85°C, I wonder – given the thermal expansion properties of the materials used – if frequently hitting those sorts of temperatures won’t adversely impact the lifespan of the equipment?

<paranoid>my Pi is set to step itself back if it should pass 60°C</paranoid>

The configured max temp can be set by going into choices. For a BB-xm, 70C would be normally safe. I am not sure what the design limit is. I used 70C when using the BB without problem.

For the BB-xM, section 3.2 of the DM3730 datasheet contains the answers

It’s a commercial grade chip, so table 3-4 shows that it’s rated to operate at temperatures up to 90 degrees. However table 3-3 shows that lifespan is reduced significantly once the temperature starts to go above 75, especially when it’s running at high speeds. So that’s probably a sensible limit at which to start throttling.

The OMAP3 datasheet provides slightly less info (section 3.3). 90 degrees is still the design limit, but there’s no guidance given for whether temperatures near that mark might start to impact lifespan, only the general guidance that constantly running the chip at high speed will degrade its lifespan.

Of course for a lot of these devices you’ve got RAM or flash chips stacked ontop, so for the full picture you might have to check what temperatures they’re rated for (and then find a way of reading their temperature! I think there’s meant to be a way for the OMAP chips to sense the temperature of the RAM, but I’ve never got to the bottom of how it works)

I suppose an interesting thing to do to test whether your device is thermally sound would be to try running some of these cpuburn code sequences. Sadly I can’t find any obvious Cortex-A15 versions, although considering the IGEPv5’s propensity to overheat even for single-core use I doubt that’s going to be much of a problem.

(And yes, many of our devices are multicore, so I should probably hurry up and make an MP-safe version of VFPSupport…)

Beagle-xM = Cortex-A8 (though I think this example is Thumb code!?)
Pandaboard = Cortex-A9
Raspberry Pi2 (initial) = Cortex-A7
Raspberry Pi2 (later) and Pi3 = Cortex-A53

Anybody able to build these (for RISC OS!) for those willing to stress test their machines? Hmmm… Will the Thumb one work at all on RISC OS?

While a Pi can run at 85°C, I wonder – given the thermal expansion properties of the materials used – if frequently hitting those sorts of temperatures won’t adversely impact the lifespan of the equipment?

Interesting thought – followed by a surprising conclusion…

A significant failure mechanism in power transistors was thermal cycling. (Was = I know of it from years ago, but I haven’t updated my knowledge on the topic in years.) Note that it’s not the high temperature that did the damage; it was the number of changes in temperature. A device kept at a constant high temperature would be expected to last far longer than one that was frequently cycled up to that same temperature and down again.

So if that’s the case with our CPUs, perhaps they would be more reliable if we didn’t keep stepping the clock frequency up and down?

Note that it’s not the high temperature that did the damage; it was the number of changes in temperature.

Similarly old info I suspect but the standard test rig at my first employer involved putting the (allegedly faulty) equipment under test into a cabinet the cycled the temperature and vibrated to induce thermal degradation of joints and marginal performance components.
Production test was a bit more gentle.

So if that’s the case with our CPUs, perhaps they would be more reliable if we didn’t keep stepping the clock frequency up and down?

There’s probably a good case for selecting a standard clock speed that is less than the maximum and a lower speed for higher ambient conditions or internal overrun with the assumption that the system is expected to run at the higher rate unless the thermal trip kicks in and then latch low.

followed by a surprising conclusion…

Not so surprising, expansion contraction expansion contraction, it’ll lead to fatigue in the end.

That’s partly why I set my throttle back at only 60C. Might seem incredibly low, but it’s 20C over the normal running temperature, which is 20-30C over “off”.
Besides, not even starting up Otter or building the OS itself warmed the processor that far…er…or at all really. So it’s a safeguard mostly.

So if that’s the case with our CPUs, perhaps they would be more reliable if we didn’t keep stepping the clock frequency up and down?

Running at a constant clock speed won’t result in the chip running at a constant temperature, unless you’re also able to make it run a constant workload. Consider the cpuburn examples linked above – they aim to make exercise as many pipeline stages/execution units as possible, causing the CPU to work harder and generate more heat than it would do when executing a more ordinary code sequence.

But on the idea of running at a constant temperature in general:

I can’t immediately find any conclusive proof, but I believe that both heat and voltage contribute to component degradation. Which means that you’ve got three causes of degradation:

• If you run the device at a high temperature, it’ll wear down
• If you run the device at a high voltage, it’ll wear down
• As the temperature cycles up & down, the mechanical stresses of it expanding & contracting in the heat will wear it down (as you describe)

However I’m not sure in what ratios the above combine in order to determine the overall lifespan of a device, so it’s hard to say how much you’d be able to extend the lifespan if you were to eliminate the thermal expansion element.

Also, you’re dealing with devices which are typically rated for 100K+ POH of reliable operation, so getting any trustworthy results from your experiments may take a long time.

I’ve installed it on soome rPi 2s, and the displayed high and low speeds are both 700MHz, with the menu icon greyed out. Is this to be expected? They are running RO5.23 (13 Apr 2017).
There are a stack of 4 rPis in a toolbox, running off an ATX psu that also provedes 12 volts for four 7 inch monitors. The ATX fan blows air out of the case, and holes ensure that the air drawn in passes over the rPis. They are running about 30C above ambient, with RO mainly idle.

Do the original RPi2s have the capability to switch speeds?
I know RPi1 did not, and RPi3 does, but unsure about RPi2 (and there are two different sorts!)

Are you sure that the processor is mainly idle?

Do the original RPi2s have the capability to switch speeds?

Yes. 600MHz and 900MHz.

Are you sure that the processor is mainly idle?

He said that the speed showing for high and low was 700MHz. That sounds like the idle speed.
On my Pi, if I open a filer window and wiggle the mouse over it or drag the window, etc, the speed will kick up into high for a few moments, then drop back down.

I’ve had it get “stuck” for a while on high, I wonder if this is due to something claiming null events?

On the original Pi, is there a way to tweak the idle speed? If the machine is pretty much twiddling it’s thumbs, it could do so at 400MHz, maybe even lower?

Do the original RPi2s have the capability to switch speeds? I know RPi1 did not, and RPi3 does, but unsure about RPi2 (and there are two different sorts!)

Please read my post at the top of this page and remain unsure no longer, Martin! My Armv7 RPi2 (earlier sort!) definitely runs at 2 speeds!

….. whereas I believe the 600MHz lower speed is dictated by CPUclock itself.

You can set the lower speed as well using arm_freq_min= in config.txt.

I have a Pi 1 running at 400MHz.

My Armv7 RPi2 (earlier sort!) definitely runs at 2 speeds!

So the question is why are Alan’s only showing 700MHz as the one possible speed?!

Firmware version? config.txt? RO version?

The Pi build gained the required CPU clock support in March 2016, so Alan’s RISC OS build from April 2017 should be new enough. So my guess is something in config.txt which is overriding the firmware’s default clock settings (or maybe a really old/busted firmware? config.txt seems more likely)

CPUClock doesn’t interfere with the clock settings at all when it starts up. It uses OS calls to enumerate the available speeds – if it thinks there is only one speed available then that is what it has been told 8) As Jeffrey has indicated – check all your settings. You can run CPUClock to just tell you what the cpu is being clocked at at any instant. As others have said – when the cpu is ‘idling’ the wimp should put the cpu into slow mode. Dragging windows around the desktop, particularly over other windows that require a lot of redrwing or on and off the edges should kick the cpu in to fast speed.

Is the CPUClock module accessible to other programs?

Last night I soldered a more useful connector onto the salvaged notebook chipset fan and connected it to an Arduino using a demo program that came with the FanControl library. I only tried it for a few seconds because it was drawing power from my tablet but the speed control and tach seemed to work.

If I an wrap my head around IIC in RO, I want to set up a uC as an IIC device and run a module for controlling the fan. I might just be lazy and go the Arduino route. Who knows.

A decent chunk of the year, passive cooling just doesn’t do the job, even indoors with the evap cooler running. I know it’s an overcomplicated project, but why not?

Just a note on the Arduino program I found. It does the smart thing and uses interrupts for catching the tach signal. This is where the thick, glossy veneer of Arduino breaks down. I feel that interrupts may have to be disabled for IIC communication unless it can do hardware IIC. It can cope with UART communication just fine because it’s buffered. Trying to handle IIC without a buffer and maybe 10,000 interrupts a second firing the signal may get a little garbled.

Is the CPUClock module accessible to other programs?

That would be very useful.

I have a remote server that would be good to monitor. I can see (and control) most things remotely but not the cpu temperature.

Is the CPUClock module accessible to other programs?

Yes. It has a SWI interface, although I have not got around to documenting it. I have also mused over ‘star commands’ but they are not in the released module.

If you need info to use it (the module) contact me privately (chris at chris hyphen johnson dot org dot uk).

Interacting with the module running on a remote machine might be more of a challenge as things stand. I would have to think about that.

FWIW I’ve just installed a basic (passive – no fan) pot-metal heatsink on my Pi3. This seems to have reduced operating temperature by around 5 deg. C. regardless of load over the last 24 hours since fitment. The Pi now idles at around 50-52 deg and peaks in the mid-sixties. I have CPUClock set to throttle at 72 deg, but I’ll probably lower that now on the basis of the new values. The Pi sits in a lidless, well-drilled plastic case, VESA-mounted on the back of the monitor.

Interesting.
The HDMI Mini to HDMI adaptor cable arrived for my Pi Zero today, so I can use it with RO again. Well, like my old one anyway. It’s bare ie no heatsink. It’s attached to what I’d call a backplane with some other boards on it. It’s sitting on about 51*C and it’s a hot night.

I put a right angle GPIO header on my pi and am using it with a Pi prototyping board. The RTC, DAC board, and the OLED (sort of) stick up too. It was an interesting experiment at least.

Is the CPUClock module accessible to other programs?

Yes. It has a SWI interface, although I have not got around to documenting it. I have also mused over ‘star commands’ but they are not in the released module.

It would be very useful for keeping an eye on remote servers. (or even local ones).

Interacting with the module running on a remote machine might be more of a challenge as things stand.

Surely a simple CGI script on a web server could do the job.