From: Eric Dumazet <eric.dumazet@gmail.com>
To: Albert Cahalan <acahalan@gmail.com>
Cc: David Miller <davem@davemloft.net>,
johnwheffner@gmail.com, linville@tuxdriver.com,
jussi.kivilinna@mbnet.fi, swmike@swm.pp.se,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: txqueuelen has wrong units; should be time
Date: Tue, 01 Mar 2011 08:26:21 +0100 [thread overview]
Message-ID: <1298964381.2676.58.camel@edumazet-laptop> (raw)
In-Reply-To: <AANLkTi=eDQh9Kvr9N_dTC5Cnbcfb+DbO-6tLxkZiEp9v@mail.gmail.com>
Le mardi 01 mars 2011 à 01:54 -0500, Albert Cahalan a écrit :
> On Mon, Feb 28, 2011 at 11:18 PM, David Miller <davem@davemloft.net> wrote:
> > From: Albert Cahalan <acahalan@gmail.com>
> > Date: Mon, 28 Feb 2011 23:11:13 -0500
> >
> >> It sounds like you need a callback or similar, so that TCP can be
> >> informed later that the drop has occurred.
> >
> > By that point we could have already sent an entire RTT's worth
> > of data, or more.
> >
> > It needs to be synchronous, otherwise performance suffers.
>
> Ouch. OTOH, the current situation: performance suffers.
>
> In case it makes you feel any better, consider two cases
> where synchronous feedback is already impossible.
> One is when you're routing packets that merely pass through.
> The other is when some other box is doing that to you.
> Either way, packets go bye-bye and nobody tells TCP.
So in a hurry we decide to drop packets blindly because kernel took the
cpu to perform an urgent task ?
Bufferbloat is a configuration/tuning problem, not a "everything must be
redone" problem. We add new qdiscs (CHOKe, SFB, QFQ, ...) and let admins
do their job. Problem is most admins are unaware of the problems, and
only buy more bandwidth.
And no, there is no "generic" solution, unless you have a lab with two
machines back to back (private link) and a known workload.
We might need some changes (including new APIs).
ECN is a forward step. Blindly dropping packets before ever sending them
is a step backward.
We should allow some trafic spikes, or many applications will stop
working. Unless all applications are fixed, we are stuck.
Only if the queue stay loaded a long time (yet another parameter) we can
try to drop packets.
next prev parent reply other threads:[~2011-03-01 7:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-27 5:44 txqueuelen has wrong units; should be time Albert Cahalan
2011-02-27 7:02 ` Mikael Abrahamsson
2011-02-27 7:54 ` Eric Dumazet
2011-02-27 8:27 ` Albert Cahalan
2011-02-27 10:55 ` Jussi Kivilinna
2011-02-27 20:07 ` Eric Dumazet
2011-02-27 21:32 ` Jussi Kivilinna
2011-02-28 11:43 ` Jussi Kivilinna
2011-02-28 13:10 ` Eric Dumazet
2011-02-28 18:31 ` Jussi Kivilinna
2011-02-28 16:11 ` John W. Linville
2011-02-28 16:48 ` Eric Dumazet
2011-02-28 16:55 ` John W. Linville
2011-02-28 17:18 ` Eric Dumazet
2011-02-28 21:45 ` John Heffner
2011-03-01 4:11 ` Albert Cahalan
2011-03-01 4:18 ` David Miller
2011-03-01 6:54 ` Albert Cahalan
2011-03-01 7:25 ` David Miller
2011-03-01 7:26 ` Eric Dumazet [this message]
2011-03-01 19:37 ` Albert Cahalan
2011-03-01 20:14 ` Eric Dumazet
2011-03-01 20:16 ` Eric Dumazet
2011-03-02 3:10 ` Mikael Abrahamsson
2011-03-02 20:25 ` Chris Friesen
2011-03-01 5:01 ` Eric Dumazet
2011-03-01 5:36 ` Eric Dumazet
2011-02-27 23:33 ` Albert Cahalan
2011-02-28 11:23 ` Jussi Kivilinna
2011-03-02 21:54 ` [RFC LOL OMG] pfifo_lat: qdisc that limits dequeueing based on estimated link latency John W. Linville
2011-03-02 22:08 ` John W. Linville
2011-03-03 12:51 ` Eric Dumazet
2011-02-28 15:38 ` txqueuelen has wrong units; should be time Hagen Paul Pfeifer
2011-02-28 16:37 ` Albert Cahalan
2011-02-28 17:45 ` John W. Linville
2011-02-28 17:20 ` Bill Sommerfeld
2011-02-28 21:51 ` John Heffner
2011-03-01 0:46 ` Mikael Abrahamsson
2011-03-02 6:25 ` Stephen Hemminger
2011-03-02 6:41 ` Mikael Abrahamsson
2011-03-02 7:07 ` Stephen Hemminger
2011-03-02 16:41 ` Mikael Abrahamsson
2011-03-02 16:50 ` Eric Dumazet
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=1298964381.2676.58.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=acahalan@gmail.com \
--cc=davem@davemloft.net \
--cc=johnwheffner@gmail.com \
--cc=jussi.kivilinna@mbnet.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=swmike@swm.pp.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox