On Sun, Oct 23, 2016 at 6:57 AM, Björn Smedman wrote:
> Hi all,
>
> I've been thinking about rate control a bit lately. I've written up
> some of my thoughts in a blog post
> (http://www.openias.org/bayesian-wifi-rate-control), but very briefly
It is nice to see some newer thinking here.
> put I
On Tue, Jun 21, 2016 at 2:41 AM, Jouni Malinen wrote:
> On Tue, Jun 21, 2016 at 11:02:20AM +1000, Julian Calaby wrote:
>> I've only done this work as I hate to see people's efforts go to
>> waste and I feel that there's enough roadblocks in the way of
>> actually using this functionality that casu
>> struct ath_atx_tid {
>> struct list_head list;
>> + struct sk_buff_head i_q;
> Do we really need a third queue here? Instead of adding yet another
> layer of queueing here, I think we should even get rid of buf_q.
Less queues, more filling!
>
> Channel context based queue handling c
For the record, michal's lastest patchset for the ath10k is here:
https://github.com/kazikcz/linux/tree/fqmac-v5
which includes the reworked codel.h support (which also landed in
net-next as of april 22) (no, haven't tried it yet, I'm only a day
back from vacation)
... but it would pay to levera
On Sun, Jun 5, 2016 at 10:50 PM, Tim Shepard wrote:
>
>
>> > Thanks. I've gotten no other feedback that suggests anyone else has
>> > read the code. So I very much appreciate it.
>>
>> I not only read it but tested it extensively against the ath9k stock,
>> ath10k stock, ath10k -michal's fqmac 3
On Sun, Jun 5, 2016 at 7:59 PM, Tim Shepard wrote:
>
>
>> > Huh. I wonder why you did that? Is it really better to call the
>> > ieee80211_txq a swq and call the ath9k hardware queue a txq? I
>> > thought doing the renaming made for more readable and much more
>> > maintainable code (where sear
And for the reason I originally cc'd ath9k-devel on this thread, was
merely that I'd wanted
to know if the diagram of the ath9k driver's current structure was
actually accurate. Is it?
http://blog.cerowrt.org/post/wifi_software_paths/
The "make-wifi-fast" mailing list exists merely because keepi
On Fri, May 13, 2016 at 12:20 PM, Aaron Wood wrote:
> On Fri, May 13, 2016 at 11:57 AM, Dave Taht wrote:
>>
>> On Fri, May 13, 2016 at 11:05 AM, Bob McMahon
>> wrote:
>>>
>>> don't have the data available for multiple flows at the moment.
>&
, but tweaking initcwnd,
tcp_limit_output_bytes, etc, is not the right thing.
There has been some good tcp research published of late, look into "BBR",
and "CDG".
> Note: That will depend on what exactly defines a flow.
>
> Bob
>
> On Fri, May 13, 2016 at
: Inline image 1]
> I'm not an expert on TCP near congestion avoidance but maybe the algorithm
> could benefit from RTT as weighted by CWND (or bytes in flight) and hunt
> that maximum?
>
> Bob
>
> On Mon, May 9, 2016 at 8:41 PM, David Lang wrote:
>
>> On Mon
This is a very good overview, thank you. I'd like to take apart
station behavior on wifi with a web application... as a straw man.
On Mon, May 9, 2016 at 8:41 PM, David Lang wrote:
> On Mon, 9 May 2016, Dave Taht wrote:
>
>> On Mon, May 9, 2016 at 7:25 PM, Jonathan
On Mon, May 9, 2016 at 8:30 PM, Adrian Chadd wrote:
> Hi,
>
> So:
>
> * the hardware can give us a per-AC transmit opportunity;
> * software queuing needs to handle the per-STA transmit opportunity;
> * they (and I followed convention after testing)
"They" had probably not made proper sacrifices
On Mon, May 9, 2016 at 7:25 PM, Jonathan Morton wrote:
>
>> On 9 May, 2016, at 18:35, Dave Taht wrote:
>>
>> should we always wait a little bit to see if we can form an aggregate?
>
> I thought the consensus on this front was “no”, as long as we’re making the
On Mon, May 9, 2016 at 4:00 AM, Toke Høiland-Jørgensen wrote:
> I finally finished my flow diagram of the ath9k TX path (corresponding
> to the previous one I did for the mac80211 stack). In case anyone else
> is interested, it's available here:
>
> https://blog.tohojo.dk/2016/05/the-ath9k-tx-path
These folk claim an open source prototype.
http://www.sigcomm.org/sites/default/files/ccr/papers/2014/January/2567561-2567567.pdf
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen wrote:
> On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote:
>> Over the weekend I found a bug in minstrel-ht that might well be
>> implicated here.
>>
>> The last retransmit rate is meant to be a 'get the packet there
>> reliably' rate;
On Sun, Feb 22, 2015 at 10:30 AM, Linus Torvalds
wrote:
> On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd wrote:
>>
>> Just a wild shot - try disabling fast authentication and see if that
>> makes a difference?
>>
>> wpa_supplicant.conf:
>>
>> fast_reauth=0
>>
>> I recall having issues with fast_r
I would like this too.
On Thu, Dec 11, 2014 at 5:47 AM, Christophe Prévotaux
wrote:
> I would like to know if there is a way to access the ath9k High Resolution
> Timestamp timers
>
> The current RTT resolution is quite low and not so useful for my purpose.
>
> --
> Christophe Prévotaux
> Email:
802.11e style priority mappings are just so wrong for 802.11n, anyway.
All they do is add bufferbloat and eat txops where you are much better
off aggregating more packets.
On Tue, Nov 25, 2014 at 1:14 PM, Hubert Feurstein wrote:
> Hi,
>
> 2014-11-24 10:10 GMT+01:00 M. Braun :
> [...]
>>
>> I don'
I have little doubt that we have been coping with more than one bug.
On Mon, Jul 14, 2014 at 4:02 PM, R. wrote:
> Hello David & list,
>
> Do you think we could get a build with CONFIG_PACKAGE_ATH_DEBUG
> enabled? I've been following OpenWRT ticket #15320 and it looks like
> this would be the wa
cc-ing ath9k-devel for this update on http://www.bufferbloat.net/issues/442
this bug, which some people (usually on macs with low signal strength)
can get to occur fairly rapidly, but I can't, is driving me 9 kinds of
crazy...
some new details below
On Sun, Jul 13, 2014 at 10:44 AM, Sebastian Mo
We have been trying to replicate a bug in seeing wifi connections hanging
in strange ways after tons of data is transferred... for several months now.
The symptoms varied, anything from multicast failing to background or best
effort traffic failing - from local access working with remote access
no
On Fri, Dec 13, 2013 at 8:00 PM, Sujith Manoharan wrote:
> Dave Taht wrote:
>> OK, I couldn't help myself but boot up that release. Wet paint! It
>> successfully brought up
>> the 5ghz radio, but did not manage to assign an ip address to it
>> (netifd bug?) and
sn't started
Failed to start hostapd for phy1
netifd: Interface 'sw10' is enabled
On Fri, Dec 13, 2013 at 12:56 PM, Dave Taht wrote:
> On Fri, Dec 13, 2013 at 1:27 AM, Sujith Manoharan wrote:
>> Sebastian Moeller wrote:
>>> It is a net gear WNDR3700 v2, so accor
On Fri, Dec 13, 2013 at 1:27 AM, Sujith Manoharan wrote:
> Sebastian Moeller wrote:
>> It is a net gear WNDR3700 v2, so according to:
>> http://wiki.openwrt.org/toh/netgear/wndr3700 it is a Atheros AR7161 rev 2 680
>> MHz soc with the following wireless parts: Atheros AR9223 802.11bgn / Atheros
>>
On Wed, May 30, 2012 at 1:06 AM, Ben Greear wrote:
> On 05/29/2012 12:07 PM, Christian Lamparter wrote:
>>
>> On Tuesday, May 29, 2012 08:23:20 PM Ben Greear wrote:
>>>
>>> On 05/27/2012 08:08 AM, Ben Greear wrote:
On 05/26/2012 09:39 AM, Sujith Manoharan wrote:
>>>
>>> We started testin
On 04/19/2010 07:05 PM, oii...@aol.com wrote:
I got avg. 60Mbps of the throughput rate by iperf testing and had the
testing environment like below:
OpenWrt: r18529 (I tried the latest r20851 and
the throughput rate could be even worse )
AP && STA h/w platform: IXP425
On 03/27/2010 05:18 PM, Benoit PAPILLAULT wrote:
> Yongheng Qi a écrit :
>
>> no one
>>
>>
> I am working on it. It is mostly working in my tree, but is still
> bleeding edge. There are two main area of work :
>
> - getting proper adhoc support in ath9k (and ath5k)
> - getting support for
28 matches
Mail list logo
