Heat Spreader Performance and Overclocking

[Legodude522]

I know it's hard to know until we get it in our dirty hands but I have been curious how well the heat spreader performs and if there is any potential for improvements/modifications to get more performance out of it. Secondly, can the CPU be overclocked and what to expect if so. Can the CPU temperature be monitored on the Pyra?

I'm sure most of this has been talked about in random places in the forums but not in a single discussion. The heat spreader design is a fairly recent development if I'm correct.

 

[levi]

Since the OMAP3 could be overclocked freely, I'd expect the same of the OMAP5, but I don't know to be fair.

 

[Linux-SWAT]

My dev boards (evm and igep) were able to hold 1.7 GHz with new glued heatsinks. Now they are holding dust.
You should find some infos here:

OMAP5432 at home !

root@slackware:~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 2 (v7l) BogoMIPS : 12.30 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc0f CPU revision : 2...

pyra-handheld.com

 

[TrashyMG]

Functionally yeah it's possible, I actually had to hack back in a 500Mhz mode that was disabled in mainline for some reason. The allowed clock speeds are defined in the Pyra's Device Tree Source, you would need to modify it and then compile a .dtb to boot with. It's not elegant like the Pandora where you can set any frequency and it would clock to that speed. Although a bit of that likely could be implemented if someone implements some kind of Frequency/voltage lookup... I think it was just some case statement in a script on the Pandora... this needs to be all done in the device tree source.

Overclocking is another story, while I remember trying 1.7GHz, the Devboard was easy to cool as it's not enclosed. I'm not sure of the overclocking potential in an enclosed environment.

 

[Letalis Sonus]

the Devboard was easy to cool as it's not enclosed.

Luckily science is able to passively cool down surfaces to ~10°C below their ambient surroundings nowadays. Perfect in combination with Vantablack!

 

[spud42]

pity the white paint is to stop absorbing heat by refelection. wont do a whole lot for internally generated heat from a cpu.

 

[Letalis Sonus]

pity the white paint is to stop absorbing heat by refelection.

Not quite, you won't go below ambient temperature by just stopping the absorption. This is more comparable to the special white paint used on heating radiators, which increases the amount of heat spreading into its surroundings by emitting infrared radiation - but on steroids.

 

[levi]

And anyway, if we're still talking about the Pyra here, the only white paint that I know of is on the opposite side of the main PCB to the CPU board.

 

[EvilDragon]

While the heatpipe works okay and moves the heat to the heatsink this only works properly for a short amount of time.
Using Chromium to watch Youtube videos made the unit a bit warmer, but not that much.

However, I left it charging for a couple of hours (idling at the desktop), and the unit became pretty warm.
CPU was 70C, battery almost 60C (the battery shut itself off due to overheating).
I need to check why that happened (maybe some interrupts going crazy raised the cpu to max), but that also means overclocking, etc. will not make much sense, as it will get way too hot.

On the contrary: We need to implement a daemon for proper throttling based on the temperatures to make sure nothing bad happens.

The OMAP5 is extremely unefficient with a CPU speed of more than 1GHz. Up to 1GHz, heat and battery consumption are fine. Anything above 1GHz will raise the heat and battery consumption exponentially.

Don't forget that the mobile version of the OMAP5 (the 5430) which we originally wanted to use never went into production (which was decided after we were already halfway through with the PCB design)

The one we are using is an industrial one. It is meant to run with a huge heatsink, a wired power supply and fresh air surrounding it.

So I don't think overclocking is a good idea - in my opinion, we should rather underclock it.

 

[matzesu]

Ok, this makes sense, also as i want this thing mostly for Pandora Tasks, i think Underclocking is the way to go..
But i also want the Device to be in Low Power Mode in my Pocket, so i have just to traw it and push a button so its ready to go..
The Problem is, in my Pocket there is not that much Air Around, as its a Jeans Workpants Pocket, and somethimes, mostly in Winter i ley under the warm bett tishue (Bettdecke),
This wasnt an issue whit the Pandora, but what happens whit the Pyra?

 

[Linux-SWAT]

i think Underclocking is the way to go..

LMAO

 

[docbroke]

The Problem is, in my Pocket there is not that much Air Around

Try airpods

 

[matzesu]

My Airpods are on the oposide in a diverent Pockets, i dont want they to be in the "Pandora/Pyra/Ebook/Notebook" Pocket ..

But maybe a future CPU Update whit a real Mobile CPU would make sense, but first whe try the Omap 5, i think whit a bit Optimimicion should they work good enough..

 

[vampire8bit]

The OMAP5 is extremely unefficient with a CPU speed of more than 1GHz. Up to 1GHz, heat and battery consumption are fine. Anything above 1GHz will raise the heat and battery consumption exponentially.

So I don't think overclocking is a good idea - in my opinion, we should rather underclock it.

The processor spec is 1.5GHz, so we are advised to use it at only 1GHz? thats disappointing. I thought it would be fine out of the box up to 1.5GHz, and only overclocking it higher than that would be detrimental to the pyra.

 

[TrashyMG]

1.5GHz is likely fine, just need to understand that you may not want to use it for prolong periods. 1Ghz is the typical operating frequency it will go to 1.5GHz on load demand. The Pyra is considerable more powerful than the Pandora, The OMAP5 underclocked at 500Mhz will beat the snot out of a 1GHz Pandora overclocked at 1.2Ghz. So it's not like we're dealing with Pandora speeds here.

Last I knew the setup only had a 1Ghz and 1.5Ghz speed modes, for reasons I don't know the 500MHz speed was disabled out of the the Device Tree source. I feel we could potentially implement a Pandora style clocking method where we could set any range of frequencies between the minimum stable and the Maximum stable, It's just a matter of figuring out what voltage needs to be set at certain frequencies and implementing some kind of method of having that setup up in the Device Tree.

 

[EvilDragon]

The processor spec is 1.5GHz, so we are advised to use it at only 1GHz? thats disappointing. I thought it would be fine out of the box up to 1.5GHz, and only overclocking it higher than that would be detrimental to the pyra.

I also advise to not charge the GPD Win at the same time while running with a high CPU-Power, as that heats the battery up so that most batteries die after 1 year.
I also advise to not drive a car at full speed, as the fuel it uses increases immensively compared to driving only a few km/h less.
It's up to you to follow that advise, no one forces you.

The OMAP5 uses exponentially more power and produces more heat when going over the speed of 1GHz.
Up until then, power consumption / speed is pretty linear.
That's simply a technical fact for the CPU, not anything we can change.

It can run up to 1.5GHz. What you seem to be forgetting is that all modern ARM CPUs are not meant to run at full power for an extended period of time.
They can handle it for a few minutes but start to throttle then.

If you make sure the device you're using stays cool, you can use the 1.5GHz with full maxed CPU as long as you like.
So for playing games, browsing the web, etc., it shouldn't be a problem, as they rarely max out the CPU all the time, they usually only have some CPU peaks, and they won't heat up the system a lot.

There's one major issue though:
In case a heated up system causes the battery to malfunction and get on fire, I am personally responsible for that.
If a house burns down, I have to pay for it. If a person dies, I will be held responsible.

So of COURSE I need to make sure that doesn't happen. There needs to be a proper throttle mechanism in there that throttles the system in order to prevent overheating.

That doesn't mean you can't use the 1.5GHz. But I need to make sure the temperature stays low enough to not cause any damage.
It's the same for almost any modern device out there, it's just that no one tells you that

Every single smartphone I ever had started to throttle if I ran games that maxed out the CPU and heated up the system. That's normal. The CPUs still have such high rating.
That is a normal fact these days, and of course, we are no exception.

It's OpenSource, you can disable the temperature throttling. But if it burns down your house, that will be your own responsibility then, as you disabled the safety measure.

 

[elvissteinjr]

It's OpenSource, you can disable the temperature throttling. But if it burns down your house, that will be your own responsibility then, as you disabled the safety measure.

At least for x86 CPUs I was under the impression there was a factory-defined maximum temperature check implemented in the hardware itself that would trigger an emergency shutdown of the system when needed. Is this really not the case on the OMAP?
Throttling should happen before that, sure, but seems weird to not have that kind of safety mechanism embedded at all.

 

[TrashyMG]

At least for x86 CPUs I was under the impression there was a factory-defined maximum temperature check implemented in the hardware itself that would trigger an emergency shutdown of the system when needed. Is this really not the case on the OMAP?
Throttling should happen before that, sure, but seems weird to not have that kind of safety mechanism embedded at all.

Concern isn't the CPU, it's the how much heat is going into the battery.

 

[RZR]

The processor spec is 1.5GHz, so we are advised to use it at only 1GHz? thats disappointing. I thought it would be fine out of the box up to 1.5GHz, and only overclocking it higher than that would be detrimental to the pyra.

Every single smartphone I ever had started to throttle if I ran games that maxed out the CPU and heated up the system. That's normal. The CPUs still have such high rating.
That is a normal fact these days, and of course, we are no exception.

And not only smartphones throttle. Has anyone played a bit with one of the latest (2016 on, for example...) 'gaming' notebooks? Let me give you an example:

P670RSG (unlocked 6820HK, GTX 1070 notebook):

->Power management for these GPU is quite complex, base core clock is rated at 1442MHz and boost at 1645MHz but are unlocked and by default overclock and underclock based on load, thermal margin, available power and other parameters, this one overclocks by default over 1800MHz and stays consistently at around 1600MHz on load:

Not only that, but this notebook is unable to maintain both CPU and GPU at 100% performance for prolonged periods (throttles either GPU or CPU), and uses a fairly complex cooling solution:

And this when powered by the PSU, when running on the battery it throttles to about 60-75% of GPU performance always, in order to avoid destroying the LiPO battery. Also on these things the die of both CPU and GPU is in contact with those heat-spreaders (TIM in the middle of course) so heat doesn't have to waste time going through an IHS (more efficient...)

So seeing how was the cooling solution for the Pyra, I already expected it to throttle on serious load. Those who want to overclock it should begin to think about designing and fitting a custom solution with heatsink and fan...

 

[EvilDragon]

At least for x86 CPUs I was under the impression there was a factory-defined maximum temperature check implemented in the hardware itself that would trigger an emergency shutdown of the system when needed. Is this really not the case on the OMAP?
Throttling should happen before that, sure, but seems weird to not have that kind of safety mechanism embedded at all.

There is one, but it's not really useful.
As soon as the OMAP5 runs too hot, it suddenly clocks down to 200MHz, until the temperature is below a certain threshold (I think it's 5 - 10°C celsius lower).

In real life, it means that the OMAP5 runs hot, throttles immensively for 5 - 10 seconds, then clocks back, overheats again after a few seconds, throttles down again.
That's okay for compiling.

But when playing a game, it means that the game changes between being unplayable and full speed every few seconds - which makes it unplayable.

What makes the game more playable would be throttling BEFORE it reaches max temperature (in probably 100MHz steps) until you have a speed that keeps the current temperature at a certain threshold.
Then the game would run constantly with, for example, 1.3GHz instead of changing speed constantly.

And yeah, the second issue is the battery. The OMAP doesn't take care about the battery - and while the battery has an emergency temperature warning, you don't want to suddenly disconnect it (and if you're running with AC power, the battery still will be hot).

So we need a dynamic throttling system.
Basically, something similar to this script:

temp-throttle/temp_throttle.sh at stable · Sepero/temp-throttle

A shell script for throttling system CPU frequency based on a desired maximum temperature - Sepero/temp-throttle

github.com

But probably as daemon, as scripts tend to use too much CPU power (because they keep the system alive).