Bufferbloat issue

[jorgemiguel4]

I'm having a bufferbloat issue on download side. ACC won't help


My current setup:
-ADSL 2+ Line at 4096 down /1024 up
-Modem TG516v6 with last firmware available(7.4.4.7).
-Router TL MR3420 with 64MB ram mod and loaded with Gargoyle compiled at 25-03-2013


http://n2.netalyzr.icsi.berkeley.edu/su ... fferResult


Any way to get rid of it?

[BashfulBladder]

Altitude Adjustment has fq_codel, so that should address the issue.

I haven't gone looking into it though.

[jorgemiguel4]

As long as I know I'm using it in my gargoyle version. But it's not doing anything...

[pbix]

The Netalyzr report shows that there is a big buffer out there. There is nothing that anyone but your ISP can do to change the size of that buffer.

This just happens to be the problem ACC was meant to solve. Since we cannot change the size of that buffer ACC instead prevents it from filling thus keeping it from causing you any problems.

fq_codel cannot do what ACC does and only ACC can keep this buffer from troubling you.

The version of fq_codel in AA (and Gargoyle) still has bugs as well so it not yet ready for production in my view.

[jorgemiguel4]

Thanks for the clarification


There are no configurable buffers in modem?

I just want to be sure that the problem is not on my side before contact my ISP.

[dtaht]

Assuming you have fq_codel built, there are two scripts in cerowrt that should work in gargoyle. Both are included in the cerowrt package repository, in the "debloat" package.

https://github.com/dtaht/ceropackages-3 ... et/debloat

The "debloat" script removes various forms of overbuffering all across wifi and ethernet, for all devices.

The simple_qos.sh script enables fq_codel with a rate shaper. When correctly configured (by editing the script to roughly your up bandwidth and a few percentage points less than your down, and to use fq_codel rather than nfq_codel).

I figure with a little fiddling it can be made to work with gargoyle's firewall system.

And you should be able to obtain the kinds of results we've been demonstrating at the ietf and elsewhere.

Please see the presentations recently given at the iccrg:

http://www.ietf.org/proceedings/86/slid ... ccrg-3.pdf

http://www.ietf.org/proceedings/86/slid ... ccrg-0.pdf

Or my recent one at the gathering:

http://www.youtube.com/watch?v=b2vSaUh5gKA

If you have trouble making the simple_qos.sh script work pop into the #bufferbloat channel in irc or the mailing list, and we'll be glad to help.

[dtaht]

btw, I have no idea what ACC is. ?

What I was pointing out is that you CAN take control of both ingress and egress on the buffering side if you are willing to sacrifice a little bandwidth to move control of the buffering into your device, particularly on ingress. 85% works always, some technologies can get closer to 95%.

I also just noticed that the poster is on ADSL, and might need the ADSL code enabled (noted a little further down in the simple_qos script.) I note there are multiple fq_codel enabled shapers out there now, dan seimon has one that's pretty good. I've been trying to bake simple_qos into pure C for a while now...

Lastly, IMHO, fq_codel is not buggy. It can certainly be improved (thus nfq_codel and efq_codel are under test), but the only major issues it has on AA is that it defaults to a 10k packet limit, which is absurdly large and can be safely reduced to 1k or a bit less, and that it defaults to ECN on.

[jorgemiguel4]

Thanks, I will give it a try.

ACC is Active Congestion Control that's part of Gargoyle QoS.

[pbix]

Hi Dave,
I have followed closely your work on fq_codel for the last year or more. I think its based on a great idea in principle and often think about how I could integrate it into Gargoyle and take some advantage of it.

btw, I have no idea what ACC is. ?

What I was pointing out is that you CAN take control of both ingress and egress on the buffering side if you are willing to sacrifice a little bandwidth to move control of the buffering into your device, particularly on ingress. 85% works always, some technologies can get closer to 95%.

Well I encourage you to study ACC. It allows Gargoyle to control bufferbloat issues without sacrificing any speed and without changing anything outside our router. Especially it allows buffer control in the face of varying available download speeds from our ISP which is a fact of life for most of us.

Lastly, IMHO, fq_codel is not buggy. It can certainly be improved (thus nfq_codel and efq_codel are under test), but the only major issues it has on AA is that it defaults to a 10k packet limit, which is absurdly large and can be safely reduced to 1k or a bit less, and that it defaults to ECN on.

I found that at low bit rates (under 1Mbps) there seems to be some accounting errors and this leads to bad decisions by HFSC. At higher bit rates it works OK but latency is not markedly different that our current ACC/HFSC/SFQ setup since we have our buffer under control already. Still I am not against using fq_codel if the issue I saw gets resolved. It could help out on the upload side I think. So what are the advantages of nfq_codel & efq_codel and why do we need them if fq_codel does everything and has no bugs? I would love hear about it but have found very little information on them to date.

Assuming you have fq_codel built, there are two scripts in cerowrt that should work in gargoyle. Both are included in the cerowrt package repository, in the "debloat" package.

For those reading Dave is too optimistic IMHO about his script. Gargoyle is mostly about a user interface and this script will have no knowledge of it or the existing QoS system that Gargoyle has. If you want to experiment with this script it would be best to do it on cerowrt.

[jorgemiguel4]

I have tried OpenWRT with codel, no improvement on netalzr test.