Re: [Cerowrt-devel] Cero 3.10.24-5 no longer supports multiple AQMs?

[Richard O <rocon46@hotmail.com>]

> 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
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.

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.

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.

(Sorry, I had to remove all the quoted text. It just wouldn't let me post no
matter what I did.)