From: David Collier-Brown <davec-b@rogers.com>
To: Richard Scheffenegger <rscheff@gmx.at>
Cc: codel@lists.bufferbloat.net
Subject: Re: [Codel] About Packet Drop in Codel
Date: Fri, 27 Feb 2015 20:57:40 -0500 [thread overview]
Message-ID: <54F12094.5040200@rogers.com> (raw)
In-Reply-To: <mailman.153549.1425025588.1815.codel@lists.bufferbloat.net>
On 02/27/2015 03:26 AM, From: Stephen Hemminger <stephen@networkplumber.org>
"Richard Scheffenegger" <rscheff@gmx.at> wrote:
>> Hi Members,
>> i am doing M.tech and my research topic is AQM.
>> i tried to run codel with ns-2.35.
>> And i found packet loss is more in codel as compared to RED.
> More packet loss is no necessarily a bad thing.
> You need to measure throughput and latency together.
TCP isn't a normal queuing system: when it gets close to it's capacity,
it throttles the sender, so that the system isn't driven into the load
range where latency goes up and (effective[1]) throughput plummets.
Instead, it does congestion *avoidance*, rather like deadlock avoidance,
and levels off total bandwidth to something very close but just below to
the link's capacity. Dropping a packet forces the sender to reduce their
offered load and then try to increase it slowly until they exceed the
maximum and it drops another packet.
This is cool: instead of the latency vs load curve looking like "_/", it
looks like "_", at something close to 99% bandwidth. Lovely low latency,
near-maximum bandwidth.
--dave
--
[1. Effective throughput is what humans care about: x Mb/S. If your
data is delayed 30 seconds, theoretical throughput doesn't change, but
frames from a movie are horribly delayed, and in effect, throughput is
horrid. This too is something that TCP does well, and people like Van
Jacobsen and Neil Gunther understand, but simplistic users of queuing
theory don't]
I'm an ex-York University nerd and author, so if I can help in your
efforts, drop me a line.
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain
next parent reply other threads:[~2015-02-28 1:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.153549.1425025588.1815.codel@lists.bufferbloat.net>
2015-02-28 1:57 ` David Collier-Brown [this message]
2015-02-26 17:12 divya singla
2015-02-26 18:32 ` Richard Scheffenegger
2015-02-26 23:14 ` Stephen Hemminger
2015-03-02 17:43 ` divya singla
2015-03-02 18:10 ` Rick Jones
2015-03-02 18:22 ` Jonathan Morton
2015-03-02 18:43 ` divya singla
2015-03-02 19:07 ` Jonathan Morton
2015-03-03 18:12 ` divya singla
2015-03-03 18:27 ` Rick Jones
2015-03-02 18:35 ` Jonathan Morton
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
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F12094.5040200@rogers.com \
--to=davec-b@rogers.com \
--cc=codel@lists.bufferbloat.net \
--cc=davecb@spamcop.net \
--cc=rscheff@gmx.at \
/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