Overheating RP3

[bb677a]

I'm using an RP3 as a monitor/controller in real time, and am having trouble with the Pi crashing. After searching around and trying things out, I'm pretty sure that the Pi is overheating, although I have never seen the CPU temp get over 80°C. Typically the CPU temp is about 75°C.

My program uses three cores (using python multiprocessing), although only one of them should be very processor intensive. The main control process was originally in an (intentional) infinite loop and ran at ~250 Hz. The other two processes wait on data from the main process using a blocking pipe.recv() call. I throttled the main loop back to ~75Hz by putting a time.sleep() in. This didn't change my total CPU usage or decrease the temperature rise, although it did slow how often it crashed. I think I'll be looking at a heat sink to put on it.

Couple questions -
Is it normal for a process with significant times of sleeping to still be reported as 100% use?
Is it advisable (and possible) to underclock the cpu's to reduce heat output?


A copy of the 'top' readout during normal running.

top - 09:23:57 up 27 min, 2 users, load average: 3.69, 3.35, 2.25
Tasks: 155 total, 1 running, 154 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25.2 us, 54.2 sy, 0.0 ni, 20.4 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 947732 total, 429684 used, 518048 free, 24420 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 181296 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1057 pi 20 0 235660 80676 45540 S 290.0 8.5 44:42.98 python
1088 pi 20 0 204024 34572 3312 S 10.6 3.6 1:43.90 python
589 root 20 0 158564 73124 32836 S 4.6 7.7 0:53.19 Xorg
571 root 20 0 42036 31024 15508 S 2.0 3.3 0:31.35 vncserver-+
1045 pi 20 0 44588 17052 14644 S 1.7 1.8 0:13.84 x-terminal+
1034 pi 20 0 36900 21512 11244 S 1.3 2.3 0:13.79 idle-pytho+
972 pi 20 0 36284 20740 10940 S 1.0 2.2 0:16.24 idle-pytho+
986 pi 20 0 35908 20688 10992 S 1.0 2.2 0:14.62 idle-pytho+
1009 pi 20 0 36996 21576 11224 S 1.0 2.3 0:13.60 idle-pytho+
1087 pi 20 0 204024 36640 5360 S 1.0 3.9 0:09.35 python
185 root 20 0 0 0 0 S 0.7 0.0 0:06.79 spi0
599 root 20 0 16240 12464 11844 S 0.7 1.3 0:07.30 vncagent
1072 pi 20 0 44604 17204 14724 S 0.7 1.8 0:01.90 lxterminal
1159 root 20 0 0 0 0 S 0.7 0.0 0:00.03 kworker/u8+
15 root 20 0 0 0 0 S 0.3 0.0 0:00.06 ksoftirqd/2
77 root -51 0 0 0 0 S 0.3 0.0 0:02.14 irq/92-mmc1
219 root 20 0 0 0 0 S 0.3 0.0 0:00.67 brcmf_wdog+

[runboy93]

Cooling.

[PeterO]

My program uses three cores (using python multiprocessing), although only one of them should be very processor intensive.
KiB Mem: 947732 total, 429684 used, 518048 free, 24420 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 181296 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1057 pi 20 0 235660 80676 45540 S 290.0 8.5 44:42.98 python

Looks like all three processes are rrunning their cores flat out !

PeterO

[bb677a]

Followup - this problem has been solved for some time, but just getting back to updating this thread. The issue was that I thought I had created 3 processes, including 1 very intensive process. What I didn't realize was that using a animated matplotlib plot creates its own intensive process - so I really had 5 processes, 3 of which ran flat out. Took me a while to sort everything out as it appeared that all of my knowingly created processes ran flat out and I couldn't get that to change....

[OutoftheBOTS]

Yes this is what I discovered when using OpenCV and some other numpy vector libraries that require fast heavy processing. The Authors of the libraries have already utilized parallel computing to speed up the processing.

[ejolson]

Followup - this problem has been solved for some time, but just getting back to updating this thread. The issue was that I thought I had created 3 processes, including 1 very intensive process. What I didn't realize was that using a animated matplotlib plot creates its own intensive process - so I really had 5 processes, 3 of which ran flat out. Took me a while to sort everything out as it appeared that all of my knowingly created processes ran flat out and I couldn't get that to change....

Glad you got the problem sorted.

Theoretically, the Pi 3 should slow the clock down automatically when it starts to overheat. In practice, it sometimes crashes instead. In my opinion, sudden switching from idle to full load with NEON optimized code on all cores could also create voltage transients that cause a crash. This can often be fixed using an overvoltage setting or by underclocking the entire system. More information is available in this thread.