Raspberry Pi 3 heat issues


Nick
 Share

1 1

Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

Not sure how much truth there is in this as I haven't had time to follow up on the sources, but interesting if true!

 

http://www.open-electronics.org/the-raspberry-pi-3-gets-seriously-hot-clocking-up-to-100-c/

 

People love bullshit and numbers. 97.3°C seriously? Showing decimal places where the tool in question might be 15°C off? Instead of showing numbers they should use a scale ranging from "pretty cold" to "freaking hot" since these measurements are all too vague.

 

Same applies to the thermal sensors that are part of every modern SoC or CPU. Their purpose is to prevent damage/overheating but I wouldn't expect that they're are very precise. It's ok if the board does an emergency shutdown when it exceeds 110°C. Or 95°C. Or 120°C.

 

Have a look into datasheets, be prepared that sensors produce values that are processed by drivers that depend on clocks (we currently have the situation that on H3 boards running Armbian/OpenELEC the reported temperatures are lower compared to other OS images -- loboris or Xunlong -- that rely on Allwinner's outdated u-boot) and show wrong readouts.

 

All modern SoCs/CPUs might easily exceed 100°C under full load (CPU + GPU + special hardware engines!) and therefore implement throttling strategies. In case you're really interested read through this whole 'thread' (a pretty misused Github pull request): https://github.com/longsleep/build-pine64-image/pull/3

Link to post
Share on other sites

I did a little more reading around some of the sources and you are right in that no one seems to have hit 97 / 100, they do also mention that internal sensors weren't used for exactly the reasons you have mentioned.

 

To be fair, while I agree with your comment that trying to measure to 0.1°C in that type of situation is questionable at least, if that is just a screen shot from the camera then surely it is more dubious to go editing out the .3?? They did at least round it up for the headline, though I imagine that was more for creating hysteria than scientific interpretation  ;) 

 

This article https://www.reddit.com/r/raspberry_pi/comments/48i47b/planning_to_put_your_pi_3_in_a_case_make_sure/ mentions potential throttling code issues, which reminded me of the early H3 troubles but again I don't know enough to comment with any authority and I think the author may also be the same person responsible for the other article as well. Which may or may not be suspicious.

Link to post
Share on other sites

potential throttling code issues

 

That's what it's basically all about. Nearly all modern SoCs heat up way too much under heavy load so you have to implement throttling (Allwinner chose in its BSP kernels for H3, A64 and A83T rather strange strategies to kill CPU cores early and not throttle earlier -- which results in strange benchmark results that are still used by some, Phoronix for example).

 

What you've seen with the H3 in the beginning was a related phenomena called 'dynamic voltage frequency scaling' where you normally try to reduce all the voltages to a reasonable minimum and increase them only if clockspeeds increase (since the higher voltages at higher clockspeeds are mostly responsible for higher temperatures). Unfortunately all OS images for Orange Pis used just 2 dvfs operating points and loboris increased them on his OS images by 200mV which then lead to all the thermal/stability issues the H3 was blamed for.

 

We made just a few tests with 'not so braindead' benchmarks as normally used. And this not to benchmark anything but just to get an idea which tool we could use to push the envelope and to be able to use for reliability testings (this is the first thing you do, ensure reliability and then start thinking about increasing performance).

 

The sysbench tool the RPi people use is rather useless, if they would try it with Linpack then things get interesting (since Linpack is able to detect data corruption! in my tests I had the same problem when running Pine64 at 1344 MHz without adjusting the dvfs max voltage of 1.3V, after increasing the voltage up to 1.4V maybe no data corruption would occur but I'm not able to reach 1344 MHz any more due to throttling preventing this before) and then cpuminer and cpuburn-a53 are way more heavy and might be able to damage a SoC with wrong throttling strategies and missing emergency shutdown mechanisms.

 

The Github issue linked to above is worth a read.

 

BTW: In the 'free' forum there's a lenghty thread about LeMaker's Guitar (not worth a look) where also some thermal stuff is mentioned. When I did some comparisons with other boards I also monitored internal temperatures. It seems it's really a problem with most recent SoCs that all overheat way too much (the S500 used on the Guitar as another example, even with light workloads able to reach 125°C)

Link to post
Share on other sites

Hi tkaiser,

I did read the GitHub link last night, it was very interesting. 

I think one of the advantages that the Raspberry Pi brand has is that not only are the foundation pushing the hardware forward but that they also have a fairly decent grasp (at least when compared to the hundreds of piClone manufacturers) of the software and inner workings of the SoC. 

 

That last point is one of the things that I love about the Armbian project / community, you guys really do know your stuff and push everything to be the best / highest quality that it can be. It's just a shame that Allwinner and often the board mfrs let you down repeatedly. 

 

I've learnt so much in a very short space of time about boot processes, dtb files and alot more from just reading this forum and asking a few questions, that's before I even consider how helpful it is to have a stable OS to work with.

 

I'm looking forward to learning even more and having alot of fun working with these boards which I don't think I would be having if I were trying to work with the stock images from the Mfrs!

Link to post
Share on other sites

Guest Guest

Off topic a little but if these boards are over heating at 1.2GHZ

 

How are the Android TV boxes using S802, S812 and S905 Socs managing 2GHZ ? Have they serious big heat sinks and fans inside, how do they pull it off or are they lying about the true speed of the Socs.

Link to post
Share on other sites

Well I am having a good laugh at the RPI heat problems, there is a large growing thread of people mentioning heat, data loss, sdcard corruption and USB corruption, the RPI 3 reporting 17 - 20c below true CPU heat.

Of course the fan boys are defending it, claim running CPU at 100c is fine but might need a heat sink!

 

Users reporting heat hot enough to burn skin!

Over heat and core shut downs when trying to watch youtube video in Firefox (thought it was Iceweasel by name in Linux )

 

 

Since RPI forum is known for bullying mods, flooding threads with biscuit repecies if they don't like the poster and law to them self. I think it karma come home. :-)

 

P.s One users reported his Pi 3

 

by laksh » Mon Apr 11, 2016 1:10 am

MPU6050 dmp program only loops 1196 times in a minute just equal to rpi1 b+.i though it would be way greater around 5x than b+.where i may be wrong.code is at github-Pibits/MPU-Pi-Demo or i2c is slower.even arduino loops around 4000 times @16mhz

 

Yes you read that loops slower than a Arduino as 16mhz. ( evil of me but I do hope it is true ).

Link to post
Share on other sites

How are the Android TV boxes using S802, S812 and S905 Socs managing 2GHZ ? Have they serious big heat sinks and fans inside, how do they pull it off or are they lying about the true speed of the Socs.

 

They start to throttle pretty early when all CPU cores are busy. But achieve high single-threaded clockspeeds. And most if not all demanding stuff runs HW accelerated in Android so it's not that much of an issue.

 

Well I am having a good laugh at the RPI heat problems, there is a large growing thread of people mentioning heat, data loss, sdcard corruption and USB corruption, the RPI 3 reporting 17 - 20c below true CPU heat.

 

The person behind LoveRPi told me in IRC chat that he suspects the thermal sensor is located far away from the CPU cores and that's partially responsible for the throttling problems. He then compared with Armbian throttling settings on Orange Pis and said they are nearly perfect, especially when comparing with the RPi settings (in the meantime it seems they reduced minimum clockspeed to 300 MHz to prevent overheating).

 

And the SD card and USB issues might be related to insufficient power (rule of thumb: never ever buy any board that wants to be powered through the crappy Micro USB connector!). But thermal stuff and insufficient power go hand in hand. If you improve heat dissipation with a heatsink and/or fan you allow the board to consume more energy since throttling starts later which in turn might lead to undervoltage/undercurrent situations earlier.

 

This is all well known for boards that use the shitty Micro USB connector for DC-IN. When I tested with Banana Pi M3 or Pine64, using a heatsink + fan always led to sudden power-offs and SD card corruption when running demanding stuff (cpuburn or cpuminer for example) and trying to rely on Micro-USB. Only by soldering a sane DC-IN solution to Banana Pi M3 and powering the Pine64 through GPIO pins (Euler connector) it was possible to run heavy benchmarks with highest clockspeeds.

Link to post
Share on other sites

Now I am going off my memory but if I recall right someone on a thread on RPI forum said the over heating sensor is in the GPU on a RPI 3.

 

Hope it helps.

 

There is some talk of will fitting a expansion board or a hat foul a heatsink or fan, 20 mm was mentioned. Is their sufficient airflow in a RPI 3 case needs considering too. Still don't think boiling to a 100 + on and off repeatedly is good for electronics. Remove the fan or heat sink on products designed to have then and failure starts to creep in.

 

Passive heatsink cooling on a graphics card springs to mind. Remove that and over time the card dies.

 

The Orange Pi as I understand ( not sure if true ) H3 soc was designed for 1.2GHZ not the over clocked 1.6 quoted, at 1.6GHZ best fit cooling. (As I say I might be wrong on this).

 

What shocks me most is RPI always claim the high ground and being professionals who test products, but yet again we see customers being used as unpaid testers debuggers of hardware, software settings. Still say Karma come home on RPI 3.

 

Thank you for your informative insight as usual tkaiser.

Link to post
Share on other sites

Now I am going off my memory but if I recall right someone on a thread on RPI forum said the over heating sensor is in the GPU on a RPI 3.

 

That would explain the problem :)

 

Basically the RPi's SoC is still the same as 4 years ago. It's a VideoCore IV VPU/GPU combined with one ARMv6 core, later 4 ARMv7 cores and now with 4 ARMv8 cores. All the RPi's many limitations (one single USB2.0 connection to the outside, VideoCore boots first, needs a FAT partition and can not address more than 1 GB DRAM) originate there.

 

AFAIK it's still not clear whether the RPi 3 can be brought up in aarch64 state but since DRAM is limited to 1 GB DRAM anyway it's not that important unless you want to benefit from the huge virtual address space you get with 64 bit. And fortunately you can benefit from ARMv8 even in 32 bit mode (multiple times faster code execution in some areas and an overall performance gain of ~20%) so people who know what they do might benefit from the Cortex-A53 cores present in the new SoC variant. But most people who know what they do will stay away from RPi 3 anyway.

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

1 1