From: Dave Taht <dave.taht@gmail.com>
To: Jim Gettys <jg@freedesktop.org>
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 10:53:29 -0700 [thread overview]
Message-ID: <CAA93jw6kN4zW-7knj3PxvObcaZ7LweJuaO19Ga6h_9R+wR3NLw@mail.gmail.com> (raw)
In-Reply-To: <CAGhGL2CsYKZxRAWRbNphtBSjSbu2Uyi00+z5uix3cNHVx+57=A@mail.gmail.com>
On Wed, May 21, 2014 at 10:47 AM, Jim Gettys <jg@freedesktop.org> wrote:
>
>
>
> 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.
No it was twice that. The udpburst tool is coming along nicely, but still
needs some analytics against the departure rate to get it right.
> 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.
Or we can take a break, and write books about how we learned to relax and
stop worrying about the bloat.
> - Jim
>
>>
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
next prev parent reply other threads:[~2014-05-21 17:53 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
2014-05-21 17:53 ` Dave Taht [this message]
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=CAA93jw6kN4zW-7knj3PxvObcaZ7LweJuaO19Ga6h_9R+wR3NLw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=jg@freedesktop.org \
--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