From: Jim Gettys <jg@freedesktop.org>
To: bloat-devel@lists.bufferbloat.net
Subject: Re: [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat
Date: Sat, 19 Feb 2011 19:51:10 -0500 [thread overview]
Message-ID: <4D60657E.1080404@freedesktop.org> (raw)
In-Reply-To: <AANLkTinTcdbjSYvt7Z_yOe_8kGZnyp2MBXZYYJ9zGB_D@mail.gmail.com>
On 02/19/2011 07:37 PM, Nathaniel Smith wrote:
> Actually, a few more comments just occurred to me...
>
> On Fri, Feb 18, 2011 at 1:21 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
>> Johannes' comment about tx status reporting being unreliable (and what
>> he was really saying) finally sunk-in. So, this version uses
>> skb->destructor to track in-flight fragments. That should handle
>> fragments that get silently dropped in the driver for whatever reason
>> without leaking queue capacity. Correct me if I'm wrong!
>
> Should we be somehow filtering out and ignoring the packets that get
> dropped, when we're calculating the average packet transmission rate?
> Presumably they're getting dropped almost instantly, so they don't
> really take up queue space and they have abnormally fast transmission
> times, which will tend to cause us to overestimate max_enqueued? They
> should be rare, though, at least. (And presumably we *should* include
> packets that get dropped because their retry timer ran out, since they
> were sitting in the queue for that long.) Possibly we should just
> ignore any packet that was handled in less than, oh, say, a few
> microseconds?
I will note that AQM algorithms that are likely to work will need to
know the actual "goodput" of the link. (This from talking to Van
Jacobson about the problem we face.)
- Jim
next prev parent reply other threads:[~2011-02-20 0:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1297619803-2832-1-git-send-email-njs@pobox.com>
2011-02-17 1:49 ` [RFC] " John W. Linville
2011-02-17 3:31 ` Ben Greear
2011-02-17 4:26 ` Nathaniel Smith
2011-02-17 8:31 ` Johannes Berg
2011-02-18 21:21 ` [RFC v2] " John W. Linville
2011-02-19 3:44 ` Nathaniel Smith
2011-02-21 18:47 ` John W. Linville
2011-02-21 23:26 ` Nathaniel Smith
2011-02-23 22:28 ` John W. Linville
2011-02-25 18:21 ` Nathaniel Smith
2011-02-25 18:27 ` Nathaniel Smith
2011-02-20 0:37 ` Nathaniel Smith
2011-02-20 0:51 ` Jim Gettys [this message]
2011-02-20 15:24 ` Dave Täht
2011-02-21 18:52 ` John W. Linville
2011-02-21 15:28 ` Johannes Berg
2011-02-21 16:12 ` Jim Gettys
2011-02-21 19:15 ` John W. Linville
2011-02-21 19:06 ` John W. Linville
2011-02-21 19:29 ` [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat - AQM on hosts Jim Gettys
2011-02-21 20:26 ` [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat Tianji Li
2011-02-28 13:07 ` Johannes Berg
[not found] <x1-oTZGm1A7eclvABnv1aK0z1Nc7iI@gwene.org>
2011-02-20 1:59 ` Dave Täht
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=4D60657E.1080404@freedesktop.org \
--to=jg@freedesktop.org \
--cc=bloat-devel@lists.bufferbloat.net \
/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