On 5/11/06, David Brownell <[EMAIL PROTECTED]> wrote:
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 ...
I'm looking at things from the view of the FS/LB bus and the frame on
that bus. In the use cases I'm currently concerned about, the high
speed bus (and any one uFrame) is never going to run out of bandwidth.
However, if I schedule a split in uFrame Y0 that uses only a fraction
of of that uFrame's worth of the full-speed frame, idle the full speed
bus, then schedule another split that runs in the next uFrame's (and
thus in the Y1 section of the FS frame), there ends up being a hole in
the FS frame that I'll likely not be able to schedule anything into,
and places additional pressure on the scheduler being able to fit
large isos. In practice, I'm often seeing usbaudio.c schedule the
largest iso request last, so this isn't just theoretical.
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.
Correct, but the reason we need to shift in the FS/LS case is a
consequence of how the TTs are designed; ie, the FS frame is segmented
when viewed through the TT, a situation that's not true in uhci or
ohci or any 1.1 HC I know of. They just run their full-frame queues
in order and don't worry about resource contention. They're not
trying to expilictly schedule large multipart transfers into a
segmented frame.
Monty
-------------------------------------------------------
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&kid0709&bid&3057&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
