[CC trimmed]
On Thu, 6 Dec 2001, Steve Calfee 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? There is every good reason you can imagine: NAK means the device is not ready to accept/donate data at the moment the IN our OUT PID arrives. However, the device might become ready at any point in time later - say 10usec for example. Why would you assume the host had to wait for the next frame (which might be a 100 times longer) to retry? > Another popular OS (tm) would never ask after > seeing a NAK, so it would be pointless effort on the device's part. Has Why pointless? If a device is not double-buffering an endpoint it might need said 10usec to process the data - hence after the first packet was transfered an immediately following IN/OUT request (assuming FSBR enabled) would be NAKed - but the next one may succeed. So with FSBR you can still transfer say 12 packets per frame (instead of about 16 without any NAK). Why would you want this to get limited to 1 packet per frame? > 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 Quite normal observation IMHO. Yes, I see all such things happen - even sequences (everything for the same endpoint) like SOF IN DATA0 ACK IN NAK IN DATA1 ACK IN NAK IN NAK IN DATA1 ACK ... SOF are pretty much the rule - not the exception - for me. If the device is I/O bound this happens even with double buffering and queing on the device side. > bandwidth should be removed from the kernel, it just confuses people. Please don't! Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
