Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Feb 2012 09:48:53 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Johann Hugo <jhugo@meraka.csir.co.za>
Cc:        freebsd-wireless@freebsd.org
Subject:   Re: performance in adhoc mode
Message-ID:  <CAJ-VmonR9P_d%2Bm=Mmf41vH%2BGr5BNrovo8t0hC5c9pspprPaadA@mail.gmail.com>
In-Reply-To: <201202291151.10365.jhugo@meraka.csir.co.za>
References:  <201202281639.05140.jhugo@meraka.csir.co.za> <CAJ-Vmo=5-jwHGa7wRVFU6dgdGdG6Fu3K12WC82Y-yHfP1=3iDA@mail.gmail.com> <201202291151.10365.jhugo@meraka.csir.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonR9P_d%2Bm=Mmf41vH%2BGr5BNrovo8t0hC5c9pspprPaadA>