On Monday 09 October 2006 7:46 pm, Alan Stern wrote:
> On Mon, 9 Oct 2006, David Brownell wrote:
>
> > > > > I don't like the idea of having two separate pathways for reporting
> > > > > the
> > > > > same kind of error. If one reporting technique is reliable and
> > > > > another
> > > > > isn't, why keep the unreliable one?
> >
> > Both mechanisms being dicussed are reliable within their domains.
>
> That's a very wishy-washy comment. "This technique doesn't always work,
> but whenever it does work it is reliable."
Not trying for accurate paraphrases, are we then ... ? That's not at
all what I said; neither in meaning nor in intent.
Could you explain just why it is you so dislike the notion of reporting
faults at submit time ("early") when that's possible?
> The lengths of underruns are generally biased toward low numbers, right?
> The most common length is 0 (no underrun), and the next most common is 1
> slot.
Zero is not an underrun and would not be reported as such!!
And yes, well written drivers won't hit underruns very often at all,
and any happening would be "short". Not necessarily just one slot;
when the slots are one microframe apart, there'd be more variability.
> Now I don't have hard numbers to support this, but I rather suspect that
> the amount of work involved in returning an error code and then doing a
> special jump forward by 1 slot is more than the amount of work involved in
> simply accepting the data, queuing it uselessly, and blindly moving on.
Hmm, "queueing uselessly" is not the same as ISO_ASAP ... you're talking
about a different ISO scheduling policy here. Consider two ISO urbs U1
and U2, with packets P1a..P1g and P2a..P2g respectively, intended to go in
slots 1..14 as S(1) = P1a, ... S(7) = P1g, S(8) = P2a, ... S(14) = P2g.
Now assume that after slot 7 there's a dropout of 2 frames. There are
two ways I think we're talking about, after S8 = empty, S9 = empty:
ISO_ASAP: S(10) = P2a, S(11) = P2b, ................... S(16) = P2g
"uselessly": S(10) = P2c, S(11) = p2d, ... S(14) = P2g
So at some level the question is just "who implements the skip" involved
in forcing that "useless" notion: HCD (new sched policy), or driver.
And similarly, whether the system needs to waste time computing the data
that will have been skipped.
For the moment, I'm assuming "not the HCD", to avoid defining and
implementing another ISO policy ... one that would apply only on a
particular resubmit/fault path (and thus be error prone), pruning
out some of the packets the driver said to transmit.
> In any case, missed slots do _not_ turn into delayed/out-of-phase data.
> They are just missed, or as you say, pure dropouts.
Only if you assume there's a new ISO scheduling policy. ISO_ASAP *would*
turn into delayed/out-of-phase data, since nothing would be pruned. If
you consider a series of URBs 0-9 with some dropouts:
0123456789 ... no dropouts
0_1_2_3_4_5_6_7_8_9 ... dropouts are "_", no pruning
0_2_4_6_8_ ... dropouts are "_", with pruning
That second case is strict application of ISO_ASAP, without any code
to prune out phase errors. The third case assumes someone (and in
my model, not the HCD) does that pruning.
> > I don't know that Linux makes use of the explicit feedback channel that's
> > implemented by interrupt transfers going the opposite direction to the
> > ISO transfers, but such mechanisms are certainly spelled out in the USB
> > spec ... and they clearly spend extra processing to achieve more accurate
> > synchronization.
>
> I'm not sure what you mean. The only synchronization mechanism I remember
> in the USB spec has to do with synchronizing the clocks of multiple host
> controllers. That's not directly related to what we're discussing...
See section 5.12.4 of the usb 2.0 spec where different feedback models
for iso endpoints are discussed; all of section 5.12 is relevant.
- Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
