On Monday 28 October 2002 04:39 pm, David Brownell wrote: > >>>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). >
Ok. The reason why I have only one in the queue is that the program that uses the driver only generates 1 packet per millisecond. If I added more urbs, the program would have to send out more information at once, say 5 packets to handle a potential 5 ms delay. Thanks for the clarification. I really meant to chain, however I'm just resubmitting . . . a bug that somehow still ends up working like a chain. I guess I'm relying on the fact that once a urb gets submitted it's completed in order. I'm just suprised that an I/O delay could take 2 ms...Thats a lot longer than what I expected. I expect latencies on the scale of us. Thanks, Anton > 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 ------------------------------------------------------- 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
