From owner-freebsd-net@FreeBSD.ORG Sun Feb 14 19:57:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1351065676 for ; Sun, 14 Feb 2010 19:57:54 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id B46548FC19 for ; Sun, 14 Feb 2010 19:57:54 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o1EJvrUu078436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2010 11:57:53 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4B7855C1.3090101@errno.com> Date: Sun, 14 Feb 2010 11:57:53 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexander Egorenkov References: <2d3b7e441001271104j14836df4j14428d34561dead1@mail.gmail.com> <2d3b7e441001271108p2a40dbbbwaa6af9679d61ab@mail.gmail.com> <4B64FC76.5060506@errno.com> <2d3b7e441001302334t5baa1102pdd1ee0309d32c2fd@mail.gmail.com> <4B65D816.5010709@errno.com> <2d3b7e441002140530m176ccf5csd120f1029263413b@mail.gmail.com> In-Reply-To: <2d3b7e441002140530m176ccf5csd120f1029263413b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: A-MPDU transmission in net80211 on FreeBSD 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2010 19:57:55 -0000 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 > 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 >> 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 < > egorenar@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 > > mailing > > list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > > >" > > > > > >