what is your definition "Good results"? I would really love it if I
could get back more flent benchmarks like this one:
https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002
As the ath10k has cost me more hair and time than I care to think about.
I am always interested in flent.org tcp_nup, tcp_ndown, and rrul_be
tests on wifi hardware. In AP mode, especially, against a few clients
in rtt_fair on the "ending the anomaly" test suite at the bottom of
this link: https://www.cs.kau.se/tohojo/airtime-fairness/ . Of these,
it's trying to optimize
On Wed, Dec 28, 2022 at 3:53 PM Abhishek Kumar wrote:
>
> Apologies for the late reply, Thanks Dave for your comment. My answer is
> inline.
>
> On Tue, Dec 20, 2022 at 7:10 AM Dave Taht wrote:
> >
> > I am always interested in flent.org tcp_nup, tcp_ndown, an
ful new feature, much simpler than relying on packet
captures. However! this test result above is on a decent, ethernet,
network, where on wifi, or anything bufferbloated, you would see the
cwnd and rtt inflate and/or bounce around horribly.
>
>
> Bob
>
> On Wed, Dec 28, 2022 at 4:
it is helpful to name the test files coherently in the flent tests, in
addition to using a directory structure and timestamp. It makes doing
comparison plots in data->add-other-open-data-files simpler. "-t
patched-mac-300mbps", for example.
Also netperf from svn (maybe 2.7, don't remember) will re
put which is
> most likely a result of my sloppy proof-of-concept change in ath10k).
So I should avoid ben greer's firmware for now?
>
>
> Michał
>
> On 16 March 2016 at 20:48, Jasmine Strong wrote:
>> BK usually has 0 txop, so it doesn't do aggregation.
>
t; On 21 March 2016 at 18:10, Dave Taht wrote:
>> thx.
>>
>> a lot to digest.
>>
>> A) quick notes on "flent-gui bursts_11e-2016-03-21T09*.gz"
>>
>> 1) the new bursts_11e test *should* have stuck stuff in the VI and VO
>> queues, and ther
Dear Michal:
I commented on and put up your results for the baseline driver here:
http://blog.cerowrt.org/post/rtt_fair_on_wifi/
And the wonderful result you got for the first ever fq_codel-ish
implementation here:
http://blog.cerowrt.org/post/fq_codel_on_ath10k/
I am running behind on this pa
As a side note of wifi ideas complementary to codel, please see:
http://blog.cerowrt.org/post/selective_unprotect/
On Tue, Mar 29, 2016 at 12:49 AM, Michal Kazior wrote:
> On 26 March 2016 at 17:44, Dave Taht wrote:
>> Dear Michal:
> [...]
>> I am running behind on this patch
There were a few things on this thread that went by, and I wasn't on
the ath10k list
(https://www.mail-archive.com/ath10k@lists.infradead.org/msg04461.html)
first up, udp flood...
>>> From: ath10k on behalf of Roman
>>> Yeryomin
>>> Sent: Friday, April 8, 2016 8:14 PM
>>> To: ath10k@lists.infr
On Sat, Apr 30, 2016 at 10:08 PM, Ben Greear wrote:
>
>
> On 04/30/2016 08:41 PM, Dave Taht wrote:
>>
>> There were a few things on this thread that went by, and I wasn't on
>> the ath10k list
>>
>> (https://www.mail-archive.com/ath10k@lists.infradead.
On Sun, May 1, 2016 at 10:59 AM, Eric Dumazet wrote:
> On Sat, 2016-04-30 at 20:41 -0700, Dave Taht wrote:
>> >>>
>> >>> 45.78% [kernel] [k] fq_codel_drop
>> >>> 3.05% [kernel] [k] ag71xx_poll
>> >>> 2.18%
On Mon, May 2, 2016 at 9:14 AM, Eric Dumazet wrote:
> On Mon, 2016-05-02 at 18:43 +0300, Roman Yeryomin wrote:
>> On 2 May 2016 at 18:07, Eric Dumazet wrote:
>> > On Mon, 2016-05-02 at 17:18 +0300, Roman Yeryomin wrote:
>> >
>> >> Imagine you are a video operator, have MacBook Pro, gigabit LAN an
ms fun to work on in a research paper because it
>> is easy to state compared to the real world) too much.
>>
>> I know that the reaction to this post will be to read it and pretty much go
>> on as usual focusing on UDP floods. But I have to try. There are so many
>&
to fork the fq_codel_drop discussion a bit...
I have up and running two new boxes[1] that are my hope to be able to
test ath10k/ath9k hardware with, for this test, using one in the
middle as a router and a nuc i3 box as the server, all ports pure
ethernet... there's a switch in the way, too.
On t
On Mon, May 2, 2016 at 4:27 PM, Rick Jones wrote:
> On 05/02/2016 04:18 PM, Dave Taht wrote:
>>
>> Netperf does not have a multi-hop capable udp flood test (rick jones
>> can explain why... )
>
>
> Well, with an intro like that, how could I refuse?-)
>
> In a
On Sun, May 1, 2016 at 11:20 AM, Jonathan Morton wrote:
>
>> On 1 May, 2016, at 20:59, Eric Dumazet wrote:
>>
>> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a
>> single one.
>
> Unfortunately, that could have bad consequences if the “fat flow” happens to
> be a TCP in sl
On Mon, May 2, 2016 at 7:26 PM, Dave Taht wrote:
> On Sun, May 1, 2016 at 11:20 AM, Jonathan Morton
> wrote:
>>
>>> On 1 May, 2016, at 20:59, Eric Dumazet wrote:
>>>
>>> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a
>>>
Thus far this batch drop patch is testing out beautifully. Under a
900Mbit flood going into 100Mbit on the pcengines apu2, cpu usage for
ksoftirqd now doesn't crack 10%, where before (under
pie,pfifo,fq_codel,cake & the prior fq_codel) it went to 88% and
ultimately bad things happened, like losing
On Tue, May 3, 2016 at 10:54 AM, Eric Dumazet wrote:
> On Tue, 2016-05-03 at 10:37 -0700, Dave Taht wrote:
>> Thus far this batch drop patch is testing out beautifully. Under a
>> 900Mbit flood going into 100Mbit on the pcengines apu2, cpu usage for
>> ksoftirqd now doe
On Thu, May 5, 2016 at 7:53 AM, Roman Yeryomin wrote:
> On 2 May 2016 at 19:14, Eric Dumazet wrote:
>> On Mon, 2016-05-02 at 18:43 +0300, Roman Yeryomin wrote:
>>> On 2 May 2016 at 18:07, Eric Dumazet wrote:
>>> > On Mon, 2016-05-02 at 17:18 +0300, Roman Yeryomin wrote:
>>> >
>>> >> Imagine you
On Thu, May 5, 2016 at 10:39 AM, Roman Yeryomin wrote:
> On 5 May 2016 at 19:59, Jonathan Morton wrote:
>>> Having same (low) speeds.
>>> So it didn't help at all :(
>>
>> Although the new “emergency drop” code is now dropping batches of
>> consecutive packets, Codel is also still dropping indiv
On Thu, May 5, 2016 at 9:59 AM, Jonathan Morton wrote:
>> Having same (low) speeds.
>> So it didn't help at all :(
>
> Although the new “emergency drop” code is now dropping batches of consecutive
> packets, Codel is also still dropping individual packets in between these
> batches, probably at
On Thu, May 5, 2016 at 12:23 PM, Eric Dumazet wrote:
> On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>> On 5 May 2016 at 19:12, Eric Dumazet wrote:
>> > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>> >
>> >>
>> >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows
On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote:
> On 6 May 2016 at 21:43, Roman Yeryomin wrote:
>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>>>
>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
>>> closed Felix'es OpenWRT email account (bad choic
On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin wrote:
> On 16 May 2016 at 01:34, Roman Yeryomin wrote:
>> On 6 May 2016 at 22:43, Dave Taht wrote:
>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin
>>> wrote:
>>>> On 6 May 2016 at 21:43, Roman Yeryom
On Thu, Jun 16, 2016 at 12:57 PM, Gaurang Ramesh Naik wrote:
> Hi Ben,
>
> Thanks for your reply.
>
> I wanted to know if the dynamic bandwidth option implemented in ath10k
> is the same as that mentioned in the standard, or does it deviate? I
> tried to look for any documentation on ath10k dynami
On Mon, Aug 1, 2016 at 1:35 AM, Roman Yeryomin wrote:
> On 7 July 2016 at 19:30, Valo, Kalle wrote:
>> Michal Kazior writes:
>>
>>> Ideally wake_tx_queue should be used regardless as
>>> it is a requirement for reducing bufferbloat and
>>> implementing airtime fairness in the future.
>>>
>>> How
On Thu, Aug 4, 2016 at 12:07 PM, Roman Yeryomin wrote:
> On 1 August 2016 at 12:04, Dave Taht wrote:
>> On Mon, Aug 1, 2016 at 1:35 AM, Roman Yeryomin wrote:
>>> On 7 July 2016 at 19:30, Valo, Kalle wrote:
>>>> Michal Kazior writes:
>>>>
>>>
I'm always rather big on people testing latency under load, and napi
tends to add some.
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
On Fri, Aug 26, 2016 at 4:12 AM, Johannes Berg
wrote:
> On Fri, 2016-08-26 at 03:48 -0700, Dave Taht wrote:
>> I'm always rather big on people testing latency under load, and napi
>> tends to add some.
>
> That's a completely useless comment.
>
> Obviously, ev
On Fri, Aug 8, 2014 at 8:42 AM, Ben Greear wrote:
> On 08/08/2014 02:06 AM, Kalle Valo wrote:
>> Ben Greear writes:
>>
>>> I'm working on a patch to report the stats seen in
>>> debugfs/...ath10k/fw_stats
>>> as ethtool stats, somewhat similar to how ath9k does it.
>>>
>>> I notice that my user-
On Mon, Sep 22, 2014 at 12:26 PM, Kathy Giori wrote:
> Hey there ath10k enthusiasts,
>
> The afternoon prior to the Linux wireless summit that John Linville
> and Johannes Berg are hosting:
> http://www.linuxplumbersconf.org/2014/ocw/events/LPC2014/tracks/339
>
> we've reserved a conference room t
On Tue, Nov 25, 2014 at 4:59 PM, Ben Greear wrote:
> A company that wishes to remain anonymous is sponsoring my
> effort to add IBSS (ADHOC) support to my 10.1.467 CT firmware.
Oh, wonderful. I would love to get babeld running on this stuff on
adhoc mode
> The kernel driver must be patched t
On Sat, Feb 21, 2015 at 9:31 AM, Ben Greear wrote:
> Here are the highlights:
>
> Add IBSS/AHDOC support.
Awesome. Does this require the candela kernel patchset?
(am thinking of trying this version of the firmware on openwrt chaos
calmer on the tp-link archer C7 v2)
> Work-around tx-credits han
In terms of deeply grokking what increasing buffering to achieve high
bandwidth on a testbench, vs what it can do to clobber latency in the
real world at low bandwidths, I tend to point folk at:
https://www.youtube.com/watch?v=Rb-UnHDw02o&t=25m40s
where I got a whole bunch of hackers to stand u
Wen Gong writes:
>> -Original Message-
>> From: Dave Taht
>> Sent: Wednesday, September 4, 2019 12:10 AM
>> To: Wen Gong ; ath10k@lists.infradead.org;
>> linux-wirel...@vger.kernel.org
>> Subject: [EXT] Re: [PATCH 2/7] ath10k: change max RX
On Tue, Apr 28, 2020 at 5:06 AM Kalle Valo wrote:
>
> Sven Eckelmann writes:
>
> > On Wednesday, 1 April 2020 09:00:49 CEST Sven Eckelmann wrote:
> >> On Wednesday, 5 February 2020 20:10:43 CEST Linus Lüssing wrote:
> >> > From: Linus Lüssing
> >> >
> >> > Before, only frames with a maximum size
I have not been on this thread (I have had to shut down my wifi lab
and am not planning on doing any more wifi work in the future). But
for what it's worth:
* tcp_pacing_shift affects the performance of the tcp stack only. I
think 16ms is an outrageous amount, and I'm thinking we actually have
a p
While I'm being overly vague and general...
* Doing some form of ack compression (whether in the tcp stack or in
mac80211) seems useful. It's really
hard to fill 4Mbytes one way and the needed number of acks the other.
I'd also pointed out (on some thread on the make-wifi-fast list that I
can't fi
Toke Høiland-Jørgensen writes:
> Felix Fietkau writes:
>
>> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote:
This part doesn't really make much sense to me, but maybe I'm
misunderstanding how the code works.
Let's assume we have a driver like ath9k or mt76, which tries to keep a
Toke Høiland-Jørgensen writes:
> Dave Taht writes:
>
>> Toke Høiland-Jørgensen writes:
>>
>>> Felix Fietkau writes:
>>>
>>>> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote:
>>>>>> This part doesn't really make muc
On Mon, Nov 19, 2018 at 3:30 PM Simon Barber wrote:
>
>
>
> On Nov 19, 2018, at 2:44 PM, Toke Høiland-Jørgensen wrote:
>
> Dave Taht writes:
>
> Toke Høiland-Jørgensen writes:
>
> Felix Fietkau writes:
>
> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrot
On Mon, Nov 19, 2018 at 3:56 PM Ben Greear wrote:
>
> On 11/19/2018 03:47 PM, Dave Taht wrote:
> > On Mon, Nov 19, 2018 at 3:30 PM Simon Barber wrote:
> >>
> >>
> >>
> >> On Nov 19, 2018, at 2:44 PM, Toke Høiland-Jørgensen wrote:
> >>
On Mon, Nov 19, 2018 at 4:20 PM Ben Greear wrote:
>
> On 11/19/2018 04:13 PM, Dave Taht wrote:
> > On Mon, Nov 19, 2018 at 3:56 PM Ben Greear wrote:
> >>
> >> On 11/19/2018 03:47 PM, Dave Taht wrote:
> >>> On Mon, Nov 19, 2018 at 3:30 PM Simon Barber wr
eping the
good wifi in is important. Could cover floors and ceilings with it to.
Cars could be tempest rated...
/me goes looking for stock to buy
> Simon
>
> On Nov 19, 2018, at 4:20 PM, Ben Greear wrote:
>
> On 11/19/2018 04:13 PM, Dave Taht wrote:
>
> On Mon, Nov 19
tempest rated being a win. "Available in 2020 from a Tesla dealer near
you!"
My car was built in 2003 and doesn't have any of this newfangled stuff.
> -Original
> From: "David Lang"
> Sent: Mon, Nov 19, 2018 at 9:12 pm
> To: "Dave Taht"
> C
Johannes Berg writes:
> On Thu, 2018-11-15 at 09:10 -0800, Toke Høiland-Jørgensen wrote:
>> Louie Lu writes:
>>
>> > Hi Rajkumar, Toke,
>> >
>> > I found the series (v3,4/6) remove the debugfs remove reset
>> > station's
>> > airtime method, and didn't added at here.
>> >
>> > Not sure how to
n't impact the API. Having a separate patch also makes testing
> easier anyway. I'll see if I can't get it to a working state over the
> holidays...
There comes a time in all patch series where the best thing to do is
commit i
On Tue, Jan 28, 2025 at 7:18 AM John W. Linville wrote:
>
> On Tue, 2025-01-28 at 11:20 +0200, Kalle Valo wrote:
> > Hi everyone,
> >
> > I'm stepping down from all my maintainer roles. My first commit
>
> Well, my friend, I suppose the time has come for you to move on to
> something else? I truly
50 matches
Mail list logo
