> > > The EHCI FS/LS sceduling should probably be aping the OHCI > > > behavior as it's known to work well. > > > > No; ohci-hcd does some "best fit" logic, which happens to be cheap for > > that hardware. Whereas ehci-hcd uses "first fit", because it's costly > > to do highspeed scheduling. > > I don't mean we should emulate how the OHCI hardware is driven; I mean > that the end-result, the final produced FS frame produced by OHCI, is > efficient and that we should aspire to that level of efficiency in our > end result-- the FS frame produced by the TT.
So that's a different issue than you had been discussing, and one that I wouldn't initially describe using the word "efficiency". OHCI acts that way because it doesn't have a TT scheduler. The current TT scheduler output is doesn't really understand TT bandwidth; the schedules it produces are not "dense", and your issue is that the schedules aren't dense. For efficiency, one basic measure is CPU cost. It's trivial to prove that a "first fit" takes fewer CPU cycles than "best fit", since it can stop after finding the first valid solution. Another measure is the electrical cost to execute the resulting schedule. I think that executing all schedules with the same number and size of transfers is going to consume the same wattage for its USB signaling, and Linux has DMA scheduling, so that's the only hardware cost that's apparent. > > The similarity is basic: see how much space is available, try the next > > schedule point if this one doesn't have enough (in all schedule slots). > > And that's already coded. > > Except that the way it's broken up now, I can't get a 1Mbps iso in > transfer to work through the TT, when ohci can push/pull 9Mbps to this > specific device without hiccups. And that's not related to the policy you were asking about -- whether to schedule a given ISO transfer always starting in the same uframe. It's an entirely different issue ... whether the TT scheduler does "dense" schedules or not. It's been getting better at doing them, but only slowly since not many folk need them. (I'm glad you seem to have test cases that let you construct and stress test dense periodic schedules. That's a huge help.) That is, your beef is with the weak TT scheduling, which isn't something that OHCI (or UHCI) does, and which accordingly can't be borrowed from either of those drivers. - 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
