hi georg!

On Friday 09 May 2008 18:27:48 Georg Lukas wrote:
quoted text
> Hello David,
>
> * David Murray <30179198@student.murdoch.edu.au> [2008-05-08 10:07]:
> > Apologies for bringing up an old thread, but I am trying to disable
> > ACKs in ad-hoc mode. My first attempt at this was to use the iwpriv
> > noackpolicy function.
>
> 802.11e (QoS) and Ad-Hoc mode don't mix well. In the standard
> implementation, MadWifi assumes that no other station supports QoS and
> therefore always uses the standard transmission policy.
>
> I've made a small patch to enable QoS for nodes which announce their QoS
> support in the WME beacon information element. Unfortunately, it seems
> that the BE traffic class with QoS enabled has a lower priority than
> with QoS disabled, so station with this patch have a lower concurrent
> throughput.

is that lower compared to other stations on the same channel which don't use 
QoS or lower compared to not using WME on the same stations? in other words: 
will non-WME stations outperform WME stations? do we have the same situation 
in STA mode or is this only seen in ad-hoc mode?

if it's just the total thruput which goes down a bit i would suggest to commit 
this patch to trunk. actually in any case i would prefer to have WME in 
ad-hoc mode too and not worry so much about a slight loss of thruput - madwifi 
thruput is not so good anyways ;(

also have you tested multiple streams with different WME classes? in this case 
the total thruput of one station goes up.

bruno

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-devel