On Fri, Jul 08, 2011 at 10:35:21AM -0300, Werner Almesberger wrote: > Thadeu Lima de Souza Cascardo wrote: > > USB 2.0 says that for full speed devices the frame is 1ms long, while > > the microframe is 125us long for high speed devices. A control transfer > > happens, then, in a 1ms frame, composed of multiple transactions. > > Yes, it clearly happens once per frame. What I'm not quite sure about > is where this limit comes from. The USB 2.0 specification states on > page 40 that > > "A control endpoint may see zero or more transfers in a single > (micro)frame." >
Yes. I see that now. And there are lots of other references to more than one transfer per frame, like the tables with the transfer limits, indicating the theoretical bandwidth limit for USB. > Now, I wonder whether getting only one control transfer per Full-Speed > frame is because of > > - a restriction elsewhere in the USB specification I've overlooked, > - a design limitation of the UHCI, > - a configurable limitation by the Linux USB stack, or > - a bug in my firmware ? > I did some testing in here. One was with a USB token, a low-speed device. The limit would be three 8-byte transfers per frame. So, 6000 transfers would take at least 2 seconds. With the limit of one transfer per frame, that would be 6 seconds. I got 4.3 seconds to execute my sample program. So, no such limit exist in my present conditions. So, I decided to insist on testing and did with a PL2303 usb-serial device. I used 7-byte control transfers, because that's what I can get with this device for non-standard control transfers. Anyway, I got 10000 transfers in less than 2.8s. So that's more than 3 transfers per 1ms frame with a full-speed device. Unfortunately, I have only EHCI in here right now. We can risk from the list then the USB specification and a restriction in the USB stack. It can still be something in the UHCI Linux driver, since bandwidth allocations are done in there. I'm not sure this would be a limitation of UHCI itself, but that's still a possibility. And, then, there's not only the firmware, but the device itself. I get you are using an ATMEGA32U2, right? I have some ATMEGA8U2 in here I would like to test. So, I will send you any results I get with them. I would hate to say that's a limitation in some ATMEL chips. > > Perhaps, the driver/device code for atusb should really be optimized to > > work as a network device to reduce RTTs and allow for better throughput. > > USB throughput isn't that much of an issue, given that the highest > over-the-air data rate is 250 kbps (standard) 2 Mbps (non-standard) > and the hightest data rate for buffer access is 8 Mbps. But the 1 ms > wait per control transfer is a killer :-( > Yes. But, then, this limit will not only make latency suck, but also the throughput. That's a similar problem we can show comparing TFTP and TCP handling of ACK's. If you need, let's say, 4 control transfers to send a package, and you need to wait 1ms between transfers, then, throughput will be a problem. It already is, since 64 bytes per 1ms frame will only let you get, at best, next to 256kbps. > > Besides, what wMaxPacket are you using for the control endpoint? > > I have bMaxPacketSize0 == 64. > > Thanks, > - Werner > Regards, Cascardo.
signature.asc
Description: Digital signature
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
