On Tue, Apr 14, 2009 at 3:11 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > We seem to be approaching agreement. I'm going to skip over a bunch of > stuff from your emails as being no longer relevant, if you don't > mind... Yep, I cut out the several things I agreed with to focus on the couple remaining points. > On Tue, 14 Apr 2009, Dan Streetman wrote: > > Why? This follows from the constraint (implicit in the USB spec and > stated explicitly in the EHCI spec) that in any uframe, CSPLITs must be > sent in the same order as their corresponding SSPLITs. Since an siTD > will always precede a QH in the periodic list's chain of pointers, the > isoc CSPLIT would precede the interrupt CSPLIT if they both occurred in > the same uframe -- and that would violate the constraint. Yep, you are right on that point - so to adhere to spec, the TT scheduler really does need to rebalance the TT schedule to put all the interrupt transfers after isoc transfers. >> I disagree that interrupt OUT transfers have to occur in a single >> uframe. Where does it say that in the spec? > > I expressed myself poorly. What I meant was this: In the best-case > accounting of full/low-speed transactions used by the scheduler, an > interrupt-OUT transfer has to occur within a single uframe. The actual > transactions on the bus don't have such a restriction. > > What is the reason? It's because a TT isn't required to buffer more > than 188 bytes per uframe. I'm not sure where you see that in the spec? I'm looking at 11.19, which says the start split buffer is (minimum) 752 bytes. > In principle, if the first 88 bytes of a uframe were already accounted > for, then a 200-byte isoc-OUT could be scheduled using a 100-byte > SSPLIT followed by another 100-byte SSPLIT in the next uframe. But the > spec doesn't allow this and the hardware doesn't support it. The first > SSPLIT _has_ to be 188 bytes. I disagree with your interpretation. I believe that you can issue a 188 byte SSPLIT even if you know there is another transfer going on, and even if you have issued another smaller transfer (less than 188 bytes obviously) earlier in that uframe. The TT has a (minimum) 752 byte SSPLIT buffer that it uses to buffer transfers up and execute when possible. Can you point me to the USB and EHCI spec sections you're looking at for this? > I agree that the -1 fix is needed. But I don't agree that the > resulting code is bug-free. For example, suppose there's nothing but a > 64-byte interrupt transfer in uframe 0, and you want to add a 150-byte > isoc-OUT. How will the carryover logic either prevent this or force > the isoc-OUT to start no earlier than uframe 3? Eh? I don't follow you, it should start before uframe 3, in fact it should start immediately after the 64-byte interrupt transfer. The best thing to do is schedule both of them in uframe 0, and let the TT run both of them in uframe 1 and the remaining part of the interrupt transfer will carry over on the full-speed bus to uframe 2. > Another issue -- all the calculations in tt_available() and > carryover_tt_bandwith() are done in usec instead of bytes. This > renders them subject to roundoff errors. The USB spec provides the functions that must be used to calculate times, sec 5.11.3. We could use nsecs instead of usecs, although I don't think that rounding impacts much. The USB spec does say in that section that "different implementations may choose to use coarser approximations of these times". > Finally, one last question. The specs (and the code) mention in > several places that with proper scheduling, more than 16 full-speed > transactions will never occur within a single uframe. That doesn't > seem right to me. > > For example, why can't 17 two-byte isoc transfers occur within 125 > usec? As I see it, the bandwidth required per isoc transfer is: > > token packet (1-byte sync plus 3-byte packet) > data packet (1-byte sync, 1-byte PID, 2 bytes of data, > 2-byte CRC) > > which is 10 bytes (plus a fraction for the inter-packet gaps). 17 of > these would occupy less than 187.5 byte times if there's no > bit-stuffing. And if the transfers were 0 bytes long then there would > be enough time for 22 of them! > > So what am I missing? Using the isoc out function specified in the USB spec sec 5.11.3, with a 1-byte isoc, no bitstuffing, and minimum think time (8 bits or 666ns), the per transfer time is 7849.94ns. That only fits 16 times into 125ms (really, about 600ns over). -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
