On Sun, Feb 23, 2014 at 07:03:54PM +0000, Luke-Jr wrote: > 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? The device itself specifies what the polling rate is, so the host is supposed to do what it is told to. I suggest using a different device if this is a problem :) And it's not a big load at all, have you measured it? > > > 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? The UHCI "bug" was that for "empty" USB requests, it was burning up the PCI bandwidth of the whole machine. Things like that should be done in hardware, not software, as it's just busy-work that hardware can handle quite well. But this is a different issue, real data is being sent, so the controller has to process it. Nothing it can do about it (see above for the "device sets the rate of packets"). > > 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. What is it then? thanks, greg k-h -- 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
