From: Jim Gettys <jg@freedesktop.org>
To: David P Reed <dpreed@reed.com>
Cc: Frits Riep <riep@riepnet.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration.
Date: Wed, 21 May 2014 13:47:06 -0400 [thread overview]
Message-ID: <CAGhGL2CsYKZxRAWRbNphtBSjSbu2Uyi00+z5uix3cNHVx+57=A@mail.gmail.com> (raw)
In-Reply-To: <1400688188.27216078@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]
On Wed, May 21, 2014 at 12:03 PM, <dpreed@reed.com> wrote:
> In reality we don't disagree on this:
>
>
>
> On Wednesday, May 21, 2014 11:19am, "Dave Taht" <dave.taht@gmail.com>
> said:
>
> >
>
> > Well, I disagree somewhat. The downstream shaper we use works quite
> > well, until we run out of cpu at 50mbits. Testing on the ubnt edgerouter
> > has had the inbound shaper work up a little past 100mbits. So there is
> > no need (theoretically) to upgrade the big fat head ends if your cpe is
> > powerful enough to do the job. It would be better if the head ends did
> it,
> > of course....
> >
>
>
>
> There is an advantage for the head-ends doing it, to the extent that each
> edge device has no clarity about what is happening with all the other cpe
> that are sharing that head-end. When there is bloat in the head-end even if
> all cpe's sharing an upward path are shaping themselves to the "up to"
> speed the provider sells, they can go into serious congestion if the
> head-end queues can grow to 1 second or more of sustained queueing delay.
> My understanding is that head-end queues have more than that. They
> certainly do in LTE access networks.
>
I have measured 200ms on a 28Mbps LTE quadrant to a single station. This
was using the simplest possible test on an idle cell. Easy to see how that
can grow to the second range.
Similarly, Dave Taht and I took data recently that showed a large
downstream buffer at the CMTS end (line card?), IIRC, it was something like
.25 megabyte, using a UDP flooding tool.
As always, there may be multiple different buffers lurking in these complex
devices, which may only come into play when different parts of them
"bottleneck", just as we found many different buffering locations inside of
Linux. In fact, some of these devices include Linux boxes (though I do not
know if they are on the packet forwarding path or not).
Bandwidth shaping downstream of those bottlenecks can help, but only to a
degree, and I believe primarily for "well behaved" long lived elephant
flows. Offload engines on servers and coalescing acks in various equipment
makes the degree of help, particularly for transient behavior such as
opening a bunch of TCP connections simultaneously and downloading the
elements of a web page I believe are likely to put large bursts of packets
into these queues, causing transient poor latency. I think we'll get a bit
of help out of the packet pacing code that recently went into Linux (for
well behaved servers) as it deploys. Thanks to Eric Dumazet for that work!
Ironically, servers get updated much more frequently than these middle
boxes, as far as I can tell.
Somehow we gotta get the bottlenecks in these devices (broadband &
cellular) to behave better.
- Jim
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
[-- Attachment #2: Type: text/html, Size: 4941 bytes --]
next prev parent reply other threads:[~2014-05-21 17:47 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 22:11 Frits Riep
2014-05-20 23:14 ` Dave Taht
2014-05-21 11:42 ` Frits Riep
2014-05-21 14:51 ` dpreed
2014-05-21 15:19 ` Dave Taht
2014-05-21 16:03 ` dpreed
2014-05-21 16:30 ` Dave Taht
2014-05-21 17:55 ` dpreed
2014-05-21 17:47 ` Jim Gettys [this message]
2014-05-21 17:53 ` Dave Taht
2014-05-21 17:56 ` dpreed
2014-05-21 17:57 ` Jim Gettys
2014-05-21 18:31 ` Dave Taht
2014-05-21 15:07 ` Dave Taht
2014-05-21 16:50 ` Michael Richardson
2014-05-21 17:58 ` David Lang
2014-05-24 14:03 R.
2014-07-25 18:37 ` Valdis.Kletnieks
2014-07-25 21:03 ` David Lang
2014-07-26 11:30 ` Sebastian Moeller
2014-07-26 20:39 ` David Lang
2014-07-26 21:25 ` Sebastian Moeller
2014-07-26 21:45 ` David Lang
2014-07-26 22:24 ` David Lang
2014-07-27 9:50 ` Sebastian Moeller
2014-07-26 22:39 ` Sebastian Moeller
2014-07-26 22:53 ` David Lang
2014-07-26 23:39 ` Sebastian Moeller
2014-07-27 0:49 ` David Lang
2014-07-27 11:17 ` Sebastian Moeller
2014-08-01 4:21 ` Michael Richardson
2014-08-01 18:28 ` Sebastian Moeller
2014-07-25 20:48 ` Wes Felter
2014-07-25 20:57 ` David Lang
2014-07-26 11:18 ` Sebastian Moeller
2014-07-26 20:21 ` David Lang
2014-07-26 20:54 ` Sebastian Moeller
2014-07-26 21:14 ` David Lang
2014-07-26 21:48 ` Sebastian Moeller
2014-07-26 22:23 ` David Lang
2014-07-26 23:08 ` Sebastian Moeller
2014-07-27 1:04 ` David Lang
2014-07-27 11:38 ` Sebastian Moeller
2014-08-01 4:51 ` Michael Richardson
2014-08-01 18:04 ` Sebastian Moeller
2014-08-02 20:17 ` Michael Richardson
2014-08-01 4:40 ` Michael Richardson
2014-07-26 11:01 ` Sebastian Moeller
2014-05-24 14:12 R.
2014-05-24 17:31 ` Sebastian Moeller
2014-05-24 19:05 ` David P. Reed
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGhGL2CsYKZxRAWRbNphtBSjSbu2Uyi00+z5uix3cNHVx+57=A@mail.gmail.com' \
--to=jg@freedesktop.org \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dpreed@reed.com \
--cc=riep@riepnet.com \
/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