In a USB driver, I'm chaining ISO urbs by resubmitting the URBS in the
completion handler. I also time the calls to the urb completion handlers
using do_gettimeofday(). Most of the time, the time between interrupts is
at most 1.01 ms, but occasionally there may be a 2 ms time inbetween
interrupts.
Quite reasonable ... even expected, if something else (BIOS intrusion?)
blocks out IRQs for no more than a millisecond or so. If interrupts are
blocked for longer times, or other stuff kicks in, it could be longer.
Are you just chaining, or is another URB queued to handle I/O delays?
Most folk seem to arrange a handful of packets per URB, and keep two urbs
queued, which tends to tie down about two pages per ISO stream and cost a
couple hundred IRQs per second (full speed).
I'm just chaining. 4 urbs per device. 2 read urbs and 2 write urbs.
Sounds to me like you're queueing two urbs, AND chaining the
completion of one urb with its resubmission. Terminology.
And that's really not enough to stream iso reliably, since
each of those urbs is only handling one iso frame at a time.
I'm testing with 3 devices.
Are you saying that my delays may be caused by memory accesses?
No, I said I/O delays (latency). Suppose you get an interrupt
that some other driver took 10msec to handle? You've only got
one packet in the queue, and you'd have needed ten to handle that
long latency (10msec delay).
Memory speeds are measured in nanoseconds, not milliseconds. :)
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
