From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <7aa1f8ae5b628668@orthanc.ca> From: hiro <23hiro@gmail.com> Date: Wed, 10 Oct 2018 11:14:26 +0200 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000f9578b0577dc4760" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: eb0c37bc-ead9-11e9-9d60-3106f5b1d025 --000000000000f9578b0577dc4760 Content-Type: text/plain; charset="UTF-8" I agree, if you have a choice avoid rpi by all costs. Even if the software side of that other board was less pleasent at least it worked with my mouse and keyboard!! :) As I said I was looking at 2Mbit/s stuff, which is nothing, even over USB. But my point is that even though this number is low, the rpi is too limited to do any meaningful processing anyway (ignoring the usb troubles and lack of ethernet). It's a mobile phone soc after all, where the modulation is done by dedicated chips, not on cpu! :) On Wednesday, October 10, 2018, Digby R.S. Tarvin wrote: > 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. >> > --000000000000f9578b0577dc4760 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree, if you have a choice avoid rpi by all costs.
Even if the softwa= re side of that other board was less pleasent at least it worked with my mo= use and keyboard!! :)

As I said I was looking at 2Mbit/s stuff, whic= h is nothing, even over USB. But my point is that even though this number i= s low, the rpi is too limited to do any meaningful processing anyway (ignor= ing the usb troubles and lack of ethernet). It's a mobile phone soc aft= er all, where the modulation is done by dedicated chips, not on cpu! :)
=
On Wednesday, October 10, 2018, Digby R.S. Tarvin <digbyt42@gmail.com> wrote:
> 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.=C2=A0 The = USB2 interface is really slow, and there arn't really many other (docum= ented) alternative options. The Ethernet goes through the same slow USB int= erface, and there is only so much that you can do bit bashing data with GPI= O's.=C2=A0=C2=A0The sdCard interface seems to be the only non-usb files= ystem 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 usu= ally the problem for me.
> In general I find the pi a nice little dev= ice for quite a few things - like low power, low bandwidth, low cost server= s or displays with plenty of open source compatability.. Or hacking/prototy= ping where I don't want to have to worry too much about blowing things = up. But it not good for high throughput I/O,=C2=A0 memory intensive applica= tions, or anything requiring a lot of processing power.
> The validit= y 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.c= om> wrote:
>>
>> > Eliminating as much of the c= opy in/out WRT the kernel cannot but
>> > help, especially when= you're doing SDR decoding near the radios
>> > using low-p= owered compute hardware (think Pies and the like).
>>
>> = Does this include demodulation on the pi? cause even when i dumped the
&= gt;> 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 neo= n cpu
>> instruction extensions for faster floating point operatio= ns, I was
>> barely able to run a small FFT.
>>
>&g= t; My conclusion was that these low-powered ARM systems are just good
&g= t;> enough for gathering low-bandwidth, non-critical USB traffic, like>> those raw I/Q samples from a dongle, but unfit for anything else= .
>>
> --000000000000f9578b0577dc4760--