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

[Dave Taht <dave.taht@gmail.com>]

On Tue, Dec 24, 2013 at 7:26 AM, Richard O <rocon46@hotmail.com> 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
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html