On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote: > > The current scheduler strategy always tries to place a given periodic > request (be it iso or intr) into the same uFrame slot in all scheduled > HFrames. Is this a requirement of the spec (I don't recall seeing > such a restriction) or merely convenient to the current code?
Neither. > 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. 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. 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. So that means high speed scheduling is multi-level: fifo, uframe, TT. I'm glad to hear it's sounding simpler to you. ;) - Dave ------------------------------------------------------- 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
