Subject: Re: [manet] transmission failure info from 802.11 cards

From: "Barbara Hughes" <[email-masked]>
Date: Fri, 2 Apr 2004 09:57:28 +0100

A related question.
I am particularly interested in Lucent Orinoco Gold cards where the
orinoco_xmit() submits the packet to the queue and
__orinoco_ev_tx() occurs when the packet transmission occurs.
Is there a known upper bound on the time a packet spends in the queue prior
to transmission, i.e. the time between the xmit placing in
the queue and the interrupt trigger to ev_tx?

Any thoughts much appreciated.
Barbara

----- Original Message ----- 
From: "David Young" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 01, 2004 10:49 PM
Subject: Re: [manet] transmission failure info from 802.11 cards

> On Thu, Apr 01, 2004 at 04:26:03PM +0200, Christian Tschudin wrote:
> > On Thu, 1 Apr 2004, Sukanta K. Hazra wrote:
> >
> > > ----- Original Message -----
> > > From: "Christian Tschudin <[email-masked]>"
> > > Date: Thu, 01 Apr, 2004 20:15 SGT
> > > Subject: Re: [manet] transmission failure info from 802.11 cards
> > >
> > > > The problem is with checking the counters on a per-packet basis,
> > > > the /proc/driver/aironet interface is too coarse. At least this
> > > > indicates that the data would be available. Next thing to know
> > > > whether you need to poll the card or not.
> > > >
> > > >   And it's also with the queueing inside the kernel i.e., to
associate
> > > > failed and successful transmissions with single packets still
sitting
> > > > somewhere in a buffer. Needs explicit signaling too.
> > > >
> > > > christian.
> > >
> > > The airo_start_xmit function in the airo driver returns SUCCESS or
> > > ERROR, that can give an indication whether the transmission was
> > > successful or not. You could modify the appropriate functions in the
> > > kernel code to make use of that indication.
> > >
> > > At the least, what this proves is that its possible to get indication
> > > from the card regarding success or failure of transmission. You can
> > > proceed from there, to incorporate it in the routing protocol.
> >
> > not really. I browsed through the code only quickly, but it seems clear
> > that airo_start_xmit() only tells you whether the driver could QUEUE the
> > packet or not. Whether the packet was actually sent or not, you will not
> > learn from that. Nor do you know when to look again at the counter
> > for detecting the packet's fate. It's an asynchronous world down there.
> >
>
> The Aironet firmware is capable of indicating transmit success or failure
> for each packet using an interrupt. It is possible with Lucent/Prism
> firmware for the driver to apply a label to each packet, so that it can
> be recognized when the interrupt comes. It *appears* that it is the same
> for Aironet.
>
> It is clear that virtually all 802.11 devices can indicate transmit
> success/failure for individual packets. It's not clear what the API
> will look like, even in the abstract, that the different layers of the
> protocol stack will use to get individual success/failure indications.
>
> Dave
>
> -- 
> David Young             OJC Technologies
> [email-masked]      Urbana, IL * (217) 278-3933
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
>

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: David Young <[email-masked]>
Date: Sat, 3 Apr 2004 01:32:40 -0600

> the queue and the interrupt trigger to ev_tx?

There might be a known lower bound equal to the firmware overhead.
An upper bound .  ev_tx is not triggered until the firmware knows the
transmission status, so the upper bound will be connected to the upper
bounds on contention, retransmissions, ack overhead, and (optional)
rts/cts or fragmentation overhead.  That said, I believe there is a
firmware register that lets you enforce a transmit lifetime.

Dave

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 5 Apr 2004 09:45:59 -0700

I performed some tests evaluating the latency of link layer feedback
using the host ap driver, a netgear MA401RA card and iwevent. I found
the lower bound (average) to be around 11 ms with a single transmitter.

Ian Chakeres

If you are interested in reading the paper, please contact me, it is
currently pending publication.

>Barbara Hughes wrote: