Thadeu Lima de Souza Cascardo wrote: > UPDATE: I've done some tests using your program. It's missing the > usbopen.h header,
Ah, that would have been in ../include/, along with usbopen.c in ../lib/ > Doing the transfer to the Linux root hub (which only > uses software for the GET_CONFIGURATION request, no HCD involved), and > it took 0.002ms per control transfer. Yes, the local hub is nice and quick ;-) > My ATMEGA8U2 LUFA stack got similar results in full-speed. Thanks for confirming the results ! I think I figured out now what's happening. It's the UHCI design [1] (EHCI is probably just a continuation of the same concept). UHCI works like this: when a frame begins, it processes the list of transfers queued for the frame. If there's time left in the frame after finishing the list of tasks, the controller goes idle until the next frame. E.g., from page 29, 3.4.1.3, item 10: "If the Queue [ end has been reached ], The Host Controller idles until the 1 ms frame timer expires. This is exactly what usbperf reports for directly attached devices, too: there's not only a spacing of one frame between requests but each of them also seem to "run" for one frame/microframe time. Of course, what really happens is that the first request is enqueued, sits ~0-1 ms in the queue until the beginning of the next frame, then gets processed, triggers an interrupt, we handle it and enqueue the next request. By then, the controller has already seen the end of the queue and idles until the next frame. This is also consistent with the my crystal frequency measurements, where I got faster convergence when I assumed the counter in the AVR was ready near the end of the request period than near the beginning. I found that a bit surprising. Now I know why it is so ;-) [1] http://download.intel.com/technology/usb/UHCI11D.pdf Trying to race the controller for accessing the pointer to the next entry is probably a losing proposition. We might be able to pipeline requests, but since there are a lot of reads (with data dependencies) in the mix, this would only mean a small improvement. > Using bulk transfers instead of control transfers. Perhaps, doing this > only change may solve a lot. Hmm, that alone probably doesn't help, since we'd still be caught in the per frame schedule. Seems that the only real solution is to avoid having many small requests and to let atusb handle a larger task in each transfer. - Werner _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
