On Thu, 7 Jul 2005 [EMAIL PROTECTED] wrote: > > if (start < now) > > start += mod; > > > > Meant to handle sequence-space wrap-around? Does this handle actual > > overruns correctly? > > What do you mean by "overrun"? It's arithmetic modulo "mod"; > and for scheduling, all relevant times need to be in the future.
For example, suppose mod is 2048, start is 5, and now is 2030. This would change start to 2053 (= now + 23), which is what I meant by "wrap-around" and you meant by "modular arithmetic". As a second example, suppose start is 5 and now is 20. Again start would be changed to 2053, and you hope this will trigger an error later on. That's what I meant by "overrun". > > if (likely ((start + sched->span) < max)) > > goto ready; > > > > I don't understand this at all. What's sched->span? > > Initialized earlier: how large a chunk of the schedule does this > URB consume? See itd_sched_init() or sitd_sched_init(). So if the URB runs for too long (sched->span > max), it will always generate an error. You won't try to schedule part of it and then schedule more of it later. And you also depend on this test failing when an overrun occurs. I guess it will if max is safely smaller than mod (say, <= mod/2). On the other hand, the "URB runs for too long" error will occur if someone tries to submit too many URBs and the queue goes too far into the future. It's possible that this is what happened to Luca. > > Does that simply > > mean the requested time is not so far in the future that you can't add it > > to the schedule yet? > > Erm, double negative ... I'll translate as "is so far in the future > that it can't be added". Oops, my mistake. I meant "is soon enough in the future that you can add it to the schedule". And from your comments, it look like the answer is "yes". > There are two strategies for this error case. One is to paper > over the problem and reschedule things. Things would seem to > work, but audio or video would jump, "isochrony" would have been > lost. Arguably better to just drop packets rather than shift > them in time... > > The other strategy -- used for now! -- forces an error, so that > some attention will be paid to actually preventing the error from > happening. As for example these emails... among other reasons, > I rather suspected that high speed ISO would turn up some issues > that merited some more focussed attention than I had time for. This seems reasonable. And if you decide to make it not be an error when an overrun occurs, I would opt for the second choice above: skip some packets but maintain isochrony. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
