Benchmarks

The name of a river or lake or other geographical feature…?

I wonder what comes after v0.9.9?

It’s obvious – v0.9.9.0

The name of a river or lake or other geographical feature…?

No, no, you’ve got to plod your way through all the different feline species first…

Rick, you forgot

I didn’t forget, I just didn’t think it was that worthy of a mention given that the underlying system was the same, and that there’s more to a computer than a processor.

That was the 2nd largest jump in performance of Acorn systems,

Yes and no. In terms of raw processor grunt, it was an enormous leap. But it was hobbled by a lethargic memory bus. People talked about how it utterly flew when running single tasking BASIC programs, with both the program and the interpreter fitting into the caches… But in the real world it behaved rather less impressively that it should have, because of the tedious memory constraints.
It was bad enough that somebody designed and built a processor card with the StrongARM and fast memory directly side by side. The Kinetic. Of course, that slaughtered DMA, so some you win some you lose.
And let’s not talk about the fact that podules were, well, podules. They could be 32 bit (but were any?) but they were still 8MHz synchronous max. That’s your I/O world.

So, kick ass processor, slow memory, even slower harddisc/networking.

You would have felt a difference, certainly. A processor clocking 5x faster is hard to ignore, but a combination of the base machine not getting any faster, and the overzealous use of cache synchronisation (just in case!) will mean it won’t have been able to demonstrate what it was really capable of.

you’ve got to plod your way through all the different feline species first…

Aegean, British Shorthair, Asian (sits with one paw in the air bobbing it’s head up and down)….

…okay, I’ll go get my coat.

Asian (sits with one paw in the air bobbing it’s head up and down)…

it’s/its.

I will presume you mean front paw, otherwise you’re describing a common sight of a cat cleaning up with one rear paw pointed skyward.
Often leading to the “forgotten paw” where they switch to scanning their surroundings while retaining the skyward pointing paw.

it’s/its.

I know that. My phone clearly doesn’t. Grrr!

I will presume you mean front paw,

I was thinking of…

Often leading to the “forgotten paw” where they switch to scanning their surroundings while retaining the skyward pointing paw.

It’s not forgotten, they just don’t move it if they don’t have to. After a good look around, if nothing interests them, they’ll resume licking.

Reminds me – I trolled Anna today.
Came home from work, went down to her stable, opened the door so she could run around (supervised).
Oh my god, the noise.
Anybody would think she was being tortured. It was only raining. And fairly lightly at that.
Cat’s gotta learn that she was born in Brittany, not the Costa del Whatever. She’s had a nice summer. It’s now about to get plenty worse.
So, back in her stable. Lots of stroking and a tin of food later, she was satisfied that the world wasn’t ending.

Me? When I went back to the house, it was raining a lot harder. I considered mewing pathetically, but they would be The One Time there’s a neighbour within earshot, so I didn’t.

Finding my Pi4 was regularly throttling itself to 600MHz due to the CPU overheating (no passive or active cooling currently), I thought I’d run some comparative graphics-intensive benchmarks to see how a deliberately throttled* Pi4 stacked up against its predecessor (in my case, a Pi3).

As can be seen, the throttled Pi4 is effectively equivalent to a Pi3 running twice as fast, which certainly surprised me.

Note:

• by setting CPUClock at an artificially low temp.

• time to display 12 c.5MB JPEGs with step time set to 0 secs.

which certainly surprised me.

Indeed. So what we need now (hello Jeffrey?) is to fiddle the Wimp so it always runs the machine at slow speed, and a new SWI “Wimp_ArseKick” that accepts in R0 a number of centiseconds in which to run at high speed.

That way, when stuff needs to get done, it can be. Otherwise no risk of overheating because the processor won’t be taxed every time the mouse moves over an icon…

So what we need now

Or one of these: https://www.jeffgeerling.com/blog/2019/best-way-keep-your-cool-running-raspberry-pi-4 ?

Either a large passive heatsink or a 30-40mm case fan on 3V3 is all that’s needed to prevent throttling.

Either a large passive heatsink

Just to update, rooting around in the spare parts/superannuated Pi’s cupboard I found a CJE Micros passive heatsink* off my Pi1 which has reduced the Pi4’s temp to acceptable levels in normal use, 60-65 deg. C.
[*http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=VAR-HEATSINK]

what we need now (hello Jeffrey?) is to fiddle the Wimp so it always runs the machine at slow speed

We need someone to do some serious investigation into why RISC OS causes such high temps. My Pi3 runs at 60 just sitting at the desktop doing nothing. Raspbian, it’s around 43.

CPUClock reports its at the low clock rate, but what it doesn’t show is how many times the clock is being changed/sec and how many hardware vectors are being called/sec. I wonder if it’s this last point that is generating all the heat.

We need someone to do some serious investigation into why RISC OS causes such high temps.

Wasn’t there something about unused cores being a problem and that controlling those (or stopping them) saved quite a bit of power?

Wasn’t there something about unused cores being a problem and that controlling those (or stopping them) saved quite a bit of power?

max_cpus=1

So what we need now (hello Jeffrey?) is to fiddle the Wimp so it always runs the machine at slow speed,

It is possible to set the high and low speeds using !CPUFreq so that, for example, it switches between 600MHz (slow) and 600MHz (fast).

It is possible to set the high and low speeds using !CPUFreq so that, for example, it switches between 600MHz (slow) and 600MHz (fast).

That is also possible with CPUClock.

into why RISC OS causes such high temps.

I think because the speed controlling is very simplistic. It uses a Portable module, originally created for the Acorn A4, which understands “fast” and “slow”. When nothing is going on, the machine runs slow. The moment something happens in the desktop, it runs fast.
That’s it.

When I stop typing, CPUClock says my Pi2 is running at 400MHz (I had intentionally slowed it down ¹ because of the hot summer). When I press a key, or move the mouse over something, the clock bumps itself up to 900MHz (with a switch-off lag of about 2 seconds so it isn’t always yoyoing back and forth).

Firstly, the system really ought to keep some sort of track of average polling rate, and bump up the CPU speed when the polling rate drops (indicating that something is taking time). I think the current logic is that it drops to idle speed while the desktop is null-polling (or skipping apps if PollIdle), and the moment there’s an activity of some sort, up it goes.

Secondly, if you go to the command line and enter SYS "Portable_Speed2", 0 TO s% : PRINT s% you’ll see it reports the fast speed. Outside of the desktop world, if you need speed switching, it has to be done manually. ²

Thirdly, if you look at a mobile phone using Aida64, or some sort of system status widget on Linux, you’ll probably notice that the device steps through a number of different rates depending upon workload. It’s not simply a matter or fast or slow. My phone is capable of running it’s eight cores (4 main, 4 thumb) from 455MHz to 2704MHz. I think the 2704 is for the Thumb, and the main cores max out at around 1.8? Either way, doing that for any measure of time would turn the phone into a small incendiary device. In standby (screen on), the main cores run at 455MHz, the Thumb ones at 650MHz. Drag the screen, the main cores jump up to 832MHz (858MHz for the Thumb), and once in a while it does it differently – main cores at 715MHz and Thumb cores at 1469MHz. The speed drops back down immediately (like within half a second).

Playing a streaming radio station (WiFi, decoding, MP3 and ICE block info, etc) and the main cores spent some some time at 1794MHz, and once in a while bump up and back down. The Thump cores spent some time also at 1794MHz, but have dropped to 650MHz. I’m guessing the initial work was sorting out the buffering, and now that everything is in place, as long as nothing complicated happens, the system can mostly run it while idling.

This isn’t to say my phone is great, it’s to highlight that a system that needs to run cool and use the least amount of power possible (small size, poor cooling, finite battery capacity) uses a very fine grained control of processor speeds. And, for similar reasons, I would imagine this is just built into Linux (Windows, etc) as standard. Why run the processor at full tilt if you only need a little extra speed?

Fourthly, logic would say that if the Wimp polls all of its applications and there’s nothing to do, it ought to put the processor into a halt/idle state (until the next interrupt, be that a device or the regular ticker).

Looking (briefly) at the Wimp, it looks like the primary speed control is a selection between fast and slow, using some sort of algorithm. There appear to be four cases (polling, waiting for keyboard, waiting for mouse (?), and waiting on Press Space or… ) where the machine is stuck into idle state until the next interrupt.

¹ As the machine jumps up to 900 when I’m using it, and basically idles at 400, I’ve not noticed any specific difference between idling at 400 and idling at 600; so I’ve just left it at 400.

² I’m talking about the standard machine here. If you’re running CPUClock, it has a module to keep an eye on temperatures, so it will switch down upon getting too hot ^{3 4} regardless of whether or not one is in the desktop.

³ I’ve set mine to step back at 54°C. I know it’s good to around about 80, but would prefer not to have those sorts of temperature swings.

⁴ Playing the open source Windows version of Duke Nukem (EDuke32). Not sure what the hell it is doing, but having that running for barely a minute and my P4’s processor fan cranks itself up to vacuum cleaner mode. I hope like hell it isn’t stuffed full of crappy busy-wait loops, but certainly it clobbers the processor like nothing else including Windows and Firefox have ever managed to…

My RPi 4 is in one of those heatsink cases with twin fans. I assumed the fans weren’t going to do anything but I don’t seem to be able to get the temp over 37°C. Idles at 33-35.

The BB -xM runs much hotter, being throttled at 65°.

My RPi 4 is in one of those heatsink cases with twin fans. I assumed the fans weren’t going to do anything but I don’t seem to be able to get the temp over 37°C. Idles at 33-35.

Fan cooling on the Raspberry Pi really does work. I am currently using a Pi 3B+ which now has the same fan as my Pi 4s. It is locked at low CPU speed of 1400 MHz and the temperature is stuck at 34’C. This Pi 3 B+ has never been so cool.

The bit I forgot to mention is that on the same RPi Raspbian idles at a similar temperature but pushes it to the mid 40s.

The 3B+ seems to run the coolest due to the metal packaging, the plastic 3B runs hotter.

I have updated the benchmarks on http://www.svrsig.org/HowFast.htm to include the Raspberry Pi compute module 4 which runs at 2000MHz.

I have tested it on the waveshare IO board but not yet added an m.2 drive (so no HDD speed test, but the SCSI pen drive speed is quite OK) and the eMMc (which contains a two partition FAT & filecore image) shows a HDD icon but RISC OS sees it as an empty drive.

Some slight bugs (about 30% of the start ups are OK, 70% mouse invisible; error on entering Supervisor mode but then works with no further errors).

I have updated the benchmarks on http://www.svrsig.org/HowFast.htm to include the Raspberry Pi compute module 4 Lite at 1500 MHz as well as at 2000MHz. Also updated to show the Pinebook Pro at 1800MHz which is an excellent machine.

The CM4 works well now that I have populated the PCIX with a m.2 NVMe drive (which works under Linux but not RISC OS).

The Pinebook Pro is most impressive, starting up in a RISC OS desktop after only 14s from power on. Hot plugging an Ethernet/USB dongle with wired Internet just works. Very impressed.

Sound not yet working and there are some slight bugs but nothing serious and to be expected on a ‘pre-release’ machine.

I have updated the benchmarks on http://www.svrsig.org/HowFast.htm to include the timings for the Raspberry Pi compute module 4 with eMMc which now works under RISC OS (since 21 Jan 2023 rom changes).

The CM4 works well now that I have populated the PCIX with an m.2 NVMe drive (which works under Linux but not RISC OS).

The PineBook Pro now supports external HDMI connection at 1920×1080 via a USB socket. specific application and dongle (available from R-Comp). Sound output is still being worked on. RISC OS now runs rock solid on the PBP (no pun intended).