On Wednesday 10 May 2006 9:38 pm, Christopher Montgomery wrote:
> On 5/10/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
> > > In some
> > > ways it's easier to just stack requests into the full-speed frame and
> > > then plop the splits into whatever uFrame that happens to work out to,
> > > even if that means that, eg, an interval 1 iso request might be
> > > serviced in substantially different portions of the actual full-speed
> > > frame.
> >
> > So with interval 1 (one packet per frame), two consecutive packets
> > might go into uframes 7 then 0?  That'd be more like interval 1/8, and
> > the next might be 15/8, and the next ... the notion was avoiding such
> > relatively non-isochronous behaviors.
> 
> Yes.  the problem is that scheduling the high-speed frame with large
> random gaps (so that isos that exist in all of 256 o512 or 1024, etc,
> frames always start in the same uframe) places additional pressure on
> the scheduler, and complicates counting how many FS usecs are already
> budgeted.

I guess I don't quite see that.  The budget is per-uframe ...


> Even if we restrict all the sitds of a given iso stream to 
> be scheduled in the same uframe, they're not guaranteed to actually
> start in the same part of the uframe.. or even that uframe for that
> matter, the TT is free to delay actually starting the transfer for up
> to two additional uframes anyway.

The scheduling reduces how much shifting is going on.   Plus, don't
forget that high speed scheduling concurrently uses many of the same
resources, and that never gets shifted.





-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to