All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH v2] ath9k: Remove ath9k rate control
Date: Thu, 06 Feb 2014 07:59:17 -0800	[thread overview]
Message-ID: <52F3B155.6010308@candelatech.com> (raw)
In-Reply-To: <1391662375-28781-1-git-send-email-sujith@msujith.org>

On 02/05/2014 08:52 PM, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> There is no benefit in retaining the legacy rate control module
> in the driver codebase.
>
> It is known to be buggy and has less than optimal performance
> in real-world environments compared with minstrel. The only
> reason that it was kept when we made the switch to minstrel
> as default was that it showed higher throughput numbers in a
> clean/ideal environment.
>
> This is no longer the case and minstrel can push ath9k to
> the same throughput levels. In TCP, with 3-stream cards, more than
> 295 Mbps can be obtained in open air, with 2-stream cards,
> 210 Mbps is easily reached. To test performance issues,
> instead of using a broken rate control module, it is better
> to use the fixed-rate interface provided by mac80211 anyway.

Can you let us know the details on how your set up that TCP
traffic?  For instance, number of streams, write size, socket
buffer sizes, etc?  Upload, download, or are both similar
throughput in your testing?

I find that those settings influence throughput a great deal,
and I have not yet been able to reach 295Mbps of TCP throughput
in our testing w/out hacking the tcp-ack logic to increase ack delays.

Thanks,
Ben


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

WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Sujith Manoharan <sujith@msujith.org>,
	John Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [PATCH v2] ath9k: Remove ath9k rate control
Date: Thu, 06 Feb 2014 07:59:17 -0800	[thread overview]
Message-ID: <52F3B155.6010308@candelatech.com> (raw)
In-Reply-To: <1391662375-28781-1-git-send-email-sujith@msujith.org>

On 02/05/2014 08:52 PM, Sujith Manoharan wrote:
> From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
>
> There is no benefit in retaining the legacy rate control module
> in the driver codebase.
>
> It is known to be buggy and has less than optimal performance
> in real-world environments compared with minstrel. The only
> reason that it was kept when we made the switch to minstrel
> as default was that it showed higher throughput numbers in a
> clean/ideal environment.
>
> This is no longer the case and minstrel can push ath9k to
> the same throughput levels. In TCP, with 3-stream cards, more than
> 295 Mbps can be obtained in open air, with 2-stream cards,
> 210 Mbps is easily reached. To test performance issues,
> instead of using a broken rate control module, it is better
> to use the fixed-rate interface provided by mac80211 anyway.

Can you let us know the details on how your set up that TCP
traffic?  For instance, number of streams, write size, socket
buffer sizes, etc?  Upload, download, or are both similar
throughput in your testing?

I find that those settings influence throughput a great deal,
and I have not yet been able to reach 295Mbps of TCP throughput
in our testing w/out hacking the tcp-ack logic to increase ack delays.

Thanks,
Ben


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


  reply	other threads:[~2014-02-06 15:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06  4:52 [ath9k-devel] [PATCH v2] ath9k: Remove ath9k rate control Sujith Manoharan
2014-02-06  4:52 ` Sujith Manoharan
2014-02-06 15:59 ` Ben Greear [this message]
2014-02-06 15:59   ` Ben Greear
2014-02-06 16:23   ` [ath9k-devel] " Sujith Manoharan
2014-02-06 16:23     ` Sujith Manoharan
2014-02-06 17:10     ` [ath9k-devel] " Ben Greear
2014-02-06 17:10       ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F3B155.6010308@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.