From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <7aa1f8ae5b628668@orthanc.ca> In-Reply-To: From: "Digby R.S. Tarvin" Date: Wed, 10 Oct 2018 19:13:16 +1100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000003fd01a0577db6c53" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: eafd04fe-ead9-11e9-9d60-3106f5b1d025 --0000000000003fd01a0577db6c53 Content-Type: text/plain; charset="UTF-8" I don't know which other ARM board you tried, but I have always found terrible I/O performance of the Pi to be a bigger problem that the ARM speed. The USB2 interface is really slow, and there arn't really many other (documented) alternative options. The Ethernet goes through the same slow USB interface, and there is only so much that you can do bit bashing data with GPIO's. The sdCard interface seems to be the only non-usb filesystem I/O available. And that in turn limits the viability of relieving the RAM contraints with virtual memory. So the ARM processor itself is not usually the problem for me. In general I find the pi a nice little device for quite a few things - like low power, low bandwidth, low cost servers or displays with plenty of open source compatability.. Or hacking/prototyping where I don't want to have to worry too much about blowing things up. But it not good for high throughput I/O, memory intensive applications, or anything requiring a lot of processing power. The validity of your conclusion regarding low power ARM in general probably depends on what the other board you tried was.. DigbyT On Wed, 10 Oct 2018 at 17:51, hiro <23hiro@gmail.com> wrote: > > Eliminating as much of the copy in/out WRT the kernel cannot but > > help, especially when you're doing SDR decoding near the radios > > using low-powered compute hardware (think Pies and the like). > > Does this include demodulation on the pi? cause even when i dumped the > pi i was given for that purpose (with a <2Mbit I/Q stream) and > replaced it with some similar ARM platform that at least had neon cpu > instruction extensions for faster floating point operations, I was > barely able to run a small FFT. > > My conclusion was that these low-powered ARM systems are just good > enough for gathering low-bandwidth, non-critical USB traffic, like > those raw I/Q samples from a dongle, but unfit for anything else. > > --0000000000003fd01a0577db6c53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know which other ARM board you tried, but= I have always found terrible I/O performance of the Pi to be a bigger prob= lem that the ARM speed.=C2=A0 The USB2 interface is really slow, and there = arn't really many other (documented) alternative options. The Ethernet = goes through the same slow USB interface, and there is only so much that yo= u can do bit bashing data with GPIO's.=C2=A0=C2=A0The sdCard interface = seems to be the only non-usb filesystem I/O available. And that in turn lim= its the viability of relieving the RAM contraints with virtual memory. So t= he ARM processor itself is not usually the problem for me.

In general I find the pi a nice little device for quite a few thin= gs - like low power, low bandwidth, low cost servers or displays with plent= y of open source compatability.. Or hacking/prototyping where I don't w= ant to have to worry too much about blowing things up. But it not good for = high throughput I/O,=C2=A0 memory intensive applications, or anything requi= ring a lot of processing power.

The validity of yo= ur conclusion regarding low power ARM in general probably depends on what t= he other board you tried was..

DigbyT
<= br>
On Wed, 10 Oct 2018 at 17:51= , hiro <23hiro@gmail.com> wro= te:
> Eliminating as much of the= copy in/out WRT the kernel cannot but
> help, especially when you're doing SDR decoding near the radios > using low-powered compute hardware (think Pies and the like).

Does this include demodulation on the pi? cause even when i dumped the
pi i was given for that purpose (with a <2Mbit I/Q stream) and
replaced it with some similar ARM platform that at least had neon cpu
instruction extensions for faster floating point operations, I was
barely able to run a small FFT.

My conclusion was that these low-powered ARM systems are just good
enough for gathering low-bandwidth, non-critical USB traffic, like
those raw I/Q samples from a dongle, but unfit for anything else.

--0000000000003fd01a0577db6c53--