On Tue, 10 Oct 2006, David Brownell wrote:
> 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?
Okay, I overstated things. Submission-time fault reporting is appropriate
when the HCD can't guarantee that the last slot will be processed and
hence can't guarantee there will be a completion interrupt.
> > 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
Actually what I had in mind was this:
"uhci": S(8) = P2a, S(9) = P2b, S(10) = P2c, ..., S(14) = P2g
but with the understanding that S(8) and S(9) are filled in after the
hardware has already processed them, so their packets don't get sent.
To me that's a continuous stream: Every slot gets filled and each URB
starts in the next slot after the previous URB. And that's how uhci-hcd
interprets URB_ISO_ASAP.
Of course this isn't functionally different from your "uselessly" scheme;
it's just an implemention detail.
> 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.
Well, the data have already been computed; they are part of U2. Filling
in the useless slots involves a little extra work that could be avoided
(with some extra effort).
> 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.
But if the HCD doesn't "implement the skip" then we do run into the
problems you mentioned of delayed/out-of-phase data. Unless the U2
submission is refused and the driver forced to try again. This doesn't
seem like a good idea; after all, the HCD is in a much better position to
know which slots will be missed.
> 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.
It's a matter of definitions. Remember, slots are just pointers in a
tree-like data structure. The HCD can fill them in at any time, even
after the controller has looked at them. Put each block of data in the
slot where it belongs, as in the "uhci" scheme, and the pruning is
automatic.
> > 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.
I'll have to go back and read through it...
Alan Stern
-------------------------------------------------------------------------
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
