[PD] new raspberries

[Chris Clepper]

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 at 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 at 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 at gmail.com> wrote:
> > > > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <msp at 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 at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150209/d3f751cf/attachment.html>