Adventures in overclocking Organelle M

NOTE: Do not try this at home. It voids your warranty.

I had good success using pd~ to utilize the four cores of the Organelle M in my patches. At some point though the main core that gathers the voices starts being the bottleneck. Especially when using ORAC 2 which needs one of the cores much more than the rest.

So I thought: what else can we do?

Well, we can overclock the CPU of the Organelle M by editing /boot/config.txt. Note that doing this already voids warranty as the CPU will set a bit to indicate it was overclocked.

The Organelle M comes with a Raspberry Pi CM3+ Lite module that runs at 1.2GHz from the factory:

Its desktop equivalent, the Pi 3B+, runs at 1.4GHz. However, simply bumping the frequency won’t be enough as the module will likely overheat, and then start throttling performance to cool down, or worse yet: burn out.

So I thought: let’s add a heatsink from Balena.io to the compute module! I ordered one and installed it as described, looks pretty slick:

The kit comes with a set of spacers (washers) and screws. You need to buy your own thermal compound though:

I used two washers per screw as the CM3+ is already pretty high. The holes in the module allow the screw to be screwed in directly, making the nuts redundant. I didn’t use those then.

However, there’s a problem. Turns out the battery compartment is spaced really tightly with the rest of the chassis. There is already a bit of it shaved by C&G to fit the large 100uF capacitor on the left. So I had to shave off some too which ended up being cleaner as a full on hole in the battery compartment:

With this the chassis closes fine with no surface tension. But it’s obviously very much out of warranty now.

Does it work though?

It does! After 30 minutes of uptime with ORAC 2 fully filled with Plaits and FX:

$ /usr/bin/vcgencmd measure_temp && vcgencmd measure_clock arm
temp=48.3'C
frequency(45)=1500002000

Overclocking to 1.5GHz (like Raspberry Pi 4) gives enough headroom for three Plaits not to cause buffer underruns.

Update 1: 12 hours later

This ran successfully now for a consecutive 12 hours without any issues. The temperature rose to 51.5℃ which means it’s stable enough.

Update 2: Another 24 hours later

To really push it to the limit, I opened VNC and 2 SSH sessions on the Organelle, replaced one of the ORAC 2 Plaits with Koto (which uses another CPU core for computation), and sequenced the three ORAC 2 modules with pretty dense sequences. Two modules were sequenced using different MIDI IN channels, and the Koto with the built-in euclidean sequencer with clock slaved to MIDI. After adding all that the long-term load of the box was still reported at a paltry 1.09. The temperature pretty quickly rose to 61.2℃ but stayed at that level. It was stable like that for another 12 hours. No issues whatsoever.

At this point I went overboard and on top of all of the above I made lxterminal in the VNC connection stream random color text constantly. This turned out to be just the thing to push the compute module to its limits. After 15 minutes of this, the temperature was at 80.1℃, the reported box load at around 3.75. The screw in the battery compartment was too hot to touch.

ONLY THEN the compute module started throttling performance to keep the temperature down. I started seeing clock speeds reported at 1195000000 compared to the previous 1500002000. Amazingly, this was enough to keep the machine in check at a stable 80.6℃ with full-blown load over the four cores.

What’s funny is that Raspberry Pi slowed down to what was its original clock speed before the overclocking. And that was enough to keep the temperature at bay. There are no audio hiccups, MIDI is processed normally the entire time. Note that this stress test scenario isn’t representative of typical Organelle usage. Under normal circumstances you will never see this kind of sustained load over all four cores.

All this is measured in a room with ambient temperature at around 26℃ (Summer’s coming here!) and humidity at 45%.

This stress test has been running for 24 hours straight at this point. I think this hack is a keeper. But again, it’s very hard to get replacement compute modules these days so unless you have a backup one, and are comfortable voiding your warranty, don’t do it. And whatever you do, don’t put batteries into an overclocked 'nelle! The heatsink is a large source of heat too close to the battery compartment.

8 Likes

Cool that you are sharing this project with us! I am not planning to overclock my Organelle, but I love reading about stuff like this.

Also it reminded me of Pd~! Ready to make some quad core patches asap! Anything I should know of Organelle-vice? Did you have any heat problems before overclocking? Is it also an easy way to check CPU% on all cores? And does the one in the Organelle menu messure the core that will be used for communicating? Aka the most stressed core in a 4x pd~ based patch?

I guess it could also be nice to keep one core free for VNC maybe. Anyways even just using 2x pd~ will of course double the cpu of the Organelle-M, so that is pretty epic!

1 Like

I edited the original post with more information on heat.

You can check what the Organelle is doing by SSH’ing to it and running htop. You can also run htop from a terminal via VNC. That will show you all core usage.

You can’t “leave one core free” for anything. Linux does the scheduling. It’s better to split your computation with pd~ as this gives Linux more granularity to round-robin it across the four available cores. Of course, there is some overhead from splitting work across pd~ and developing patches that way is a bit harder. But I wouldn’t worry about it too much.

I think of pd~ mostly in the context of ORAC which is modular and combines multiple pieces of audio processing. I would love it if parallel3 automatically put each chain in a separate pd~. That would be enough to make Organelle awesome for most users without requiring any work from the module developers.

But, of course, with pd~ we can also have serious pro-sounding polyphonic realtime synthesizers as Organelle patches. There is much untapped potential for the Organelle here. Especially with the 25% additional CPU power that I just unlocked with overclocking.

1 Like

Thanks for your answer! Especially the thought on splitting the different processes into their own Pd~ objects sounds like a better approach than just splitting the patch in four. I will start programming :slightly_smiling_face:

Another update: After leaving the Organelle running overnight on the hardest stress test and discovering that the Eastern windows rose temperature of the studio to 29℃ ambient (over 84°F), the instrument managed to still play without hiccups and keep its temperature at around 80℃. After turning off the VNC text spam, CPU temperature fell down to under 70℃ in two minutes. At this point I turned the test off.

I think I can call this experiment a full success.

1 Like

BTW @RPLKTR if i take the audio of one Pd~ and feed it into the input of another pd~ are they still able to be on separate cpu cores? Or will they then be forced to be on the same core? I think I read something about this in some other software once. Do you know?

They are still separate processes and as such can utilize separate cores. However, chains of pd ˜ increase latency so avoid more than 3.

1 Like

This is awesome, I’ll be doing it on my S but first I’m going to make a custom heatsink block since the Balena’s one is to expensive to ship in my country!

Do you mind sharing what OC settings have you ended up with?

I know it’s subjective for each processor and ideally I’d have to do my tests while overclocking, but I’m curious to know if you’ve tried lower over_voltage settings or did you go straight to over_voltage=8 (1.4V)?

Thanks!

I wasn’t interested in using the 'nelle with AA batteries since the screw touching one of the batteries would be too hot. So I went for overvoltage 8 since it would not risk underpowering the overclocked CPU. That being said, with higher voltage there’s higher chance of frying the unit.

Shipping from Balena is via DHL so it’s indeed a big chunk of the price. It was $20 for me so I bought three heatsinks in one go, one to use in my Norns as well, and one to have as a spare.

However, to make it clear, this exercise voids warranty and risks frying your compute module which at the current time is not replaceable (due to chip shortages the modules are unavailable everywhere). I’m not judging but think about it: if spending $20 on shipping is a big deal to you, I’d advice against doing this as you might lose a $500 device. Moreover, overclocking makes most sense if you make your own ORAC modules that use pd~ (there are almost none online). Otherwise, I’d say the risk is not worth the gain.

Obviously, in the end it’s up to you. Share how your custom heatsink looks like. Maybe you’ll be able to make it fit more snuggly, which would remove the need to drill the plastic. Although when you open the case, you’ll see that C&G themselves drill a bit of plastic in the battery compartment as well to fit one of the tall components on the PCB.

In any case, good luck!

Thanks, yes I understand however the Balena shipping cost was not a big deal to me per se, but since I’ve figured I can adapt a copper block by cutting it to measure and find the correct height for the washers, it made more sense to me and it’s more fun!

Also since I own an Organelle S I don’t have to worry about the battery compartment as there is enough room under the module!

Here is the block I’m gonna use for the mod:

Also I’m working on a multicore ORAC chain but as of right now I’m failing miserably… XD

1 Like

Sweet piece of copper! If you already have that then of course it makes sense to use it.

I missed you’re doing it on the S. In this case definitely take pictures, I’m pretty interested in how it differs internally.

1 Like

I’m posting a few pictures showing the guts of the Organelle S

Here it is with the chocolate bar installed…

For the OC I’ve taken a more conservative approach:
arm_freq=1500
gpu_freq=450
sdram_freq=500
over_voltage=6

I did not engage force_turbo.
So far looks promising, no more dropouts on my presets, the cpu load dropped a good 23%, so far temperature is stable in the mid 50°c range, but I need to do more testing…

1 Like

I’ve highlighted with red boxes the areas where differs from the M, obviously it’s missing the speaker amp and the battery connector board.

1 Like

Done with testing stability, and indeed it’s pretty stable with those settings.

The test consisted of 5 koto instances running for several hours, all cores where almost maxed out and temp was stable at around 75°c to 80°c.

Also to stay on the safe side I’ve replaced the original 9V power supply with a 3A supply (9V), as the 1A on the original supply became probably not sufficient with the OC especially when adding bus powered devices to the USB ports.

I’m really happy now, being able to load almost any module combo I wish without dropouts it’s fantastic, I didn’t expect such performance boost especially since I’m not even using pd~ at the moment!

Thanks a lot @RPLKTR for posting this and inspiring me for this mod! :smiley:

2 Likes