On Thu, 16 Apr 2009, Dan Streetman wrote:
> In addition to below, I agree with your other email in that the
> current code can allow the execution of a transfer to be delayed up to
> (but no more than) 1 uframe (I mentioned this several days ago also).
> So as far as changes that need to be made, is this a complete list:
>
> 1. use best-case calculations in transfer time (currently uses
> worst-case calculations)
For scheduling, yes. Continue to use worst-case values for budgeting.
> 2. ensure all interrupt transfers come after all isoc transfers within a frame
(Likewise, insure all low-period interrupt transfers come after all
higher-period interrupt transfers.)
We might want to hold off on this, or not do it at all. But if we
don't do it, then insure that CSPLITs are always issued in the correct
order.
> 3. change scheduler logic to:
> a) ensure for each uframe, the start of the last transfer does not
> get delayed into the next uframe (this will probably replace most of
> the current logic)
Not quite -- make sure that the start of _any_ transfer following the
one being inserted doesn't get delayed into the next uframe. And make
sure that the end of any isoc-IN transfers don't get similarly delayed.
If/when rebalancing is implemented these restrictions can be removed,
since we'll rebalance the delayed transfers.
> b) allow starting any transfer (including large isoc) in non-empty uframe
This is part of the logic that will get replaced.
> 4. implement rebalancing
Some indefinite time in the future.
> 5. implement FSTN
Also siTD backpointers -- these have got to be easier than rebalancing.
> Did I miss anything?
6. Do budgeting of high-speed split transactions. This will be
complicated by the lack of appropriate formulas in the spec.
Which reminds me, can you explain the details of the formulas in
5.11.3? I understand much of them but definitely not all.
> > 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!).
>
> Well no, you are right. I think that the carryover logic prevents
> this from happening, but I haven't specifically thought about that
> case.
I'm pretty sure it doesn't prevent this.
> Yes. I think I finally understand sec 11.18.1 and fig 11-66. I
> didn't understand it before, but as you pointed out in your other
> email, stopping with only 29 bytes allowed in uframe 6 is nowhere near
> 90%. What the spec seems to have done here is taken the 90%
> requirement to apply to the worst-case calculation ("budgeting"), and
> reversed that to say, ok in the best case, we can schedule for 1157
> bytes total per frame. When we do a best-case (no bit-stuffing)
> scheduling of 1157 bytes, it will probably take a little more than
> 1157 bytes on the wire due to bit-stuffing, but in the very worst case
> it will never go above 90% of the frame. So "schedule" for 1157
> best-case bytes; "budget" for 90% of the uframe.
You shouldn't take that 1157 too seriously. Basically all it means is
that there's never any need to schedule more than 1157 data bytes
during a frame, because budgeting rules it out. But since the rest of
that section is all about scheduling, not budgeting, this isn't an
important point.
> So the scheduler shouldn't use the formula from sec 5.11.3, but it
> also needs to account for "interpacket gap" and "bus turnaround time"
> too, as well as the TT think time, right? Do we know those numbers?
> For example table 5-4 says a full-speed isoc transfer has 1 byte of
> "interpacket delay". I am not seeing where that number is coming
> from....?
No, the scheduler needs to use best-case timing. Interpacket gap and
bus turnaround time are both under 8 bit times; we can ignore them.
(Especially since turnaround time is just a maximum -- its best-case
value is close to 0. The same goes for TT think time.) But we
probably should count SYNC time (1 byte) and allow for tokens,
acknowledgments, and CRC bytes. The spec isn't too clear on this...
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
