Re: [Make-wifi-fast] [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs

On Fri, Oct 12, 2018 at 12:38 AM Rajkumar Manoharan wrote: > > On 2018-10-11 03:38, Toke Høiland-Jørgensen wrote: > > Rajkumar Manoharan writes: > > > >> Hmm... mine is bit different. txqs are refilled only once for all > >> txqs. > >> It will give more opportunity for non-served txqs.

Re: Tool to debug wifi pkt sniffs?

On Wed, Oct 10, 2018 at 1:44 PM Ben Greear wrote: > > On 10/10/2018 12:13 PM, Dave Taht wrote: > > On Wed, Oct 10, 2018 at 10:10 AM Ben Greear wrote: > >> > >> On 10/03/2018 01:29 PM, Dave Taht wrote: > >>> On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-

Re: Tool to debug wifi pkt sniffs?

On Wed, Oct 10, 2018 at 10:10 AM Ben Greear wrote: > > On 10/03/2018 01:29 PM, Dave Taht wrote: > > On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen wrote: > >> > >> Ben Greear writes: > >> > >>> Hello, > >>> > >&g

Re: [PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation

On Sat, Oct 6, 2018 at 11:18 AM Felix Fietkau wrote: > > On 2018-10-06 19:59, Dave Taht wrote: > > On Sat, Oct 6, 2018 at 10:37 AM Felix Fietkau wrote: > >> > >> When there are few packets (e.g. for sampling attempts), the exponentially > >> weighted v

Re: [PATCH 9/9] mac80211: rc80211_minstrel: remove variance / stddev calculation

On Sat, Oct 6, 2018 at 10:37 AM Felix Fietkau wrote: > > When there are few packets (e.g. for sampling attempts), the exponentially > weighted variance is usually vastly overestimated, making the resulting data > essentially useless. As far as I know, there has not been any practical use > for

Re: Tool to debug wifi pkt sniffs?

On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen wrote: > > Ben Greear writes: > > > Hello, > > > > I often find myself wanting to figure out what equipment is to blame (and > > why) > > in a wifi environment. > > > > I am thinking writing a tool that would parse a pcap file and look at

Re: [RFC] mac80211: budget outstanding airtime for transmission

As a side note (good work!) - I would dearly like to visibly account for management frames somewhere that can be seen from userspace. ?

Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen wrote: > Rajkumar Manoharan writes: > >>> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the >>> mac80211 TXQs for some devices because of a theoretical throughput >>> regression.

Re: [Make-wifi-fast] [PATCH v3] mac80211: Dynamically set CoDel parameters per station

On Thu, Apr 6, 2017 at 8:58 AM, Toke Høiland-Jørgensen wrote: > Eric Dumazet writes: > >> On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote: >> >>> + >>> +if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { >>> +

Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi

On Mon, Jan 30, 2017 at 8:17 AM, Toke Høiland-Jørgensen wrote: > Klaus Kinski writes: > >> Hello all, >> >> this is a blast from the past, but something that still bothers me. >> I have two systems with Atheros/QCA cards: >> >> System

Re: [PATCH] mac80211: prevent skb/txq mismatch

Yay! This sounds like a potential fix for this? https://bugs.lede-project.org/index.php?do=details_id=368 Are all the ath10k chipsets excluded by commit: 4ca1807815aa6801aaced7fdefa9edacc2521767 Still needed to be excluded?

Re: [PATCH net-next] bridge: multicast to unicast

On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau <n...@nbd.name> wrote: > On 2017-01-10 18:17, Dave Taht wrote: >> In the case of wifi I have 3 issues with this line of thought. >> >> multicast in wifi has generally supposed to be unreliable. This makes >> it reli

Re: [PATCH net-next] bridge: multicast to unicast

In the case of wifi I have 3 issues with this line of thought. multicast in wifi has generally supposed to be unreliable. This makes it reliable. reliability comes at a cost - multicast is typically set at a fixed low rate today. unicast is retried at different rates until it succeeds - for

Re: scheduled scan interval

On Mon, Nov 21, 2016 at 7:08 AM, Luca Coelho wrote: > Hi Arend, > > On Mon, 2016-11-21 at 13:03 +0100, Arend Van Spriel wrote: >> On 21-11-2016 12:30, Arend Van Spriel wrote: >> > On 21-11-2016 12:19, Arend Van Spriel wrote: >> > > Hi Johannes, Luca, >> > > >> > > The gscan work

make-wifi-fast linuxplumbers talk summarized on lwn.net

and available here: https://lwn.net/SubscriberLink/705884/1bdb9c4aa048b0d5/ After the talk I discussed with several folk about applying the same debloating techniques to other chipsets. I don't remember, unfortunately, who all those folk were, nor the candidate chipsets! -- Dave Täht Let's go

Re: [RFC] mac80211: set wifi_acked[_valid] bits for transmitted SKBs

On Thu, Oct 27, 2016 at 7:21 AM, Johannes Berg wrote: > From: Johannes Berg > > There may be situations in which the in-kernel originator of an > SKB cares about its wifi transmission status. To have that, set > the wifi_acked[_valid] bits

Re: Bayesian rate control

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

Re: [PATCH v3] ath10k: implement NAPI support

On Fri, Aug 26, 2016 at 4:12 AM, Johannes Berg <johan...@sipsolutions.net> 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 commen

Re: [PATCH v3] ath10k: implement NAPI support

I'm always rather big on people testing latency under load, and napi tends to add some.

Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.

On Wed, Aug 17, 2016 at 9:49 PM, Johannes Berg wrote: > Hi, > > You need to work on coding style, a lot of your indentation is > completely messed up. > >> + switch (sdata->vif.type) { >> + case NL80211_IFTYPE_STATION: >> + if

Re: [PATCH] ath10k: disable wake_tx_queue for older devices

On Thu, Aug 4, 2016 at 12:07 PM, Roman Yeryomin <leroi.li...@gmail.com> wrote: > On 1 August 2016 at 12:04, Dave Taht <dave.t...@gmail.com> wrote: >> On Mon, Aug 1, 2016 at 1:35 AM, Roman Yeryomin <leroi.li...@gmail.com> wrote: >>> On 7 July 2016 at 19:30,

Re: [PATCH] ath10k: disable wake_tx_queue for older devices

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

Re: TCP performance regression in mac80211 triggered by the fq code

Just to add another datapoint, the "rack" optimization for tcp entered the kernel recently. It has some "interesting" timing/batching sensitive behaviors. While the TSO case is described, the packet aggregation case seems similar, and is not.

Re: TCP performance regression in mac80211 triggered by the fq code

On Wed, Jul 13, 2016 at 10:53 AM, Felix Fietkau wrote: >> To me this implies a contending lock issue, too much work in the irq >> handler or too delayed work in the softirq handler >> >> I thought you were very brave to try and backport this. > I don't think this has anything

Re: TCP performance regression in mac80211 triggered by the fq code

On Tue, Jul 12, 2016 at 4:02 PM, Dave Taht <dave.t...@gmail.com> wrote: > On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau <n...@nbd.name> wrote: >> On 2016-07-12 14:13, Dave Taht wrote: >>> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <n...@nbd.name> wrote:

Re: TCP performance regression in mac80211 triggered by the fq code

On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau <n...@nbd.name> wrote: > On 2016-07-12 14:13, Dave Taht wrote: >> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau <n...@nbd.name> wrote: >>> Hi, >>> >>> With Toke's ath9k txq patch I've noticed a pret

Re: TCP performance regression in mac80211 triggered by the fq code

On Tue, Jul 12, 2016 at 2:57 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Dave Taht <dave.t...@gmail.com> writes: > >>> As for why this would happen... There could be a bug in the dequeue code >>> somewhere, but since you get better performance from sticki

Re: TCP performance regression in mac80211 triggered by the fq code

On Tue, Jul 12, 2016 at 2:28 PM, Toke Høiland-Jørgensen wrote: > Felix Fietkau writes: > >> Hi, >> >> With Toke's ath9k txq patch I've noticed a pretty nasty performance >> regression when running local iperf on an AP (running the txq stuff) to >> a wireless client.

Re: TCP performance regression in mac80211 triggered by the fq code

On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau wrote: > Hi, > > With Toke's ath9k txq patch I've noticed a pretty nasty performance > regression when running local iperf on an AP (running the txq stuff) to > a wireless client. Your kernel? cpu architecture? What happens when

Re: A question about MAC80211 (3.9)

What are you trying to accomplish? I look forward to seeing any rate control algorithm that can address the issues in minstrel! ( http://blog.cerowrt.org/post/minstrel/ ) It has generally been my hope to implement some form of better service sharing between the VO, VI, and BE queues than what

Re: [ath9k-devel] [PATCH] ath9k: Support 4.9Ghz channels on AR9580 adapter.

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

Re: [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

>> 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

Re: How to use fractional center frequencies (4942.5, for instance)?

On Mon, Jun 6, 2016 at 8:04 AM, Ben Greear wrote: > > It appears that some cisco equipment, at least, uses fractional center > frequencies for 5Mhz channels. I was not aware that anything supported 5Mhz other than ath9k and ath5k. Thx. Can you identify what cisco gear

Re: [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues

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

Re: [RFC/RFT 2/5] ath9k: use mac80211 intermediate software queues

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,

Re: iwlwifi: mvm: add reorder buffer per queue

I can't even describe how much I hate the concept of the reorder buffer in general. Ordering is the endpoints problem. Someday, after we get fq_codeled, short queues again, I'll be able to show why. On Mon, May 16, 2016 at 4:41 AM, Luca Coelho wrote: > On Fri, 2016-05-13 at

Re: Limit rate of BCM34348 on Raspberry PI-3 via brcmfmac

Ugh. A somewhat dumb question is how would I disable bluetooth entirely on the rpi3? I had done some initial tests on the rpi3 for the fq_codel on wifi work and gave up due to dismal results on the flent tests. I hadn't got around to writing them up here, http://blog.cerowrt.org/tags/wifi/ but

Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

On Thu, May 5, 2016 at 11:33 PM, Michal Kazior <michal.kaz...@tieto.com> wrote: > On 6 May 2016 at 07:51, Dave Taht <dave.t...@gmail.com> wrote: >> On Thu, May 5, 2016 at 10:27 PM, Michal Kazior <michal.kaz...@tieto.com> >> wrote: >>> On 5 May 2016 at 17

Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

On Thu, May 5, 2016 at 10:27 PM, Michal Kazior <michal.kaz...@tieto.com> wrote: > On 5 May 2016 at 17:21, Dave Taht <dave.t...@gmail.com> wrote: >> On Thu, May 5, 2016 at 4:00 AM, Michal Kazior <michal.kaz...@tieto.com> >> wrote: >>> This adds a few deb

Re: [PATCHv4 4/5] mac80211: implement codel on fair queuing flows

On Thu, May 5, 2016 at 4:00 AM, Michal Kazior wrote: > There is no other limit other than a global > packet count limit when using software queuing. > This means a single flow queue can grow insanely > long. This is particularly bad for TCP congestion > algorithms which

Re: [PATCHv4 5/5] mac80211: add debug knobs for codel

On Thu, May 5, 2016 at 4:00 AM, Michal Kazior wrote: > This adds a few debugfs entries to make it easier > to test, debug and experiment. I might argue in favor of moving all these (inc the fq ones) into their own dir, maybe "aqm" or "sqm". The mixture of read only

Re: General VHT rate-ctrl question

On Wed, Apr 13, 2016 at 6:18 AM, Ben Greear wrote: > > > On 04/13/2016 01:01 AM, Johannes Berg wrote: >> >> On Tue, 2016-04-12 at 16:48 -0700, Ben Greear wrote: >>> >>> If a station and it's peer can both do VHT, is there ever a good >>> reason to even try HT rates? >>>

ietf proposed standards for dscp to 802.11e mappings

If anyone cares https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11/?include_text=1 these will be discussed on the tsvwg mailing list. https://www.ietf.org/mailman/listinfo/tsvwg There are several things in here I object to - no discussion of multicast, and arbitrarily

Re: [PATCHv2 1/2] mac80211: implement fair queuing per txq

On Wed, Apr 6, 2016 at 12:21 AM, Johannes Berg wrote: > [removing other lists since they spam me with moderation bounces] I have added your email address be accepted to the codel, make-wifi-fast lists. My apologies for the bounces. The people on those lists generally

Re: [PATCHv2 1/2] mac80211: implement fair queuing per txq

thx for the review! On Tue, Apr 5, 2016 at 6:57 AM, Johannes Berg wrote: > On Thu, 2016-03-31 at 12:28 +0200, Michal Kazior wrote: > >> +++ b/net/mac80211/codel.h >> +++ b/net/mac80211/codel_i.h > > Do we really need all this code in .h files? It seems very odd to me

Re: [RFC] ath10k: implement dql for htt tx

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 <michal.kaz...@tieto.com> wrote: > On 26 March 2016 at 17:44, Dave Taht <dave.t...@gmail.com> wrote: >> Dear Mi

Re: Bonjour mDNS broacast can be lost during BT-WLAN coexistence schemes?

These folk claim an open source prototype. http://www.sigcomm.org/sites/default/files/ccr/papers/2014/January/2567561-2567567.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [RFC] ath10k: implement dql for htt tx

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

Re: [RFCv2 0/3] mac80211: implement fq codel

kaz...@tieto.com> wrote: > On 21 March 2016 at 18:10, Dave Taht <dave.t...@gmail.com> 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 s

Re: making fq_codel default

On Tue, Mar 22, 2016 at 3:05 AM, Reinoud Koornstra wrote: > Thanks, that answers my question. Adding this to /etc/sysctl.conf or /etc/sysctl.d/bufferbloat.conf is generally what we do net.core.default_qdisc=fq_codel A lot of us are running ecn by default and put in

Re: [RFCv2 0/3] mac80211: implement fq codel

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 <j...@eero.com> wrote: >> BK usually has 0 txop, so it doesn't do aggregation. >> >> On Wed, Mar

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

>> regular fq_codel uses 1024 and there has not been much reason to >> change it. In the case of an AP which has more limited memory, 256 or >> 1024 would be a good setting, per station. I'd stick to 1024 for now. > > Do note that the 4096 is shared _across_ station-tid queues. It is not >

per sta queuing - the ath9k statistics

I have put together some of the patches for fq_codel and per-station queuing inside the mac80211 portion of the stack flying around on linux-wireless, to no real visible effect as yet. Mostly testing uploads at the moment, from an x86 based client. It's not clear if I have the code path enabled,

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

RESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > + * SPECI

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun <apenw...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht <dave.t...@gmail.com> wrote: >> If I can just get a coherent patch set that I can build, I will gladly >> join you on the testing ath9k in particula

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

If I can just get a coherent patch set that I can build, I will gladly join you on the testing ath9k in particular... can probably do ath10k, too - and do a bit of code review... this week. it's very exciting watching all this activity... but I confess that I've totally lost track of what set of

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

On Tue, Mar 1, 2016 at 11:38 PM, Michal Kazior wrote: > On 1 March 2016 at 15:02, Johannes Berg wrote: >> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote: >>> >>> +typedef u64 codel_time_t; >> >> Do we really need this? And if yes, does

Re: [PATCH] mac80211: fix AP buffered multicast frames with queue control and txq

On Thu, Mar 3, 2016 at 7:14 AM, Johannes Berg <johan...@sipsolutions.net> wrote: > On Sun, 2016-02-28 at 09:35 -0800, Dave Taht wrote: >> On Sun, Feb 28, 2016 at 6:19 AM, Felix Fietkau <n...@openwrt.org> >> wrote: >> > Buffered multicast frames must be passed to

Re: [PATCH] mac80211: fix AP buffered multicast frames with queue control and txq

On Sun, Feb 28, 2016 at 6:19 AM, Felix Fietkau wrote: > Buffered multicast frames must be passed to the driver directly via > drv_tx instead of going through the txq, otherwise they cannot easily be > scheduled to be sent after DTIM. > > Signed-off-by: Felix Fietkau

Re: [PATCH] codel: add forgotten inline to functions in header file

On Thu, Feb 11, 2016 at 7:05 AM, Grumbach, Emmanuel wrote: > fixing linux-wireless address ... > > On 02/11/2016 04:30 PM, Eric Dumazet wrote: >> On Thu, 2016-02-11 at 16:08 +0200, Emmanuel Grumbach wrote: >>> Signed-off-by: Emmanuel Grumbach

Re: [PATCH] codel: add forgotten inline to functions in header file

On Thu, Feb 11, 2016 at 7:29 AM, Grumbach, Emmanuel wrote: > > > On 02/11/2016 05:12 PM, Eric Dumazet wrote: >> On Thu, 2016-02-11 at 15:05 +, Grumbach, Emmanuel wrote: >> >> >>> Yeah :) codel_should_drop seemed very long indeed... I wanted to use the >>>

Re: [RFC v4] mac80211: add A-MSDU tx support

On Mon, Feb 8, 2016 at 3:23 AM, Felix Fietkau wrote: > On 2016-02-08 12:06, Krishna Chaitanya wrote: >> On Mon, Feb 8, 2016 at 4:34 PM, Felix Fietkau wrote: >>> On 2016-02-08 10:54, Krishna Chaitanya wrote: On Mon, Feb 8, 2016 at 2:56 PM, Emmanuel

Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

> A bursted txop can be as big as 5-10ms. If you consider you want to > queue 5-10ms worth of data for *each* station at any given time you > obviously introduce a lot of lag. If you have 10 stations you might > end up with service period at 10*10ms = 100ms. This gets even worse if > you consider

Re: [RFC RESEND] iwlwifi: pcie: transmit queue auto-sizing

e can get from a few chipsets, but not enough was known about the iwl last I looked. And one reason why fq_codel - unassisted - is not quite the right thing on top of this is that multicast can take a really long time... Regardless, I'd highly love to see/use this patch myself in a variety of real w

Re: [ath9k-devel] AR9462 problems connecting again..

On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen j...@w1.fi 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;

Re: [ath9k-devel] AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 10:30 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd adr...@freebsd.org wrote: Just a wild shot - try disabling fast authentication and see if that makes a difference? wpa_supplicant.conf: fast_reauth=0 I

Wifi outside the faraday cage (was: Throughput regression with `tcp: refine TSO autosizing`)

On Fri, Feb 6, 2015 at 1:57 AM, Michal Kazior michal.kaz...@tieto.com wrote: On 5 February 2015 at 20:50, Dave Taht dave.t...@gmail.com wrote: [...] And I really, really, really wish, that just once during this thread, someone had bothered to try running a test at a real world MCS rate - say

Re: Throughput regression with `tcp: refine TSO autosizing`

On Wed, Feb 11, 2015 at 11:48 PM, Michal Kazior michal.kaz...@tieto.com wrote: On 11 February 2015 at 09:57, Michal Kazior michal.kaz...@tieto.com wrote: On 10 February 2015 at 15:19, Johannes Berg johan...@sipsolutions.net wrote: On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote: +

Re: Throughput regression with `tcp: refine TSO autosizing`

On Fri, Feb 6, 2015 at 2:44 AM, Michal Kazior michal.kaz...@tieto.com wrote: On 5 February 2015 at 14:19, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote: The intention is to control the queues to the following : 1 ms of buffering, but