So the 30 second version:
* the maximum aggregation size in 802.11n is 65536 bytes, including
the between-frame delimiters;
* mpdu density defines how big those delimiters are - they're
calculated either in bytes or as a function of the currently selected
rate and duration, which ends up being a set of bytes anyway;
* some hardware may require extra delimiter time between frames to
"reset" internal frame processing between MPDUs. The atheros hardware,
for examples, sets the default mpdu density to 8 microseconds to allow
the encryption hardware to reset fully. It's only needed at the higher
rates, but I've not sat down and totally mapped out what behaviour is
there so I do it for all rates;
* .. and later atheros hardware has a minimum per-MPDU timing and
delimiters are added to that to "pad" out a frame to a minimum
duration in microseconds. Again, to meet timing requirements in the
* bawinsize is negotiated during ADDBA negotiation. The maximum window
size is 64 frames but devices may negotiate smaller window sizes if
* some hardware / drivers may limit the size of aggregates anyway -
eg, the ath(4) aggregation code limits the per-AMPDU size to 32 frames
even if the window is 64 frames. This is done to limit the effects of
poor reception. Again, I could do a smarter job of it in ideal(er)
situations but I've been focusing on other things.
On 31 January 2013 16:48, Ramanujan Seshadri <ksramanu...@gmail.com> wrote:
> I am testing the driver code witht he ralink nic. Yes the frame
> aggregation works, since i get higher throughput. I am actually tryign to
> know how many frames (MPDU's) are aggregated each time in an AMPDU.
> Regarding the MPDU density - i was wondering how it should affect the Frame
> aggregation. Since MPDU density is the time duration between each MPDU sent
> within the AMPDU. So, how does this matter to the hardware for aggregating
> the number of frames. It just sends MPDU's with the set interval.
> The other two limits make sense, the BAWinSize and the MAX_LEN_CFG.
> On Wed, Jan 30, 2013 at 5:45 PM, PseudoCylon <moonlightak...@yahoo.ca>wrote:
>> On Wed, Jan 30, 2013 at 1:20 PM, Ramanujan Seshadri
>> <ksramanu...@gmail.com> wrote:
>> > Thank you. I also wanted to know the function where the Block ACK Window
>> > will be decided. is it decided during the ADDBA session establishment or
>> > does it change dynamically.
>> The hardware will aggregate packets until any of following limits hit max
>> * rt2860_txwi.flags
>> 000 == no restriction
>> 001 == 1/4 us
>> 010 == 1/2 us
>> 111 == 16 us
>> * rt2860_txwi.xflags
>> RT2860_TX_BAWINSIZE_SHIFT (frame count)
>> * RT2860_MAX_LEN_CFG bit 12:13
>> 00 == 8k bytes
>> 01 == 16k
>> 10 == 32k
>> 11 == 64k
>> At a quick look, none of them is set in current code. Also,
>> RT2860_TX_AMPDU flag need to be set to make the h/w aggregate packets.
>> How is ampdu working on ral(4)? I cannot test because I do not have
>> any ral(4) nic (only have run(4) nics).
>> > On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon <moonlightak...@yahoo.ca>
>> > wrote:
>> >> > Message: 6
>> >> > Date: Thu, 24 Jan 2013 12:23:55 -0500
>> >> > From: Ramanujan Seshadri <ksramanu...@gmail.com>
>> >> > To: freebsd-...@freebsd.org
>> >> > Subject: Block ACK in Ralink RT2860
>> >> > Message-ID:
>> >> >
>> >> > <CAK=c58kya80kgvqenhj8xekmkkdnhnmbqkzoykq-k6r_7v4...@mail.gmail.com>
>> >> > Content-Type: text/plain; charset=ISO-8859-1
>> >> >
>> >> > Hi all,
>> >> > I am trying to read the contents of block ack's in a Ralink RT2860
>> >> > driver.
>> >> > Can you please help me to know which function i should be looking
>> into ?
>> >> At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag
>> >> at
>> >> http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559
>> >> Then, the diver should receive BA packets, and you can read them.
>> >> AK
> freebsd-...@freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"