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: Thu, 11 Oct 2018 08:32:32 +1100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="0000000000009a39b50577e696f7" Subject: Re: [9fans] PDP11 (Was: Re: what heavy negativity!) Topicbox-Message-UUID: eb576b56-ead9-11e9-9d60-3106f5b1d025 --0000000000009a39b50577e696f7 Content-Type: text/plain; charset="UTF-8" Well, I think 'avoid at all costs' is a bit strong. The Raspberry Pi is a good little platform for the right applications, so long as you are aware of its limitations. I use one as my 'always on' home server to give me access files when travelling (the networking is slow by LAN standards, but ok for WAN), and another for my energy monitoring system. It is good for experimenting with OS's, especially networking OS's like Plan9 where price is important if you want to try a large number of hosts. Its good for teaching/learning. Or for running/trying different operating systems without having do spend time and resources setting up VMs (downloading and flashing an sd card image is quick and takes up no space on my main systems). Just don't plan on deploying RPi's for mission critical applications that have demanding I/O or processing requirements. It was never intended to compete in that market. On Wed, 10 Oct 2018 at 20:54, hiro <23hiro@gmail.com> wrote: > 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. > >> > > --0000000000009a39b50577e696f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I think 'avoid at all costs'=C2=A0 is a bit = strong.

The Raspberry Pi is a good little platform for t= he right applications, so long as you are aware of its limitations. I use o= ne as my 'always on' home server to give me access files when trave= lling (the networking is slow by LAN standards, but ok for WAN), and anothe= r for my energy monitoring system. It is good for experimenting with OS'= ;s, especially networking OS's like Plan9 where price is important if y= ou want to try a large number of hosts. Its good for teaching/learning. Or = for running/trying different operating systems without having do spend time= and resources setting up VMs (downloading and flashing an sd card image is= quick and takes up no space on my main systems).

Just d= on't plan on deploying RPi's for mission critical applications that= have demanding I/O or processing requirements. It was never intended to co= mpete in that market.

On Wed, 10 Oct 2018 at 20:54, hiro <23hiro@gmail.com> wrote:
I agree, if you have a choice avoid rpi by all costs.
Even if t= he software side of that other board was less pleasent at least it worked w= ith my mouse and keyboard!! :)

As I said I was looking at 2Mbit/s st= uff, 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 anyw= ay (ignoring the usb troubles and lack of ethernet). It's a mobile phon= e soc after all, where the modulation is done by dedicated chips, not on cp= u! :)

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 hav= e always found terrible I/O performance of the Pi to be a bigger problem th= at the ARM speed.=C2=A0 The USB2 interface is really slow, and there arn= 9;t really many other (documented) alternative options. The Ethernet goes t= hrough the same slow USB interface, and there is only so much that you 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 limits th= e viability of relieving the RAM contraints with virtual memory. So the ARM= processor itself is not usually the problem for me.
> In general I f= ind the pi a nice little device for quite a few things - like low power, lo= w bandwidth, low cost servers or displays with plenty of open source compat= ability.. Or hacking/prototyping where I don't want to have to worry to= o much about blowing things up. But it not good for high throughput I/O,=C2= =A0 memory intensive applications, or anything requiring a lot of processin= g power.
> The validity of your conclusion regarding low power ARM in= general probably depends on what the other board you tried was..
> D= igbyT
> On Wed, 10 Oct 2018 at 17:51, hiro <23hiro@gmail.com> wrote:
>>=
>> > Eliminating as much of the copy in/out WRT the kernel can= not but
>> > help, especially when you're doing SDR decodin= g near the radios
>> > using low-powered compute hardware (thin= k Pies and the like).
>>
>> Does this include demodulatio= n on the pi? cause even when i dumped the
>> pi i was given for th= at purpose (with a <2Mbit I/Q stream) and
>> replaced it with s= ome 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 the= se low-powered ARM systems are just good
>> enough for gathering l= ow-bandwidth, non-critical USB traffic, like
>> those raw I/Q samp= les from a dongle, but unfit for anything else.
>>
>
--0000000000009a39b50577e696f7--