On Wed, 11 Mar 2009, Stefan Bruens wrote: > Hi, > > I have some questions regarding latency for USB packets. After having read the > USB 2.0 specification and the Intel EHCI specification (v1.0), I have come to > the following conclusions: > > Assuming a device with 1 IN and 1 OUT endpoint (bulk), directly connected to > the USB root hub, no other devices on the same port. Fixed package size of 512 > bytes (in and out). IN packets are generated at a constant rate of about 4 > packets per microframe, OUT packets are generated as bursts of variable size. > URBs for IN and OUT are 512 bytes each (single USB packet). > > I would be very grateful if anyone confirmed or turned down the following > statements: > > 1. transactions for IN and OUT will be scheduled round robin, given there are > any OUT packets in the queue Yes. > 2. the device will be polled for available IN data by the host every > AsyncSchedSleepTime interval (10us, see EHCI spec 4.8.4) More or less. The NakCnt field is involved too. > 3. OUT packets will be transmitted immediately when they are available (given > no other ongoing transaction, device has available space (PING->ACK)) OUT packets are also subject to the AsyncSchedSleepTime delay. > 4. an interrupt will only be generated by the EHCI controller once every > microframe (when interrupt on completion is set), introducing a latency of up > to 125 us. Yes. > Assuming the device would send back any received packet immediately, this > would result in the following round trip latency, as seen from user space: > > sequence of tokens/length in bytes including sync, turnaround ... (see USB > 2.0; table 5-10): > PING, ACK ~ 34 bytes > OUT, DATA, ACK ~ 55 + 512 bytes > IN, DATA, ACK ~ 55 + 512 bytes > > ignoring bit stuffing, this sums up to (144+1024)*8/(480e6/s) = 19us, + > interrupt delay. > > If I have a userspace application which submits one 512byte OUT and one > 512byte IN URB, the OUT URB can be reaped immediately, and the IN URB can be > reaped (completed) at least 19us, at most 134us later (assuming no latencies > when switching between kernel and userspace, and no processing overhead in > kernel - how much will this be?). Switching and processing overhead depend on the speed of your CPU. There's no simple way to predict it; you have to measure it. Average latency can be reduced greatly if the program submits multiple URBs asynchronously or uses URBs larger than 512 bytes. 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
