On Wed, May 21, 2014 at 10:47 AM, Jim Gettys <[email protected]> wrote: > > > > On Wed, May 21, 2014 at 12:03 PM, <[email protected]> wrote: >> >> In reality we don't disagree on this: >> >> >> >> On Wednesday, May 21, 2014 11:19am, "Dave Taht" <[email protected]> >> 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
