linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ath9k rate control statistics not updated for UDP
@ 2012-06-11 13:37 Antonis Hadjiantonis
  2012-06-11 17:52 ` Ben Greear
  0 siblings, 1 reply; 3+ messages in thread
From: Antonis Hadjiantonis @ 2012-06-11 13:37 UTC (permalink / raw)
  To: linux-wireless

I am using iperf to test rate control algorithms (use default:minstrel_ht) on an
ath9k device (WRT160NL OpenWRT Backfire 10.3.1 r29592). 
When I use UDP traffic over an 802.11g connection, the rcstat file is not
updated. Not sure if the rate control algoritmh works during the process.
If I use TCP traffic, rcstat is updated and statistics/rate change accordingly.

Is this the correct behaviour of minstrel RC? I went through documentation
regarding MRR and retransmission bounds but wasn't able to figure it out. Any
one noticed something similar?

Thanks in advance,
Antonis


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ath9k rate control statistics not updated for UDP
  2012-06-11 13:37 ath9k rate control statistics not updated for UDP Antonis Hadjiantonis
@ 2012-06-11 17:52 ` Ben Greear
  2012-06-12 10:17   ` Antonis Hadjiantonis
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Greear @ 2012-06-11 17:52 UTC (permalink / raw)
  To: Antonis Hadjiantonis; +Cc: linux-wireless

On 06/11/2012 06:37 AM, Antonis Hadjiantonis wrote:
> I am using iperf to test rate control algorithms (use default:minstrel_ht) on an
> ath9k device (WRT160NL OpenWRT Backfire 10.3.1 r29592).
> When I use UDP traffic over an 802.11g connection, the rcstat file is not
> updated. Not sure if the rate control algoritmh works during the process.
> If I use TCP traffic, rcstat is updated and statistics/rate change accordingly.
>
> Is this the correct behaviour of minstrel RC? I went through documentation
> regarding MRR and retransmission bounds but wasn't able to figure it out. Any
> one noticed something similar?

Your UDP traffic may be completely uni-directional, so no packets
are ever received.  Maybe try setting up a bi-directional traffic
flow?

Ben

>
> Thanks in advance,
> Antonis
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ath9k rate control statistics not updated for UDP
  2012-06-11 17:52 ` Ben Greear
@ 2012-06-12 10:17   ` Antonis Hadjiantonis
  0 siblings, 0 replies; 3+ messages in thread
From: Antonis Hadjiantonis @ 2012-06-12 10:17 UTC (permalink / raw)
  To: linux-wireless


Ben Greear <greearb@...> writes:

> Your UDP traffic may be completely uni-directional, so no packets
> are ever received.  Maybe try setting up a bi-directional traffic
> flow?
> 
> Ben

Thanks Ben, indeed UDP traffic was uni-directional from client to 
server on the wireless AP, so the bidirectional flag did the trick!

Would appreciate some input on a few more questions below:

So, if I got it right, rate control and its statistics refer to 
traffic sent from the AP to stations, i.e. only outgoing/transmitted traffic ?

Also, does this mean that the uplink and downlink rates of a session
 between an AP and a Station are independent?

Finally, is there any way for the AP to control the uplink rate its
 stations use, or is it up to each station to use appropriate RC algorithms? 

Looking forward to your replies,

Thanks
Antonis


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-06-12 10:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-11 13:37 ath9k rate control statistics not updated for UDP Antonis Hadjiantonis
2012-06-11 17:52 ` Ben Greear
2012-06-12 10:17   ` Antonis Hadjiantonis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).