avoiding usb

This might well be the worst problem with the Pi.  This Broadcom SoC just wasn't made for networking.

It contrasts rather badly with the TI SoC on the BeagleBone which provides both Ethernet MAC and two USB ports on the chip directly.

I wonder if Broadcom has a better device in this range that might be used for a future version of Pi.

well yes, it is somwhat less than ideal, but that`s what there is to work with.

know any work-arounds?

YT2095 . wrote:

 

know any work-arounds?

Use a Model A (once available) in combination with the Ethernet-over-USB gadget driver.  The on-chip USB controller will then handle the network traffic in the usual interrupt-driven way (an assumption, but reasonable I think), and a downstream class-compliant USB hub will also be handled by the normal interrupt-driven USB driver.

It's only a partial solution since it requires something else to provide the actual Ethernet hardware, but at least it avoids the polling.

Interesting that you should mention polling, Esp since the Pi is open source (for the S/ware at least), it should be perfectly possible to Lower this 8KHz polling rate to something more reasonable surely?

or perhaps make it at least Semi-inteligent whereby it`s scanned at a rate suitable for that which is in use.

I guess you could poll less frequently for keyboard and mouse traffic since their data rate is somewhat low, but remember that the average response latency is half the polling interval, so it would become progressively worse as you decreased the polling rate.  And for Ethernet, that sounds extremely unlikely as a viable solution at all, since you could end up losing data in buffer overruns between polls.

Basically, "polling == bad", period.

My understanding, which might be wrong, is that the 20% CPU overhead from the 8k interrupts/sec is from the USB driver on the on-chip SoC USB port. So it would be just the same in the Model A.  It has been suggested that it might be possible to make a much more efficient USB driver, reducing the interrupt service routine overhead by up to 90%, but even though the code is open-source, not clear if there's enough good documentation to really do this (?)

The 8 kHz interrupt rate is actually mandated by the specific USB hardware they used in the SoC. 8 kHz is apparently the high-speed USB2 "micro-frame" rate, and any lower rate would not work correctly (at least with high-speed USB devices). You can think of it in analogy to a "winmodem" which offloads some of the processing to the CPU, to save complexity/cost in hardware.

jbeale wrote:

 

My understanding, which might be wrong, is that the 20% CPU overhead from the 8k interrupts/sec is from the USB driver on the on-chip SoC USB port.

It's a timer-driven poll of the external device, apparently.  On a Model A, it wouldn't need to poll anything, since the USB driver would just sit there quiescent and only become active when USB data arrives and the SoC's USB controller then generates an interrupt to process it.  Ie. event-driven, just like everything else in the standard *nix model.

jbeale wrote:

 

My understanding, which might be wrong, is that the 20% CPU overhead from the 8k interrupts/sec is from the USB driver on the on-chip SoC USB port.

It's a timer-driven poll of the external device, apparently.  On a Model A, it wouldn't need to poll anything, since the USB driver would just sit there quiescent and only become active when USB data arrives and the SoC's USB controller then generates an interrupt to process it.  Ie. event-driven, just like everything else in the standard *nix model.