On Thu, 16 Apr 2009, Dan Streetman wrote: > If you don't mind, I'd like to summarize, as I think we only really > disagree on 2 points: > > 1. Can more than 188 bytes worth of SSPLTs be issued in a single uframe? > 2. Can an Isoc transfer that is larger than 188 bytes be started in a > uframe that is not empty? > > I believe you think no on both those points, while I think yes on both > points. Note that I think you were confusing my position on #2 with > the current implementation - the current tt_available() implementation > agrees with #2 *only* because it's easier to perform the calculations > that way. Our emails are passing in the night. :-) You've convinced me on #1. With the additional proviso that in any four consecutive uframes, no more than 752 bytes of SSPLIT-OUT data may occur (which the current code doesn't check for!). > For #1: > I see in 11.19 where the spec requires 752 bytes of SSPLIT buffer. I > don't see any place where it mentions that this buffer could be > segmented into 188-byte chunks and therefore overflow if more than 188 > bytes of SSPLITs were issued in a uframe. Additionally, the current > improved TT scheduler code has done exactly this, schedule more than > 188 bytes of SSPLITs per uframe, for years now with no bug reports (as > far as TT SSPLIT buffers overflowing) that I am aware of. > > For #2: > I see in 11.18.4 item 2(a) where it says the first SSPLIT of a > multi-uframe (meaning more than 1 SSPLIT) isoc out transfer must use > 188 bytes. However, only if the above statement #1 is true does this > part of the spec also mean the above position #2 is true. I don't > believe #1 is true, and therefore it is perfectly fine to issue a > 188-byte SSPLIT in a uframe where there already has been another > SSPLIT. Yes, agreed. Without #1, there's no reason for #2 to hold. > I think all of us (you, me, and David) agree on: > > 1. The TT scheduler should be putting all the interrupt transfers > after the isoc transfers. That's certainly the _easiest_ way to do it. On the other hand, with the current code that would prevent you from accepting _any_ isoc transfers larger than 188 bytes if there's an interrupt transfer scheduled in uframe 0. Of course, the current code could be improved... > 2. It would be good to implement "rebalancing", either for moving a > single transfer's position later in the same frames, or for moving > many transfers or moving transfers into a completely new frame > position, or both. Also FSTN would be nice to add (for EHCI hardware > that supports it). Rebalancing might be more effort than it is worth, at least for now. FSTN support probably should be added. (And backpointers for siTD's, if they aren't already in there -- I haven't looked.) > There is also the issue of what bandwidth calculation the TT scheduler > should use. It currently uses the regular low/full-speed calculation > as specified in 5.11.3, but you disagree that this is appropriate > because that calculation is worst-case bitstuffing, while 11.18.1 says > best case (no bitstuffing) should be used (although it then > contradicts itself by calculating the per-uframe byte capacity using > worst-case bitstuffing). > > I'm not sure whether to use best-case calculations, which we would > need to create a new function for, or continue to use the worst-case > regular 5.11.3 function. I tend to lean towards the 5.11.3 function, > since the 188-byte calculation also seems to use worst-case > bitstuffing despite what it says in the text. The calculation that > comes up with the 1157 value in the figure does use bitstuffing. > Plugging 1157 into the 5.11.3 calculations gives roughly 900ms. Using > the smallest-time (isoc out) calculation with 1 byte does give 16 > maximum transfers per uframe as specified later in sec 11.18. So, as > you pointed out, it seems that although the spec says "best case no > bitstuffing" it doesn't mean it. Let's be more precise about this. Properly handling periodic transfers requires both _budgeting_ and _scheduling_: "Budgeting" means checking that the transfers don't use more than 90% of the full/low-speed bandwidth or 80% of the high-speed bandwidth. "Scheduling" means deciding which [u]frames the transfers are assigned to and which uframes the S/CSPLITs are assigned to. For budgeting you have to use worst-case figures, i.e., the formulas in 5.11.3 (which are given in ns and can be converted to us with no difficulty). Otherwise the guarantees might not be met. For scheduling you are supposed to use best-case byte counts; otherwise you might fail to accept transfers that could be accomodated. Obviously the two areas interact, because the budgeting will depend on which frames and uframes you allocate for the transfers. Still, they are logically separate notions. Does this clarify things? Alan Stern -- 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
