On Sunday, February 23, 2014 5:45:19 PM you wrote: > In general this should not cause any problems, but for example the > ftdi_sio driver has the low-latency flag set by default which results in > bulk-in data (mostly empty, status-only packets) being received > every millisecond. > > If the flag is cleared (e.g. using setserial) the latency can be > increased through sysfs (defaults to 16ms). Thanks, this should help. (perhaps-waste-of-time-to-read detailed reply to Greg below..) On Sunday, February 23, 2014 4:14:18 PM Greg KH wrote: > On Sun, Feb 23, 2014 at 06:27:17AM +0000, Luke-Jr wrote: > > If I understand the USB Serial code correctly, at least open devices are > > constantly polled by 2 active URBs replaced immediately upon completion, > > except when the tty layer throttles them. > > It depends on the specific driver, what one are you referring to? I was looking at the circumstances surrounding ftdi_sio, which uses the generic implementation. > 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? > > With many of these devices, this creates significant USB bandwidth usage. > > At least one report found that it starts creating practical problems > > after 12 devices (on a BeagleBone), while adding a delay allows up to > > 60. > > That sounds like a bug in the BeagleBone USB host hardware. It's as if > people didn't learn the problems of the UHCI controller from the 1990's, > which had the same issue :) What is the issue? If there are 2 URBs per device going back and forth constantly, it's almost certainly going to use more bandwidth than if it was 1 URB polled every 10 milliseconds (for example). 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? > Note, the rpi also has the same issue, if you plug in a single USB > keyboard, you used to loose 30% of your CPU. I hope that issue has been > resolved, but it wasn't going to be easy given the hardware chosen in > that device. As far as I know, this isn't a CPU-load issue. Luke -- 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
