That's great to hear. I take it this is HT20? I believe you can get
40-60 Mb/s @ MCS15 w/o AMPDU and 80-100 Mb/s w/ AMPDU. In HT40 I've
gotten 160-180 Mb/s for TCP netperf (5GHz) and 220+ Mb/s for
unidirectional streams (netperf -t UDP_STREAM). Note that once you get
to these higher rates things like TCP window sizes become important and
doing things like TSO in s/w can give noticeable speed boosts.
Sam
Alexander Egorenkov wrote:
Hi,
thanks for your help, I implemented A-MPDU Tx in my Ralink driver now
and it works very good.
I have average Tx rate about 4.5~5 MBytes/s now :-) The Ralink chip that
i have implements the frame queue in hardware so i had only to assign
sequence numbers, set BA window size and MPDU density and it worked,
lucky me :-)
Alex.
On Sun, Jan 31, 2010 at 8:20 PM, Sam Leffler <s...@errno.com
<mailto:s...@errno.com>> wrote:
Alexander Egorenkov wrote:
Why doesn't 802.11 stack assign sequence numbers to A-MPDU frames ?
Because if net80211 does the assignment it may be wrong. As the
comment says, if tx aggregation causes frames to be q'd above the
h/w then by the time they are sent OTA the pre-assigned seq# may be
invalidated by other frames going out ahead of it.
When sequence numbers are not assigned to A-MPDU frames, then BA
doesn't work with my AP.
I tried to assign sequence numbers to A-MPDU frames in my device
driver and then BAs worked
with my AP.
That is what the comment says to do.
And what is meant by aggregation queue ? Where is that queue anf
how do i use it ?
The aggregation q is the mechanism used to hold frames waiting for
additional frames to aggregated into an A-MSDU/A-MPDU. The queue is
typically wherever the aggregation work is done. Some devices do
this in h/w, others require the host handle this. When done in the
host it can be done in the driver or above. The intent has always
been to have net80211 implement tx aggregation that a driver can
fallback on but I never did the work. All the 11n drivers I've done
have either handled tx aggregation in h/w or in the driver.
Thanks.
On Sun, Jan 31, 2010 at 4:43 AM, Sam Leffler <s...@errno.com
<mailto:s...@errno.com> <mailto:s...@errno.com
<mailto:s...@errno.com>>> wrote:
Alexander Egorenkov wrote:
Sorry, i posted the wrong comment.
Here is the comment which i don't understand:
/*
* NB: don't assign a sequence # to potential
* aggregates; we expect this happens at the
* point the frame comes off any aggregation q
* as otherwise we may introduce holes in the
* BA sequence space and/or make window accouting
* more difficult.
*
* XXX may want to control this with a driver
* capability; this may also change when we pull
* aggregation up into net80211
*/
Thanks.
What is unclear?
Sam
On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov <
egore...@googlemail.com <mailto:egore...@googlemail.com>
<mailto:egore...@googlemail.com
<mailto:egore...@googlemail.com>>> wrote:
Hi,
i'm implementing a device driver for a 802.11n NIC under
FreeBSD 8
und experimented with A-MPDU transmission. I looked into
net80211 code
and there is some code which implements this feature
but it
worked not very
well for me.
I noticed e.g. that sequence numbers are not assigned to
A-MPDU frames
and found this comment in file ieee80211_output.c :
/*
* Check if A-MPDU tx aggregation is setup or
if we
* should try to enable it. The sta must be
associated
* with HT and A-MPDU enabled for use. When
the policy
* routine decides we should enable A-MPDU we
issue an
* ADDBA request and wait for a reply. The
frame being
* encapsulated will go out w/o using A-MPDU,
or possibly
* it might be collected by the driver and
held/retransmit.
* The default ic_ampdu_enable routine handles
staggering
* ADDBA requests in case the receiver NAK's
us or we are
* otherwise unable to establish a BA stream.
*/
Can somebody elaborate this description to me please.
Thanks.
ALex.
_______________________________________________
freebsd-net@freebsd.org <mailto:freebsd-net@freebsd.org>
<mailto:freebsd-net@freebsd.org
<mailto:freebsd-net@freebsd.org>> mailing
list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscr...@freebsd.org
<mailto:freebsd-net-unsubscr...@freebsd.org>
<mailto:freebsd-net-unsubscr...@freebsd.org
<mailto:freebsd-net-unsubscr...@freebsd.org>>"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
