Hi,
We only had 2 URB's, and that was the problem. The reason why we only
had 2, was because the less URB's you have, the lower delay you have. I
guess we're going to go to 3 URBs. Thanks a lot for your help.
What delay that would increase with the number of urbs queued? I'd
think tolerance for irq delays would increase ... you always need to
keep enough queued to handle your maximum IRQ latency.
Please correct me if I am wrong, but from my reading of how the URB's
work, this situation is accurate:
If you have 4 URB's with an isochronous USB connection. As soon as you
open the connection to the device, there is going to be a set of empty
packets the number of which is equal to the number of URB's. So if you
That makes no sense to me. If it's an ISO data stream, the packets
are supposed to be coming IN (or going OUT) at constant rate regardless
of how many urbs you have posted.
More urbs just means the rate can be sustained (no transfer slots
"missed") for a bit longer without your driver refilling the queue.
have 4 URB's, the first four packets sent will be blank. If you're
controlling something....say a robot....where it is important to
minimize the delay of when you write a packet and it is received, you
would want to have less URB's.
If you're controlling something, I'd sure expect transfer delays
to be a part of the feedback equation ... more of a constant than
the IRQ delays are.
On the other hand, if you are using ISO for OUT transfers (I'd thought
you were using IN like most people), I can see the delay you're talking
about. Though it's not actually a function of how many URBs are queued,
but the number of ISO transfers in that queue ... normally people use
multiple packets per urb, to help meet the service interval.
Getting low latencies on those OUT transfers will be an issue.
Two transfers in the queue should normally handle it, unless
something delays reporting the first completion long enough to
prevent it from re-issuing in time ... as you have noticed.
Thanks for the clarification!
- Dave
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
