ben-wpan: pings between atben and atusb

Thadeu Lima de Souza Cascardo cascardo at
Fri Jul 8 07:39:56 EDT 2011

On Fri, Jul 08, 2011 at 12:59:51AM -0300, Werner Almesberger wrote:
> Some news from the ben-wpan driver front: Stefan Schmidt did some
> great work on the atusb driver, based on Richard Sharpe's skeleton
> driver. I then killed a few remaining bugs.
> All the kernel code is in the ben-wpan branch of
> Now I got some clean pings between a Ben equipped with atben and a
> PC equipped with atusb, both running dirtpan:
>   100 packets transmitted, 100 received, 0% packet loss, time 99524ms
>   rtt min/avg/max/mdev = 152.010/158.962/176.015/5.154 ms
> The round-trip-time is quite long. This it at least in part
> because it seems that I can get only one USB control transfer per
> 1 ms frame, which means that the very best-case timing for a
> send-receive turnaround (on one end) is 23 ms. Sometimes, a control
> transfer also takes longer.
> A ping over dirtpan exchanges a total of four frames: the Echo
> Request, an ACK generated by dirtpan, the Echo Reply, and finally
> an ACK for the Echo Reply.
> I don't see anything in the USB specification that would require
> control transfers to be so slow, but I haven't been able to find
> any mechanism in the kernel to make them faster either. Ideas
> welcome :-)

Hello, Werner.

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. In the
case of control transfers, that means the SETUP transaction, DATA
transactions and STATUS transaction. Another SETUP will only be sent in
the next frame and in a best effort frame allocation. That is, the frame
may be allocated by an interrupt requesting a frame every 10ms, for

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.
Besides, what wMaxPacket are you using for the control endpoint? A
smaller wMaxPacket (ATMEGA32U2 should support 64 bytes for control
endpoints, the maximum allowed for full speed control endpoints) will
require more DATA transactions, which will include more overhead, reduce
the throughput, but also increase the latency.


> dirtpan has relatively short timeouts. To make it work in this
> scenario, the timeouts have to be enlarged, see the patch below.
> One additional complication is that atben turns around faster
> than atusb, so the ACK for a frame sent from atusb to atben is
> usually lost, and it takes the two a while to resolve the problem.
> As a dirty work-around, I just make dirtpan's send_ack wait until
> we can be reasonably sure the peer has turned around.
> The long turn-around time also effectively breaks any serious use
> of TCP (SSH or such), probably because of TCP ACK loss.
> If there's no easy solution for getting control transfers handled
> more quickly, then it will be necessary to move more of the
> send/receive logic from the kernel driver into the firmware.
> - Werner
> ---------------------------------- cut here -----------------------------------
> diff --git a/tools/dirtpan/dirtpan.c b/tools/dirtpan/dirtpan.c
> index 5e6d200..22a20fa 100644
> --- a/tools/dirtpan/dirtpan.c
> +++ b/tools/dirtpan/dirtpan.c
> @@ -61,8 +61,8 @@ enum packet_type {
>  #define	MAX_FRAG	(127-11-2-1)	/* MHDR, FCS, control byte */
>  #define	MAX_PACKET	2000
>  #define	MAX_TRIES	5
> -#define	T_REASS_MS	200
> -#define	T_ACK_MS	50
> +#define	T_REASS_MS	500
> +#define	T_ACK_MS	100
>  static struct {
> @@ -323,6 +323,7 @@ static void send_ack(int seq)
>  {
>  	uint8_t ack = pt_ack | (seq ? SEQ : 0);
> +usleep(4000);
>  	send_frame(&ack, 1);
>  	stats.tx_ack++;
>  }
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at
> Subscribe or Unsubscribe:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

More information about the discussion mailing list