Combining BeagleBone and Raspberry Pi

Because of the dreadful 8k polls per second that the Broadcom SoC has to perform to handle the external USB and Ethernet, it occurs to me that the most effective way to combine a graphics-handling Pi with the BeagleBone is to use a Pi Model A, so that USB is handled properly by interrupt hardware on the Broadcom SoC.

The X11 traffic can then be sent to the Pi through the built-in USB channel using Ethernet-over-USB networking, which the BeagleBone provides out of the box anyway to give beginners a fast and simple QuickStart experience.  Since there are no Model A boards in the wild yet, I'll have to use the less efficient Model B for now, but it's a goal to keep in mind for the future.

Morgaine.

Apparently the issue is caused by the Broadcom SoC itself, not by SMSC's LAN9512 device .  From a snippet that jbeale quoted in another thread:

jbeale wrote (quoting the Foundation's dom):
Yes, the USB hardware is "dumb" and needs to be told what
to do (by the core) every frame. More advanced USB hardware
blocks would handle the simple responses in hardware, and so
produce less load on the CPU (esp. when idle).

So, given that tjhe dumb USB controller on the SoC would have fewer things to poll on a Model A because the LAN9512 is not present and there would be no need for 12Mbit/s operation in this application, we could decrease the USB poll rate on a Model A to a low rate suitable for X11 transfers through Ethernet-over-USB

SMSC suggests a slow poll rate of every 4ms for Hi-Speed operation in their LAN9512 datasheet, but we can reduce the rate further as it's mostly a tradeoff between latency and bandwidth efficiency I think.  Combining a reduced polling rate with a better USB host driver will hopefully compensate for the SoC's Synopsys USB core being "dumb" as stated.

Morgaine.

Apparently the issue is caused by the Broadcom SoC itself, not by SMSC's LAN9512 device .  From a snippet that jbeale quoted in another thread:

jbeale wrote (quoting the Foundation's dom):
Yes, the USB hardware is "dumb" and needs to be told what
to do (by the core) every frame. More advanced USB hardware
blocks would handle the simple responses in hardware, and so
produce less load on the CPU (esp. when idle).

So, given that tjhe dumb USB controller on the SoC would have fewer things to poll on a Model A because the LAN9512 is not present and there would be no need for 12Mbit/s operation in this application, we could decrease the USB poll rate on a Model A to a low rate suitable for X11 transfers through Ethernet-over-USB

SMSC suggests a slow poll rate of every 4ms for Hi-Speed operation in their LAN9512 datasheet, but we can reduce the rate further as it's mostly a tradeoff between latency and bandwidth efficiency I think.  Combining a reduced polling rate with a better USB host driver will hopefully compensate for the SoC's Synopsys USB core being "dumb" as stated.

Morgaine.

Hmmm, no, that's not going to work because USB doesn't have Ethernet-like jumbo frame capability, its frames are limited to 1024 bytes at Hi-Speed.  So, it seems that there's a showstopper on trading off response latency for polling efficiency.  Bah.

Since we can't do that, I guess we have to look at the timing demands imposed by multiple 1024-byte chunks of X11 data wanting to be transferred over to the Pi using Ethernet-over-USB at an instantaneous peak rate of 480Mbit/s.  Just to get a feel for the numbers, let's ignore all issues of encapsulation, signaling, and protocol stacks.

That frame transfer seems to take about 17 microseconds for the raw data transfer down the wire considering only the peak rate, so if such chunks of data were sent in a continuous stream then we would have to poll at around 58KHz to avoid gaps where nothing is happening.  This may not even be possible, but even if it were possible then the Pi's dumb USB controller would be slugged to death by it using the existing driver.

So, "it's not that simple".  We'll have to do lots of measurements and see where this goes.

I have a Freescale imx53 QSB sitting next to my Pi. It has a USB OTG and I have run a network connection between the two (CDC ECM - don't have EEM in my antiquated kernel for the imx) and tried running NBD for swap and have yet to try using a usb storage driver which might be a bit more efficient. I mainly use it to compile for the Pi as I have it running Raspbian in a chroot and the faster cpu, extra ram and sata hard disk make things run a bit faster than the Pi. I can imagine them bundled up in a box together with the imx doing compiles courtesy of distcc and providing some of its 1G ram as swap.

I think using a second arm board as a "coprocessor" for the Pi is an interesting idea but the status of the Pi's USB does put a damper on it. Another option is to use the Pi as a "graphics card" for another arm board as the Pi's videocore is pretty decent. I can imagine remote controlling a stack of Pi's bolted onto HD displays.

That's very interesting Paul.  I was looking at the i.MX53 QSB myself not long ago when looking for an ARM board to fill in the gap during the long Pi pre-ordering wait, but decided on the BeagleBone instead.  I'll undoubtedly purchase other ARM boards before long though, since I want gigabit Ethernet and lots of RAM.

I'm very interested in your mention of CDC EEM.  Because EEM doesn't seek to do all the NIC-type signaling that full CDC ECM does, this might mean that more of the SoC's time can be dedicated to bulk transfers and less to control frames, which might translate into less polling being required.

Yes, I agree completely that the VideoCore seems really good on the graphics and media side --- the main problems being addressed here are on the communications side.  This is why at least in principle using the Pi to run the BeagleBone's X11 server and a few related ancillaries like the window manager seems like a good idea.

It's certainly proving a worthwhile topic for head scratching, even without my Pi having arrived yet.

Morgaine.

Paul Shirren wrote:

 

I think using a second arm board as a "coprocessor" for the Pi is an interesting idea but the status of the Pi's USB does put a damper on it. Another option is to use the Pi as a "graphics card" for another arm board as the Pi's videocore is pretty decent. I can imagine remote controlling a stack of Pi's bolted onto HD displays.

It's the 2nd of the above that I'm focused on.

I have a thread about non-HPC cluster systems over here -- http://www.element14.com/community/thread/17542?tstart=90 --, and it's going to be a heterogenous cluster with different horses for different courses.

Cortex-A8/A9/A15 are likely to figure highly for "compute nodes" in the cluster, while the Pi is probably the best board around at this time for "display nodes"..  I envisage having at least 3 display nodes in the cluster once Pi boards are available ex-stock, one for each of my 1920x1200 LCD screens.

PS. I keep having to state "non-HPC" because so many people seem to think that clusters have only the single purpose of performance, which is most definitely not the case.

Morgaine.

The XRF radios that Simon Monk has been advocating here are nicely applicable to BeagleBone as well as to Raspberry Pi, and could conceivably  be used even to link the two together for low-bandwidth messaging.  In case an application arises, some handy links:

• Simon's project post --- http://www.element14.com/community/thread/18613?tstart=0
• XRF home sites --- http://www.openmicros.org/index.php/articles/84-xrf-basics , http://shop.ciseco.co.uk/ , http://www.openkontrol.org/wiki/tiki-index.php
• RF regulatory links --- http://www.element14.com/community/message/53650#53650
• Texas Instruments CC1110F32RSPCC1110F32RSP datasheet --- http://www.ti.com/lit/ds/symlink/cc1110f32.pdf

This could be particularly useful when the Pi Model A comes out, since it has no on-board Ethernet comms.

Yet another idea is to put one XRF on either a BeagleBone or a Pi, and the remote standalone XRF on something like the Olimexino-STM32 instead, because the latter has a built-in Li-Poly battery charger --- http://www.olimex.com/dev/olimexino-stm32.html --- And since this Olimex board costs under 17 quid from Farnell, that matches the low-price XRF modules perfectly -- http://uk.farnell.com/olimex/olimexino-stm32/board-dev-olimexino-stm32/dp/2061325

PS. Blog post on combining BeagleBone with XRF -- http://www.e-ssociation.com/blog/?p=112

Morgaine.