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. 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. Given the already substantial
shifting going on, I had to wonder if eliminating the 'always the same
uframe' restriction was really all that much of a practical
difference... or what the spec actually has to say on the matter. It
seems odd there'd be no official suggestion or mandated behavior.
Another concern: such an irregular schedules would facilitate hitting
configurations which need rebalancing to reclaim space wasted by misshapen
holes. We have no rebalancing code (yet?); not that we seem to have hit
bandwidth limitations other than sub-optimal hardware, but it'd seem be
good to avoid such issues by design.
I had thought of this and had assumed rebalancing code was in place.
Given that it is not, it looks like I have to deal with holes
anyway.... or also write rebalancing code :-(
By the way, one of the next frontiers for high speed scheduling will
be making it more independent of EHCI. There's highspeed silicon that
doesn't use EHCI, and has an even stronger need for software scheduling
because the host talks to hardware at the level of a USB FIFO. EHCI
effectively does fifo scheduling in hardware, but sometimes it must
be done in software.
Well, so far what I'm doing is all at a level above the silicon so the
conceptual implementation is abstract.
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
