On Thu, Dec 06, 2001, Steve Calfee <[EMAIL PROTECTED]> wrote: > One other thing, I keep seeing people write about the PCI bandwidth hogging > option in the uhci host controller drivers. The idea is if you get a NAK > from a bulk device in a frame, keep asking it in case it gets ready in the > rest of the current frame. This causes a torrent of INs or OUTs on the USB > bus and apparently keeps the PCI bus busier too. The funny thing is I have > never seen any device that NAKs in a frame be able to respond again in that > same frame. Why would they? Another popular OS (tm) would never ask after > seeing a NAK, so it would be pointless effort on the device's part. Has > anyone seen (with a bus analyzer like CATC) a device respond in the same > frame in which in NAKed? I think this attempt at optimizing the USB bus > bandwidth should be removed from the kernel, it just confuses people.
That's wrong. The idea isn't to ask a device after a NAK for more data. The idea is to ask a device who can handle multiple transfers per frame to keep sending data. To efficiently use all of the bandwidth the USB bus provides. We don't differentiate between devices who NAK and devices which actually send data. We do disable FSBR if a device doesn't transfer data for a couple of frames. Maybe we can extend this to disable FSBR if we only see one TD worth of progress per frame as well. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
