Re: some questions about bandwidth calculation
hi alan: 2014-02-14 23:36 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Fri, 14 Feb 2014, vichy wrote: hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? No. stream-usecs is the time required on the high-speed bus, and stream-tt_usecs is the time required on the full/low-speed bus. tt_available makes its decisions based on whether there is enough available time on the full/low-speed bus. Therefore it needs to use stream-tt_usecs. it makes me a little confused. if we try to send 108 bytes to FS iso ep over HS hub. shouldn't we use below formula to calculate what bus time need for? NS_TO_US (think_time + usb_calc_bus_time ( dev-speed, is_input, 1, 108)); it seems no matter we transfer 108, 118, 140, even 188 bytes to FS iso ep over HS hub. The full/low bus time are all the same. appreciate your help -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
On Sun, 16 Feb 2014, vichy wrote: it makes me a little confused. if we try to send 108 bytes to FS iso ep over HS hub. shouldn't we use below formula to calculate what bus time need for? NS_TO_US (think_time + usb_calc_bus_time ( dev-speed, is_input, 1, 108)); That should have the maxpacket size, not 108. it seems no matter we transfer 108, 118, 140, even 188 bytes to FS iso ep over HS hub. The full/low bus time are all the same. That's right. The driver doesn't know how many bytes are going to be sent to the isochronous endpoint. All it knows is the maxpacket size. Therefore it has to assume that all packets will be the maximum size. See section 11.18.2 in the USB 2.0 spec: The host always uses the maximum data payload size for a full-/low-speed endpoint in doing its budgeting. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? 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. Then you must have noticed the sentence just above Table 5-9: The table does not include the overhead associated with bit stuffing. The table also doesn't include the overhead associated with cable delay and intermediate hubs. 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 +- 3 bits/s?(3/12M = 0.25%) That's right. Also, Low-Speed devices are allowed to vary by up to 1.5%, and High-Speed devices are allowed to vary by up to 0.05%. Appreciate your help, -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
On Fri, 14 Feb 2014, vichy wrote: hi Alan: I don't understand your question. At full speed (12 Mb/s), the time required to transfer 188 bytes is (188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us, which is greater than 125 us. @@ -1412,7 +1412,7 @@ sitd_slot_ok ( */ uf = uframe 7; if (!tt_available(ehci, period_uframes 3, - stream-udev, frame, uf, stream-tt_usecs)) + stream-udev, frame, uf, stream-usecs)) if so, shall we modify code like above? Use transfer time instead of bus budget to calculate tt_avaiable? No. stream-usecs is the time required on the high-speed bus, and stream-tt_usecs is the time required on the full/low-speed bus. tt_available makes its decisions based on whether there is enough available time on the full/low-speed bus. Therefore it needs to use stream-tt_usecs. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
hi Alan:
2014-02-07 23:40 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Fri, 7 Feb 2014, vichy wrote:
Hi Alan:
2014-01-31 2:23 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
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 +- 3 bits/s?(3/12M = 0.25%)
Appreciate your help
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
On Mon, 10 Feb 2014, vichy wrote:
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?
I don't understand your question.
At full speed (12 Mb/s), the time required to transfer 188 bytes is
(188 bytes) * (8 bits/byte) / (12 b/us) = 125.33 us,
which is greater than 125 us.
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.
Then you must have noticed the sentence just above Table 5-9:
The table does not include the overhead associated with bit
stuffing.
The table also doesn't include the overhead associated with cable
delay and intermediate hubs.
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 +- 3 bits/s?(3/12M = 0.25%)
That's right. Also, Low-Speed devices are allowed to vary by up to
1.5%, and High-Speed devices are allowed to vary by up to 0.05%.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
Hi Alan:
2014-01-31 2:23 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
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?
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.
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?
take Full buck for example, which is non-iso, the protocol overhead is
only 13Bytes.
appreciate your help,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
On Fri, 7 Feb 2014, vichy wrote: Hi Alan: 2014-01-31 2:23 GMT+08:00 Alan Stern st...@rowland.harvard.edu: 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. 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? 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 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. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
some questions about bandwidth calculation
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)));
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?
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)
Thanks for your help in advance,
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about bandwidth calculation
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.
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.
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.
The 3.167 is the time required for the DATAx PID byte at the start of
the data packet and the CRC bytes at the end.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
