In general, the ARM will do all sorts of things to keep energy usage to the bare minimum: Video decoding runs on dedicated DSP/GPU rather than the main cores, parts of the cores are shutdown, RAM is put to sleep and so on.
Using -nosleep on a root process at elevated could defeat enough of the low power safeguards as that is something an Android phone/tablet would never do. All of those devices have heatsinks just due to space constraints, and Apple ran afoul of customers due to excessive heat on a dual A8 based iPad.
Without any heat treatment on top of the CPU most of the heat flows through the PCB. So in some cases the issue wouldn't be with the ARM but some other part reaching its thermal limit (like a power regulator or RAM that have to be physically close to the CPU). The UDOO board's WiFi chip gets hotter than the ARM heatsink for example. Freescale recommend heat spreaders and sinks for all of their iMX.6 parts although not all of the low eval boards have them.
The Pi 2 doesn't have much thermal cooling on the chip and the RAM is directly UNDER the CPU so the heat from both will largely go into the same place PCB. Maybe there is enough copper in the PCB to dissipate the heat, but the thermal docs I have from Freescale say it's not possible to do for a 5W+ quad A9.
On Mon, Feb 9, 2015 at 1:53 PM, Miller Puckette msp@ucsd.edu wrote:
Interesting. Of course, it _should_ be thermally permitted to run all cores at speed - and the Pi folk are taking heat dissipation very seriously in their thinking. So my leaning would be to risk $35 on a week-long stress test using -nosleep. Hmm, time to order a machine...
cheers Miller
On Mon, Feb 09, 2015 at 01:13:40PM -0500, Chris Clepper wrote:
The ARM multicore CPUs tend to bounce processes between cores to avoid thermal issues (an idle core is a cool core). If you really want to do -nosleep for a long period, think about adding a heatsink to the chip. I have had A9s lock up or shutdown pretty quickly from heat. On the plus side, I have lower latency on ARM than my new Macbook Air or any other desktop I run Pd on...
On Sat, Feb 7, 2015 at 10:52 AM, katja katjavetter@gmail.com wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu
wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA
with
only the desktop running, and ~450 mA with pd -nosleep running idle
or
with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list