hi Alan:
2014-02-07 23:40 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Fri, 7 Feb 2014, vichy wrote:
>
>> Hi Alan:
>>
>> 2014-01-31 2:23 GMT+08:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
>> > On Fri, 31 Jan 2014, vichy wrote:
>> >
>> >> Hi all:
>> >> I have some questions about bandwidth calculation
>> >> 1. why tt time need to include one maxp bus time ?
>> >> qh->tt_usecs = NS_TO_US (think_time +
>> >> usb_calc_bus_time (urb->dev->speed,
>> >> is_input, 0, max_packet (maxp)));
>> >
>> > Because tt_usecs is the time required to send a maximum-size packet.
>> > So of course you have to include the maxp bus time.
>> is it the requirement defined in spec?
>> if so, would you please tell me where I can find it?
>
> Section 11.18.2 (last paragraph on p. 373):
>
> The host always uses the maximum data payload size for a
> full-/low-speed endpoint in doing its budgeting.
>> 2. in tt_available, below is used to check whether tt time is bigger than 125us
>> if (125 < usecs) {
>> int ufs = (usecs / 125);
>> int i;
>> for (i = uframe; i < (uframe + ufs) && i < 8; i++)
>> if (0 < tt_usecs[i]) {
>> ehci_vdbg(ehci,
>> "multi-uframe xfer can't fit "
>> "in frame %d uframe %d\n",
>> frame, i);
>> return 0;
>> }
>> }
>> is it possible tt time bigger than 1 uframe?
>
> Yes. Any isochronous transfer that is longer than 188 bytes will
> require more than one uframe.
from spec's explanation, the usecs in the above source is the budget
calculated with Maxp instead of bandwidth indeed we need to transfer.
Why it is still possible over 125us?
for the case the ep max packet size over 188 bytes?
>
>> >> 3. below is the fomula to calculate bus time
>> >> Full-speed (Input)
>> >> Non-Isochronous Transfer (Handshake Included)
>> >> = 9107 + (83.54 * Floor(3.167 + BitStuffTime(Data_bc))) + Host_Delay
>> >> what is 9107 and 3.167 used for?
>> >> (9102 is not equal to FS bit time * FS protocol overhead)
>> >
>> > 9107 is the overhead. It includes things like inter-packet delays, the
>> > IN or OUT token packet, the ACK packet, and so on.
>> in spec I only find the formula, but spec didn't tell where this 9107 come from?
>
> No, it doesn't. And in fact, the values in the spec are wrong because
> they don't take into account the delays caused by intermediate hubs.
>
>> take Full buck for example, which is non-iso, the protocol overhead is
>> only 13Bytes.
>
> What do you mean by "Full buck"?
sorry it is my typo, I mean FS bulk.
>
> For each packet (token, data, and handshake), the overhead includes
> inter-packet delay, cable delay, SYNC, bit-stuffing, and End-Of-Packet
> -- all in addition to the PID, token, and CRC bytes.
>
> I don't know where you got that "13" from. If you assume the
The 13 bytes I see is from usb spec section 5.8.4.
> inter-packet delays always require 1 byte time and count up the
> inter-packet delays (3), SYNCs (3), token bytes (3), PID and CRC hytes
> (3), and handshake (1), that adds up to 13 bytes of protocol overhead.
> But it leaves out cable delay, bit-stuffing, and End-Of-Packet signals.
>
> You also have to remember that the spec allows the clock rate on
> Full-Speed devices to vary by up to 0.25% of the nominal rate.
so you mean FS speed will be 12M bits/s +- 30000 bits/s?(30000/12M = 0.25%)
Appreciate your help
--
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
