kern/175227: commit references a PR

[Артём Морозов]

---------- Forwarded message ----------
From: Adrian Chadd <adrian at freebsd.org>
Date: 2013/2/1
Subject: Re: Block ACK in Ralink RT2860
To: Ramanujan Seshadri <ksramanujan at gmail.com>
Cc: FreeBSD Net <freebsd-net at freebsd.org>, PseudoCylon <
moonlightakkiy at yahoo.ca>, freebsd-wireless at freebsd.org


Hi,

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
chip;
* bawinsize is negotiated during ADDBA negotiation. The maximum window
size is 64 frames but devices may negotiate smaller window sizes if
they like;
* 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.

HTH,



adrian


On 31 January 2013 16:48, Ramanujan Seshadri <ksramanujan at 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.
>
> Ram
>
> On Wed, Jan 30, 2013 at 5:45 PM, PseudoCylon <moonlightakkiy at yahoo.ca
>wrote:
>
>> On Wed, Jan 30, 2013 at 1:20 PM, Ramanujan Seshadri
>> <ksramanujan at 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
>> http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L782
>> * rt2860_txwi.flags
>>         RT2860_TX_MPDU_DSITY_SHIFT
>>         000 == no restriction
>>         001 == 1/4 us
>>         010 == 1/2 us
>>         ...
>>         111 == 16 us
>> * rt2860_txwi.xflags
>>         RT2860_TX_BAWINSIZE_SHIFT (frame count)
>>
>> http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L93
>> * 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).
>>
>>
>> AK
>>
>> >
>> >
>> > On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon <moonlightakkiy at yahoo.ca>
>> > wrote:
>> >>
>> >> > Message: 6
>> >> > Date: Thu, 24 Jan 2013 12:23:55 -0500
>> >> > From: Ramanujan Seshadri <ksramanujan at gmail.com>
>> >> > To: freebsd-net at freebsd.org
>> >> > Subject: Block ACK in Ralink RT2860
>> >> > Message-ID:
>> >> >
>> >> > <CAK=C58KyA80kgVqenHj8xEkmkKDNHnmbQkZoyKQ-K6r_7V4GGA at 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-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
_______________________________________________
freebsd-wireless at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscribe at freebsd.org"