Heavy CPU load and Cooling : no issues :)

Organelle Hacking
1

note: to be clear there are no issues with Organelle regarding cooling under normal use.
this topic merely investigates what happens under more extreme usage

The organelle is configured to not scale the cpu due to load , to runs at maximum frequency at all times… this is 100% what we want for a musical device.

BUT I starting to think if you are doing heavy CPU tasks for longer periods of time (>5 mins) , this should be changed , otherwise its likely we are overheating the cpu.
(this is unlikely an issue in heavy musical patches, as you’d mostly likely get audio dropouts at this point… so would stop the patch :slight_smile: )

For me (and perhaps others) I think the danger particular comes when compiling projects, which can easily load the cpu up to 100% for long periods of time…

If your doing this, I think you should switch the scale governor to ondemand.

Is this correct? @oweno thoughts?

technical background
organelle uses the performance scaling governor to lock cpu to 1ghz. however the organelle is passively cooled, meaning the only way it can reduce its heat is to reduce the cpu frequency. but as far as I can tell , the performance governor prevents this.

1 Like
2

Ok, Ive done some more testing and research… and its all good news :slight_smile:

note: testing below was done with some pretty heavy compiling, so whilst a real life scenario, not common for many users.

on the organelle its actually quite difficult to raise the temperature to over about 70C without doing stress tests, e.g. running patches and compilations at the same time, raise the temperature pretty slowly to 70C, so the compilation will have to be for a long time.

also Ive found that the so called processor speed can be overridden even in performance mode by thermal trip points.
for the organelle, this kicks in at 83C , and will drop the processor to 3/4 speed, and another at around 90 (?) to 1/3 speed… but what I noticed was even with the cpu loaded at 85-90% the first trip point was enough to basically keep the temperature in check.

note: the max/critical temperature is 95C, at which point i believe (not willing to test ;)) the board should shutdown.

so basically, nothing to worry about … however, you still might want to switch the ondemand when doing non-audio, as it will generally allow the cpu to keep cooler as it allows cpu idling.

on the quad core, things are a bit different (bare in mind i dont have a heatsink fitted, like the single core)
for a given processing load it will run cooler, but ramp up the processing loads and the extra cores do allow for temperatures to rise much faster.
interestingly this board though is rated to 10C higher critical temps, (so max is 105) so the defaults are also proportional higher, the first one kicks in at 93… which is pretty hot.
I lowered the trip points for testing, and found that unlike the single core, going down to 3/4 speed doesn’t stabilise temperatures, they still continue to rise (albeit slower), until they hit the next trip point, at the 1/3 trip point they do stabilise.

so what does this tell us?

  • everything is ok, it should fail gracefully under load
  • if you run for prolonged periods with high cpu loads (>85%?) you will get cpu scaling
  • if your doing general tasks with high cpu loads (compilation), id recommend switching to ondemand, it might lengthen the life of the board.
  • quad core, the default temperatures seem high to me (more research needed), you can lower these by setting trip points, you’ll still get advantages of the extra cores, e.g. 4x700mhz is still more than 1x1ghx … and it’ll only scale back when it needs… no disadvantage for normal audio application. (Im thinking perhaps 83C, like the factory, rather than 93)
  • quad core, again switch to ondemand when not doing audio.
  • trip points, you can only set the first trip point, the other 2 higher ones are calculated based on that.

quad core heatsink? is one needed?
interesting question, I currently don’t think so - it would slow the heat gain (thermal mass) , and allow for a bit more dissipation (surface area), but ultimately for long periods its still passive cooling, so going to heat up… and then the only real solution is cpu scaling.
also, I think the Organelle case is great, because of its form factor, its got quite a bit of space for air to flow…
if I really wanted better cooling, probably drilling a couple of holes in the bottom would help…
(Id guess the buttons etc, would allow hot air to flow out the top)

is this an organelle issue?
No, definitely not… whilst looking into this, the same concerns have also been raised against the raspberry pi, particularly the rPI3.

anyway, hats off to C&G, the processor used means we don’t have to worry about these things, and I think the case is great for passive cooling.

1 Like
3

Thanks for all the info here.

I agree, I think the 93 for the 4 core seems a tad toasty!

I have been doing some tests with it set to 73 using a stress tool and it seems to max out around 84c with the clock scaled down to 792000.

I don’t see the values in trip_point_1_temp and trip_point_2_temp being updated when setting trip_point_0_temp, do you?

Also setting the trip_point_0_temp low, say 63 has no impact on the final clock speed (79200) or the temp (around 84c) compared to setting it at 73. So I am thinking trip point 1 and 2 are not working here.

4

Actually I was wrong, trip 1 is changing, trip 2 is always at 105.

Setting trip 1 to 40 I managed to get it to scale down again to 396000, brings the temp down to around 75.

Interestingly it won’t let you set the trip 0 back to the default 93:

[root@organelle thermal_zone0]# cat trip_point_0_temp
93000
[root@organelle thermal_zone0]# echo 93000 > trip_point_0_temp
-bash: echo: write error: Invalid argument

The max I can set is 85!

5

yeah, the main issue is because its using passive cooling, the only option is to slow the processor down… and basically this doesn’t cool very quickly, and you need to bring it down a lot to reduce the temperature quickly… but it is what it is, and in practice its not caused me any real issues.

what you need to be careful of though is the organelle default power profile, is to not use cpu scaling (until critical), this is absolute the correct operation for a musical instrument… as you really don’t want cpu scaling to happen whilst playing… it will cause audio dropouts/glitches.

but for me this is not an issue…
what i do is, when I’m doing development I put a more general profile in place, that will scale cpu much quicker… this allows me to do things like long parallel compilations without worrying about it, it gives me fast squirts of power, and slows down a bit too cool off… and the compilations are dramatically quicker :slight_smile:

for normal musical use, i leave it on max performance, because i know the patches are well within the limits of the core, so overheating doesn’t occur, and no cpu scaling happens.
(if anything the quad core runs slightly cooler than the original solo for any given load… and of course has a little more headroom on one core… as a few things OS/mother are running on other cores)