Steve Glass wrote:
I'm considering using the USRP together with the 802.11 stack to
prototype some 802.11 MAC layer changes. I'm sending from an 11b card
at the base rate to my USRP/RFX2400.
One shortcoming at present is that the code doesn't generate ACKs for
received frames. There are quite strict timing requirements for ACK
generation: for 11b at the base rate the ACK should be sent within a
period measured in microseconds. I can increase the ACKTimeout but
apparently there's a hard limit in my 802.11 equipment at 746us beyond
which I will incur a rentransmission.
I'm prepared to wade into the code but its a fool's errand if the
latencies will be too high to ACK within a few hundred microseconds.
I'm worried that the block latencies and USB round-trip delay would
seem to make this impossible. If anyone here can give me an informed
opinion then I'll be really happy. So, does anyone know if it is it
possible to generate an ACK within 700us or so of receiving a data frame?
Hi Steve,
One trick for testing if you can't get the latency down - use a second
802.11b radio card and use the same MAC address in your gnuradio
implementation.
The 802.11b radio will automatically ACK every packet for its MAC address.
If the gnuradio based MAC has the same MAC address then you can then use
the gnuradio for transmission and reception of real data without needing
to transmit ACK packets.
The catch - if the gnuradio misses a packet you don't have the option of
not acking so it is sent again.
Nick
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
