Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
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

  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