On Thu, 6 Dec 2001, Pavel Machek wrote: Hi,
> This allows end-user to configure if he wants high bandwidth and slow Am I completely wrong when I assume changing #define's in the driver source aren't normal end-user configuration tasks? > PCI or if he wants high bandwidth and possible unfairness. I never > seen that unfairness in real life. Well, probably not with a single device being active on the bus and rather short transfer size anyway. But what if there are quite a number of transfers scheduled for different device and, even worse, some of them (think scanners) use larger transfer sizes? The unfortunate last on the schedule would get really sucking performance - think of a number of short transfers required for a storage device doing sg with short blocks. > +/* CONFIG_USB_UHCI_HIGH_BANDWITH turns on Full Speed Bandwidth > + * Reclamation: feature that puts loop on descriptor loop when > + * there's some transfer going on. With FSBR, USB performance > + * is optimal, but PCI is slowed down up-to 5 times, slowing down > + * system performance. > + */ > +#define CONFIG_USB_UHCI_HIGH_BANDWIDTH 0 This defaults to FSBR being disabled - right? > +/* *_DEPTH_FIRST puts descriptor in depth-first mode. This has > + * somehow similar effect to FSBR (higher speed), but does not > + * slow PCI down. OTOH USB performace is slightly slower than > + * in FSBR case and single device could hog whole USB, starving > + * other devices. > + */ > +#define USE_BULK_DEPTH_FIRST 1 // 0: Breadth first, 1: Depth first In all my throughput measurements the difference between breadth first and depth first was pretty small - something like 16 vs. 17 packets (64 bytes each) scheduled for each frame. Time saving is something like 1 or 2 usec for every packet because the cached QH must not be fetched from the schedule. And if the device returns NAK the HC follows the breadth path anyway. I.e. in situations where a NAKing device may create some PCI contention with FSBR I simply don't buy things are much better with depth first. Well, the decision is obviously to be made by the maintainer - but I'd like to comment that both changes of the default behaviour do introduce a further kind of subtle difference for UHCI compared to OHCI. IIRC, OHCI has FSBR always enabled and depth first is simply not available. If there is some need to make this subject of user-configuartion activities - what about a module option (which should default to FSBR=on and breadth first, IMHO)? Regards, Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
