ben-wpan: pings between atben and atusb

Thadeu Lima de Souza Cascardo cascardo at holoscopio.com
Sun Jul 10 10:48:03 EDT 2011


On Sun, Jul 10, 2011 at 12:19:11AM -0300, Werner Almesberger wrote:
> Thadeu Lima de Souza Cascardo wrote:
> > I did some testing in here.
> 
> Thanks a lot ! I did some experiments too. Here's the utility
> I wrote for them:
> http://projects.qi-hardware.com/index.php/p/ben-wpan/source/tree/master/tools/usbperf/
> 
> Some results:
> 
> Device		Direct/hub	Speed	Time per control transfer (ms)
> ---------------	---------------	-------	------------------------------
> Mouse		direct		Low	4.002
> Keyboard	direct		Full	1.003
> BT dongle	direct		Full	1.012
> Ben		hub (HS)	High	0.128
> Printer		direct		Full	1.018
> Oscilloscope	hub (HS)	Full	0.253
> IDBG		hub (HS)	Full	0.250
> Hub		direct		High	0.254
> ATUSB (SiLabs)	direct		Full	0.999
> ATUSB (SiLabs)	hub (HS)	Full	0.210
> ATUSB (Atmel)	direct		Full	1.001
> ATUSB (Atmel)	hub (HS)	Full	0.253
> 
> So the pattern seems to be as follows:
> - high-speed devices handle one control transfer per microframe
> - for full-speed devices, it depends on how they're connected:
>   - directly (using the UHCI), one control transfer per frame
>   - via a high-speed hub, ~2 microframes per control transfer
> 
> This would be consistent with the pattern you saw, if a hub was
> involved in your experiments.
> 

Not an external hub, but as I told you, it was using EHCI. But there is
two integrated "rate matching" hubs that should do the work of
communicating with full and low speed devices. They are not Linux root
hubs, but Intel root hubs. So it makes more sense. I am still a little
skeptical about the results though. That could be a Linux limitation or
perhaps a limitation when using libusb or with the user interface to
send control messages. Although you are encountering the same problem
using a kernel driver with usb_fill_control_urb, so it should be a
bandwidth allocation problem.

UPDATE: I've done some tests using your program. It's missing the
usbopen.h header, so I used some of my code to find devices with a given
vendor:product ID. 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. So it's not a problem with the
user interface and is more likely a problem with the host controller or
the USB protocol itself. It can still be in Linux bandwidth allocation
when it goes through HCD code.

> > Unfortunately, I have only EHCI in here right now.
> 
> At least a few years ago, EHCI and Full-Speed controller(s) worked
> together as follows: if a port was Low-Speed or Full-Speed, the "old"
> controller (UHCI, etc.) would take care of it. If the port was High-
> Speed, the UHCI's root hub would detach from the port and EHCI would
> handle it.
> 

I thought that was the case here. I would even try a high-speed device
and force it into full-speed by removing the ehci_hcd driver. But, then,
I realized that was no uhci_hcd loaded and when I loaded it and unloaded
the ehci driver, I could not enumerate any device. I think they are
droping UHCI altogether nowadays.

> So each High-Speed capable port had access to an UHCI (or similar)
> plus an EHCI, each via the respective root hub.
> 
> > I get you are using an ATMEGA32U2, right?
> 
> Yes, with my own USB stack. The IDBG and the "ATUSB (SiLabs)" above
> use an C8051F326 with an earlier version of my stack.
> 

My ATMEGA8U2 LUFA stack got similar results in full-speed.

> > Yes. But, then, this limit will not only make latency suck, but also the
> > throughput.
> 
> Yes, unless we can move a lot of data per transfer. Unfortunately,
> this currently isn't the case. (We get 1-2 transfers per register
> access, about 23 in total for one in-RX -> TX -> back-to-RX cycle.)
> 
> Seems that, unless we find a way to get the host controll to do more
> than one control transfer per (micro-)frame, I have to rethink the
> whole architecture :-(
> 
> Any ideas ?
> 

Using bulk transfers instead of control transfers. Perhaps, doing this
only change may solve a lot. Anyway, if it does, I still think that
should be a Linux problem in its bandwidth allocation or some stupid
thing in the host controllers implementation that we can't fix
ourselves.

> Thanks,
> - Werner
> 

Best regards,
Cascardo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20110710/5b5447e3/attachment.pgp>


More information about the discussion mailing list


interactive