Re: [ath] Degraded throughput - adhoc mode

2012-12-12 Thread Johann Hugo
On Sunday, December 09, 2012 04:18:45 PM Adrian Chadd wrote:
 Ok, I've just taught the aggressive mode logic about IBSS. It's pretty
 dirty - I may cop some hate for enabling aggressive mode for IBSS as
 each IBSS node doesn't know about the overall voice/video data rates.
 That's how it works in AP mode - the AP tracks the traffic it is
 sending/receiving and changes its configuration based on that. It
 can't take into account overlapping BSSes.
 
 In any case, can you just try that out in your lab and let me know how it
 goes?

Great, I'm now getting the same throughput for ADHOC and AP/STA mode.

mesh-2870:~ # uname -a
FreeBSD mesh-2870 10.0-CURRENT FreeBSD 10.0-CURRENT #15: Wed Dec 12 11:38:06

wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 00:02:6f:41:19:09
inet6 fe80::202:6fff:fe41:1909%wlan0 prefixlen 64 scopeid 0x7 
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
media: IEEE 802.11 Wireless Ethernet autoselect mode 11a adhoc
status: running
ssid mesh channel 128 (5640 MHz 11a) bssid 02:88:99:fe:ca:00
regdomain NONE country ZA ecm authmode OPEN privacy OFF txpower 24
mcastrate 6 mgmtrate 6 scanvalid 60 wme burst

mesh-2870:~ # ifconfig wlan0 list wme
AC_BE cwmin  4 cwmax 10 aifs  3 txopLimit   0
AC_BK cwmin  4 cwmax 10 aifs  7 txopLimit   0
AC_VI cwmin  3 cwmax  4 aifs  2 txopLimit  94
AC_VO cwmin  2 cwmax  3 aifs  2 txopLimit  47
mesh-2870:~ #  ifconfig wlan0 wme aifs be 2 cwmin be 4 cwmax be 10 txoplimit 
be 64

mesh-2870:~ # iperf -V -c fe80::202:6fff:fe41:1908%wlan0

Client connecting to fe80::202:6fff:fe41:1908%wlan0, TCP port 5001
TCP window size: 40.1 KByte (default)

[  3] local fe80::202:6fff:fe41:1909 port 60833 connected with 
fe80::202:6fff:fe41:1908 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  34.4 MBytes  28.8 Mbits/sec

mesh-2870:~ # iperf -V -c fe80::202:6fff:fe41:1908%wlan0

Client connecting to fe80::202:6fff:fe41:1908%wlan0, TCP port 5001
TCP window size: 40.1 KByte (default)

[  3] local fe80::202:6fff:fe41:1909 port 41099 connected with 
fe80::202:6fff:fe41:1908 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  34.6 MBytes  29.0 Mbits/sec

Did you manage to figure out why the wme setting changes back when the 
interface if taken down/up ?

Johann
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org


Re: [ath] Degraded throughput - adhoc mode

2012-12-09 Thread Adrian Chadd
On 18 May 2012 02:33, Johann Hugo jh...@meraka.csir.co.za wrote:
 Hi

 We have an outdoor wifi mesh network with various atheros adapters configured
 in adhoc mode. (FreeBSD-9)

Hi,

Please try -HEAD. I _think_ I've handled the WME configuration side of
things right in IBSS mode.

The problem with IBSS is that nodes are automatically created whenever
frames are received; then a beacon frame will update the current
configuration. So if you create an IBSS STA node based on receiving a
data frame (and not a beacon) then it may create things with no WME
config, and it'll just default to the default (non-aggressive mode)
WME parameters.

Now, my -HEAD patch may actually be incorrect, because it changes the
global WME config for that particular device; there's no real per-node
WME configuration unfortunately. I don't have a very large IBSS setup
to test how this works in practice and I will admit I haven't sat down
and really tried to understand / implement IBSS stuff in any useful
fashion. But it did come up and it did parse the WME IE correctly.

So just make sure you configure the WMM parameters on both sides to
have aggressive BE parameters (aifs 2, cwmin4, cwmax 10, txop 64) and
then reassociate.

I may end up reverting the WME IE parsing for now and just requiring
people statically configure the WME parameters on each node. I'll
experiment some more and then commit it to -HEAD. But the ath IE
parsing works and I now see fast-frames used in adhoc mode, which will
bump the throughput up a bit on the non-11n NICs.



Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org


Re: [ath] Degraded throughput - adhoc mode

2012-12-09 Thread Adrian Chadd
Hm, there's some odd behaviour.

If I configure the WME parameters before I bring the interface up,
bringing it up overrides the parameters.

I'll do some further digging in a few minutes. Something tells me the
aggressive mode logic is overriding the configured WME parameters.

G!


Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org


Re: [ath] Degraded throughput - adhoc mode

2012-12-09 Thread Adrian Chadd
Ok, I've just taught the aggressive mode logic about IBSS. It's pretty
dirty - I may cop some hate for enabling aggressive mode for IBSS as
each IBSS node doesn't know about the overall voice/video data rates.
That's how it works in AP mode - the AP tracks the traffic _it_ is
sending/receiving and changes its configuration based on that. It
can't take into account overlapping BSSes.

In any case, can you just try that out in your lab and let me know how it goes?

It's easy enough for me to disable the aggressive mode programming for
IBSS mode once we better understand what's going on with the IBSS +
WME programming.

Thanks for being so patient with this!


Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org