On Tue, Dec 24, 2013 at 7:26 AM, Richard O <[email protected]> wrote: >> Dave Taht <dave.taht <at> gmail.com> writes: >> >> >> Just a pair of quick comments on something you said below. I'll look >> over your scripts later. >> >> There is PLENTY of sense in shaping inbound traffic. Inbound is the >> bulk of the problem in many cases - verizon has 300ms of inbound >> buffering in their 25/25mbit service, and comcast often well over a >> second on their 25Mbit/4. (and often over a second on outbound but the >> new modem I've been testing is only about 200ms. But the bulk of the >> delay is on inbound, by far) >> >> comcast shaped only on inbound: >> >> >> > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/oneway/149.20.63.30.rrul-ethernet-ecn.svg >> >> comcast unshaped entirely exhibits almost 2 seconds of delay before it >> starts dropping packets. >> >> >> > http://snapon.lab.bufferbloat.net/~cero2/armory.com/unshaped/149.20.63.30.rrul-comcast_unshaped.svg >> >> UGH! This is the kind of performance cable users have to deal with! I >> hope the CMTS folk get their act together soon. >> >> And the normal glorious post >> whatever-the-heck-we're-going-to-call-aqm-scripts-ceroshaper result: >> >> >> >> > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/149.20.63.30.rrul_noclassification-ethernet-ecn.svg >> >> So... a lot of people keep insisting that "shaping inbound doesn't >> work" on the client device, and it just aint true. I had hoped to just >> be able to fix the cable modems in docsis 3.1, but that isn't going to >> be what happens, sadly. >> >> Sure: a primitive use of a policer doesn't work well (see wondershaper >> result below), but attaching htb + fq_codel on ingress works fine. >> Perhaps we need to collect a wide swath of results from tools like >> netanalyzer, too? with inbound and outbound enabled/disabled in >> combination? >> >> What might have caused confusion? is that I generally enable ECN on >> inbound so that ECN compliant streams don't get their packets dropped, >> but marked, when it's time to slow down. (Very little traffic >> is ECN marked.) >> >> Anyway, I recently went through a round of tests of 2.10.24, realizing >> only later that the instruction trap error was skewing the data on >> some tests. There are some new results. >> >> This is wondershaper on a 25Mbit/4Mbit comcast service. The inbound >> policer drops far too many packets to get even half the allocated >> bandwidth. (Wondershaper has many other problems. It needs to die!) >> >> >> >> > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/149.20.63.30.rrul-wondershaper.svg >> >> I do not know to what extent DPI is used to mess with torrents, but I >> got a good 50 client download going of ubuntu and still had very good >> performance for normal tcp, and web pages are pretty good, too. >> >> http://snapon.lab.bufferbloat.net/~cero2/armory.com/with_torrent/ipv4-2.svg >> >> (as always these dirs contain far more data than just what I'm cherry >> picking above, notably a bunch of simpler tcp up/down/bidir plots. >> feel free to move around) >> >> > Wow, those RRUL graphs show some interesting stuff. It's cool to know
I should do a lecture on all the useful stuff a practiced eye can see with them. That said, they are terribly noisy and an unpracticed eye often mis-interprets the peaks and valleys. > fq_codel does everything really well, and I had no idea fq_codel can still > differentiate between UDP EF traffic and UDP BE traffic w/o having to > prioritize them into different htb leafs first. I guess that kinda makes my > classification rules redundant, I suppose. No, presently fq_codel does not prioritize diffserv into different htb leaves. That is the "simple.qos" script doing that. "simplest.qos" doesn't. I have generally found that simplest does a pretty darn good job... but I strongly suspect prioritization at your bandwidth levels is required. Someday, perhaps, we'll pour this into c, and make something faster than htb. I have some thoughts towards doing that.... Please feel free to try simplest.qos in your environment, though. > Anyway, I got the idea shaping inbound traffic didn't do much while I was > looking up about what Cero and fq_codel was about waaay back when I was > deciding on whether I should try it out. I'm not sure which forum I stumbled > upon, learning that particular bit of information, but that's all I took > from it. It's good to know I was wrong. I have spent a ton of time correcting websites. (I run a regular google search for bufferbloat but it doesn't catch everything) I wish it were possible to update the lart stuff, like the howtos - they are impossibly outdated and the first hits you get point to things that are massively wrong for todays environments, like wondershaper. Recently I spent some time fixing this script, for example. As posted originally it was just so terribly, terribly wrong. https://wiki.gentoo.org/wiki/Traffic_shaping > Also, you don't have to bother looking at my script. Everything works as > well as I could hope for and I'm sure you have much more important things to > be focused on. Again, thanks for taking the time to help out a smuck like me. No, I always learn things from how people do stuff differently. I ended up writing a bit of a rant on wondershaper while I looking at yours, in a weird sort of result. In your case I have a couple thoughts. I think there is a strong need, particularly at low bandwidths, to have some ability to strongly prioritize a given host's packets (gaming boxes being the most important) and that ability isn't in cero. I can be faulted for mostly testing at 20/4 mbit and above, since that's what I have, and the way the world is going... prioritization counts for much less then, and packetization helps ever more. > (Sorry, I had to remove all the quoted text. It just wouldn't let me post no > matter what I did.) > > > > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
