Temperature Monitors

Are there temperature monitors for the ARMX6 and Titanium computers?

More generally, for which ‘RISC OS’ computers do we have temperature monitors?

I have just found one for the ARMX6, CPUClock. I overlooked it because the icon said only CPUClock.

According to the Help, it works on other ‘modern’ computers too. I’ll try later on my Titanium – only just switched it off in case it overheated on what is a very hot day here!

CPUClock works fine on the Titanium and IGEPv5, and RaPis.

I am surprised you are having the ARMX6 heating up. With mine I do not think I have ever managed to get the cpu temperature higher than about 40 deg. My R-Comp ‘standard’ ARMX6 has a fairly beefy fan and the cpu is ‘underclocked’ at 1008 MHz, rather than the rated speed of 1200 Mhz. The Titanium and the IGEPv5 certainly do warm up when working hard.

I should add, you should be using the latest version of CPUClock (v. 2.09, 24 Apr 2021, module version 0.10) – module version 0.09 could cause a floating point exception under certain circumstances.

CPUClock updated to version 2.09 on both ARMX6 and Titanium.
On the Titanium I am getting 60C and 250MHz idling and 1500MHz when moving a window. On the ARMX6 I am getting 50C and 324MHz idling and 1008Mhz when typing this post.

My Pi2 is currently 44°C. It has a heatsink, and there’s an external fan keeping the Vonets, power brick, and Pi cool. The Pi is also set to idle slower (300MHz, IIRC) and to throttle (via CPUClock) at 55°C. Though ambient indoors is only around 22ish so it’s okay.
[picture here – https://heyrick.eu/blog/index.php?diary=20170807 – third or fourth one down]

Well, I have just seen the Titanium go up to 65C at which point CPUClock shows red in its status window, and the Titanium was doing little, maybe moving a window. The ambient temperature has been about 30C today.

The mini.m is the one which runs a bit toasty due to being an ARMX6 in a 2 inch cube, CPUClock often showed it going over 70C, with no ill effects. It runs a little cooler after I took it apart and applied some new thermal paste to the chassis/heatsink.

I know I’ve raised the issue of temperature many, many times, but there’s something seriously wrong with RISCOS when it comes to CPU throttling. A Pi3 will quickly go over 60C under an idle RO, when under Linux it won’t go much over 30C.

My guess is it’s a multi-core issue, perhaps the OS isn’t keeping unused cores in a permanent halt state?

This morning, after both computers have been off for the night, I powered up the ARMX6 and Titanium at the same time and, with the Titanium idling, its CPU temperature after an hour was about 60C (running at 250MHz) sometimes hitting 65C (CPUClock status colour red), while the ARMX6 got to a peak of 50C (CPUClock status colour green). I was running an application on the ARMX6 during this hour since power on, but the Titanium has been doing nothing.

And there was me thinking, as we are told, that ARM processors don’t need a fan as they are so cool.

CPUClock status colour red

There is nothing magical about 65C – the temperature at which CPUClock starts to reduce the clock speed is user configurable. The official maximum rated operating temperature for these various cpus is usually much higher. I just used a default of 65C to cover most eventualities.

sometimes hitting 65C

I think the maximum junction temperature is something in the order of 120°C. 65°C is being a bit paranoid. My 55°C is being extremely paranoid.

And there was me thinking, as we are told, that ARM processors don’t need a fan as they are so cool.

No – as we were told, when ARM processors clocked a couple of hundreds of megahertz and were tiny little things that needed no heatsink and could probably boot and run an OS off a watch battery…
…contrasted against the early Pentiums of the same era that were large slabs requiring heatsinks and fans for cooling at roughly the same sorts of clock speeds, and could likely not manage to start the processor off a watch battery, never mind an operating system!

Fast forward a few decades, ARM devices are multicore and clock speeds up in the gigahertz ranges, not to mention additional cores such as GPU and memory management and whatever else (DSP, Huffman encoder, etc) the manufacturer thinks will be useful. They’re still small, they’re still efficient, but they generate heat. It’s a pretty simple equation – the faster the processor runs, the more heat it will generate. That’s why modern systems have fairly advanced and fine grained speed management.
RISC OS, on the other hand, pretty much only has a “high” and a “low”, a system dating back to the A4 laptop, where the idea was not to reduce heat (there wasn’t any at those speeds), but to preserve battery life.
As far as I recall, it’s the Wimp that looks after the speed selection, idling at slow speed and bumping it up any time something happens (namely a notable mouse movement or keypress). Because of this, it’ll be cranked up to full speed when doing anything single-tasking. Not ideal, but just another part of the long-ago heritage of how these things came to be.

At any rate, “ARMs don’t need a heatsink” is now about as true as “Windows is still full of 16 bit code”. Once upon a time, yes. These days? Just no.

I Just tried to update CPUClock using PackMan but got an error. Here is the log.

The files for the packages have been installed correctly, but
the following warnings occurred during configuration.
Component ‘SCSI::SSD.$.Apps.C1.!CPUClock’ has not been installed’!)

The change to the default install location may be relevant.

….it’s the Wimp that looks after the speed selection, idling at slow speed and bumping it up any time something happens (namely a notable mouse movement or keypress). Because of this, it’ll be cranked up to full speed when doing anything single-tasking.

I find CPU speed tends to get ‘stuck’ at the higher setting (1500Mhz on this Pi4) even when no processes appear to be in progress (i.e. !Usage indicating 100% idling), especially if the machine has been running for more than a few hours. Restarting restores CPUClock’s ability to cycle promptly between fast and slow states, but after a few hours it becomes lazy and sticks at the higher setting.
Has anyone else experienced this quirk? I’m using the latest version – 2.09 (24 April 2021, module 0.10) – on a Pi4 running the most recent stable OS version (5.28 19-Oct-20).

I find CPU speed tends to get ‘stuck’ at the higher setting (1500Mhz on this Pi4) even when no processes appear to be in progress (i.e. !Usage indicating 100% idling)

I’ve noticed similar – but not identical – symptoms. In my case the displayed CPU speed doesn’t get stuck at the high speed, but it can oscillate between “low” and “high” for up to 2 minutes after a CPU-intensive task has been run. This effect is more likely when the machine has been running for some time.

CPUClock 2.09, Pi 4B, RISC OS 5.28 (16 December 2020).

… but it can oscillate between “low” and “high” for up to 2 minutes

Yes, I get that after a restart, when CPUClock is still responsive (i.e. not sticking at a particular speed). I’m wondering if my module settings are contributing to the particular behaviour I’m getting – they are as follows:
Temp read interval 75 cs;
Enable auto temperature control = Yes;
Maximum temp 65 deg.C;
Differential 5 deg.C;
Use rolling average = No;
Enable IRQs during callback = Yes;
Enable fan control = No;*
Fan trigger temp 55 deg.C;
Differential 4 deg.C.

[*the Pi is fanless]

Operating temps are currently in the 55-62 deg.C range: the Pi will throttle down as expected if temps hit 65 deg.C but it doesn’t happen often. If I reduce the maximum temp. to 60 deg.C, say, the Pi is initially throttled down to 600MHz when the limit is hit, and reverts to 1500MHz when the temp drops to 55 deg.C, but it DOESN’T throttle back down until the temp again rises to the upper limit, which indicates to me that the ‘sticking’ behaviour is still in play.

It’s called hysteresis, and you have it set to 5 degrees.

As far as I recall, it’s the Wimp that looks after the speed selection, idling at slow speed and bumping it up any time something happens (namely a notable mouse movement or keypress).

There is an open merge request that makes a small modification to the way the Wimp determines if the CPU is idling or not. I’ve never tested the small change, but it would be interesting for those having issues around idling to create a test ROM with these changes and see if it helps their particular issue.

There seems to be some misunderstanding here. CPUClock does NOT switch the cpu between fast and slow speeds. That is a function of the wimp and OS. What CPUClock does is to monitor the cpu die temperature and if it rises above the user configured limit, then it reduces the cpu fast speed, until the cpu temperature falls. There is hysteresis built in, as Dave said, to prevent the hunting of the fast speed setting if the cpu is just hovering at the set temperature.

If the cpu is staying at the fast speed then the cpu must be working on something and not idling.

If the cpu is staying at the fast speed then the cpu must be working on something and not idling.

Prompted by your comment, Chris, I systematically quit icon bar apps (my system loads about a dozen on booting) until the CPU speed as displayed by CPUClock started behaving normally, i.e., cycling to the lower speed when idling. It looks like !Avalanche is the culprit: not loading it fulltime seems to solve the issue I had. Thanks to all for the responses.

It’s probably a WimpPoll NULL claimer – the enemy of power saving.

Avalanche is a VNC client. VNC is known for voluminous network traffic, which takes lots of CPU cycles to consume.

It’s only poor design if Avalanche wasn’t connected to a server and was still soaking up CPU cycles. When it’s connected you’d expect it to consume lots of CPU cycles anyway.

This may be an opportune moment to enquire whether an RDP server for RISC OS is a reasonable prospect, within a reasonable timescale.

I have just launched !Avalanche and checked using TaskUsage. It appears to be well behaved. If running, but not connected, then its cpu usage is 0%, and CPUClock shows the fast/slow switching to be entirely normal.

I have noticed that Iris locks the cpu into fast mode.

Do you have !Avalanche connected to a server all the time?

… its cpu usage is 0%, and CPUClock shows the fast/slow switching to be entirely normal.

Yes, that’s how it behaves here – for a short period after booting. After several hours CPU speed sticks at the higher figure; quitting !Avalanche then appears to restore normal behaviour. I suggest you leave !Avalanche running for several hours to see if CPU behaviour changes similarly.

Do you have !Avalanche connected to a server all the time?

No. Once the high-speed behaviour is established, it seems to make no difference whether it’s connected to a server or simply running.

Caveat: I’ve described my current best analysis. But I shall do some more exhaustive testing and report.

It’s probably a WimpPoll NULL claimer – the enemy of power saving.

Avalanche does claim NULLs … but it uses WimpPollIdle, so does not appear to consume lots of time in handling them. However, I am not sure how it handles the intervals between Polls – when running but nothing connected it does about 27 polls/sec, but when connected to one or two servers it does about 55 polls/sec. The polls are:

• low, and processor time is 0%,
• seem to vary,
• seem to raise the CPU temperature (on this Titanium) by about 5 degrees (55 to 60)
• seem to make top processor speed more likely than low speed

Perhaps the activity threashold when the speed is switched to high is lower than we think?

Just my observations!
I will leave it running and not connected to see if time has any effect here.