Luke-Jr wrote: > > And this is the way that the USB protocol works, a device can not send > > data to the host unless it is asked for it. So the host always has to > > ask for it. > > I'm aware of that - but wouldn't it be possible to just ask less often to > reduce the bandwidth load? It depends on the device hardware. Some USB devices by design (or perhaps lack thereof) silently discard incoming data if no request is pending. It's easy to see why devices do this when considering the increased complexity of device firmware to queue responses on a bulk-in endpoint after processing a command on a bulk-out endpoint. It's obviously much better for everybody involved to use control transfers instead, but meh who cares about such details, too difficult, let's go shopping. As was already mentioned, the FTDI protocol is exceptionally poorly designed in that not only is there in-band overhead for every data transfer but the protocol also implements its own in-band signalling as opposed to using the signalling primitives already present in the lower layers of USB. This translates to wasted resources throughout the entire system; bus time, CPU time, power consumption. Greg's point about the host controller still stands. > What is the issue? It seems that the host controller IP fires interrupts too frequently. Ie. based on the number of transfers as opposed to e.g. bus utilization. At first glance that may not seem like a very important distinction but there is, as always, quite a significant difference between that-seems-ok-lets-ship-it technology and something well-understood. > I suppose the controller might be able to delay the URBs such that > they just start taking longer; is that what you expect should happen? An efficient HC design would at a minimum coalesce interrupts for things that occur $close_enough to each other, making use of knowledge about the schedule for the bus. > As far as I know, this isn't a CPU-load issue. Then can you investigate and report back on what *is* the issue? Too high interrupt load is also a kind of CPU-load issue, even if it doesn't show in top output. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
