performance in adhoc mode

[Adrian Chadd]

Ok, long_retry means that the hardware had to try more times to get
the frame out.

Either it's picking too high a rate, or the ACKs can't be heard.

I wonder what changes in the MAC and driver when we flip on adhoc
mode. I know it changes how the beacon queue is handled, I didn't
think anything else changed..

Can you try forcing a lower rate on both ends (ifconfig wlanX
ucastrate Y) and do your tests?

Please file a PR with this. :)

Thanks!


Adrian


On 29 February 2012 01:51, Johann Hugo <jhugo at meraka.csir.co.za> wrote:
> On Tuesday 28 February 2012 17:50:39 Adrian Chadd wrote:
>
>> I've not looked into adhoc _at all_.
>
>
>
> please_do
>
>
>
>>
>
>> I'd start by looking at the behaviour of the rate control code - do
>
>> 'sysctl dev.ath.X sample_stats=1' after you've done some traffic and
>
>> check dmesg.
>
>>
>
>> Just ensure that the same rates are being used and the error rate is low.
>
>>
>
>
>
> The rates differ a bit and also some of the dev.ath.0 sysctl's.
> dev.ath.0.stats.ast_tx_longretry is more than double in adhoc mode.
>
>
>
> Johann
>
>