On Wed, 23 Jun 2004, David Brownell wrote:
The interrupt transfer should normally poll each interrupt endpoint just once per period ... so there should be at most one NAK per period.
Are you sure your driver is scheduling an interrupt transfer? Sounds like it's trying to use a bulk endpoint instead. A bulk transfer could easily waste USB and PCI bandwidth like that.
Maybe my interpretation was wrong and it is the bulk pipe which behaves like that. I saw two pipes, one pipe having one NAK per ms, one pipe having about 117 NAKs per ms. I suspected the interrupt pipe, but I could have been the bulk pipe, too.
Sounds like the bulk pipe.
If it is this way, does it make sense for bulk pipes to be polled that fast? Do they consume all remaining bandwidth by polling, if there are no other transfers? Is this a usual behaviour for devices like USB network and bluetooth devices?
Yes, yes, and yes. If there's a pending transfer, and nothing else for the controller to do, it'll try to move forward on that transfer.
Are there some settings in the host controller to change this behaviour?
No.
- Dave
Thanks in advance for your help!
Christian
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
