2014-04-02 08:53:50

by Cedric DEBARGE

[permalink] [raw]
Subject: Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

Hi Bob and Dennis,

Thanks for your answer.

>On 3/28/2014 8:22 AM, Bob Copeland wrote:
>> Interesting -- I tried this exact thing once before, but got mixed
>> results in my testing.
>>
>> Can you share your testing strategy?

Here is my testing summary :

__ _ |_|_| |_|_| __ _
[__]|=|--->[____?] [____?]<---[__]|=|
/::/|_| /::/|_|
.------------------.
Mesh portal B | Office building | Mesh portal A
Fixed location | 15m x 40m | Fixed location
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
'------------------'
__ _ |_|_|
[__]|=|-->[____?]
/::/|_|

Mesh portal C
Fixed location

All points are mesh portals. Signal levels are :
- around -60dBm between A and B --> metric = 152
- around -60dBm between B and C --> metric = 152
- around -80dBm between A and C --> metric >> 2*152

All point are using openwrt with compat-wireless v2013-04-16.

A runs an iperf server and C an iperf client (see iperf parameters below)
iperf -c mesh_point_A_ip -b10M -i10 -t9999

During the test I monitored both mpath and minstrel stats on mesh portal C:
- mpath (iw wlan0 mpath dump)
- minstrel stats (rc_stats files for stations B and A)

Without my patch, I get 10 or more mpath changes per minute. When I apply it,
the number of changes drops to 1 or 2 per minute. In this particular case, it
seems to be an improvement but I haven't tested this patch in another scenario.
In order to get a fully stable link, I have to set a rssi threshold in order to
prevent C to establish any plink with A (and do the same on point A).

C?dric DEBARGE
ACKSYS R&D dpt.