gargoyle and fq_codel

[dumas777]

To make a long story short was just going to share after many months of trial and error what I have found to be the best firmware/qos (tried many including, stock, openwrt, cerowrt, etc) solution available for the WNDR3700v2 at least for my family that watches a lot of internet video (long live cutting the cable tv cord) and some gaming. As one can guess it starts with Gargoyle's rock stability and innovative download ACC. For the download I have found I can just use gargoyles QOS solution out of the box except for deleting a few classes and changing the QOS script so that hfsc also uses stab with an overhead of 30 and a linklayer of ATM. This is due to my ADSL modem being on the internet side of the router. Because I am using ACC I set the maximum speed to internet line speed. I have found I can get by with two classes. A general one with wan throughput optimized and bandwidth percent set to %99 and a special one I use only for PS3 gaming triggered by a few udp ports with something like 100 kbps minimum and with a maximum of 500kbps and the percent set to %1. This one is set to minimize RTT when it is active. It is my experience that reducing the number of classes and rules as much as possible decreases latency and is great for a home where you won't have dozens of sources of contention.

I found also for the upload I was better off running a single default class with no rules set to about %90 of my maximum upload. On this single class (I deleted others through GUI) I set up a fq_codel qdisc with no ecn, quantum 400, and a limit of 600 (my upload less than 1Mbps). I also set up the hfsc to use stab with ATM linklayer and an overhead of 30 (much trial and error on that one). I of course did this by modifying the Gargoyle qos script (which I won't post here as my script is for my needs and if I do some nub will ruin their router, its not hard to do just google it). I have found the benefits of fq_codel really outshine sfq on the upload side compared to the download at least on ADSL. SFQ on the download is actually a bit lower latency than fq_codel for my use cases at least on Gargoyle and best of all it gives true bandwidth sharing in the same class. SFQ does ok on the upload side but any one host can pretty much hose itself latency wise by saturating the link. It may not hose it for others but with fq_codel really the only way any host can hose itself or any other host is not only saturating the link but doing so with many many TCP connections like with torrents that aren't controlled well. I don't run many torrents but if I did I would probably setup a bulk class just for them on both the upload and download.

Sorry to be long winded but just an FYI someone may find interesting. The only other change I made to gargoyle was to (probably illegally) boost the 5ghz power significantly using a fairly simple method (patches some kernel modules) described on an openwrt wiki page I won't repeat here.

[pbix]

Thanks dumas777 for this post.

I could not agree more that the simple approach is the best approach especially since Gargoyle already does per IP sharing. Many novices make their lives miserable by specifying many classes and should take note of this post.

I actually have a qos_gargoyle script that replaces the sfq qdisc with fq_codel. I think the fq_codel concept is very interesting. Unfortunately in my tests there is a problem somewhere between fq_codel and hfsc in that statistics are not being tallied correctly and as a result things don't work right. What I have observed is that when fq_codel is used the link limit cap is not respected. I do not know the reason for this and will try again once Barrier Breaker is released.

If you have only one class on the upload side you are not using hfsc at all so you would not notice this problem using fq_codel.

Not sure why you saw improvement modifying ATM link layer. Gargoyle already uses linklayer when PPPoE connections are used. What test results could you share that demonstrate your settings are better?

People who want to try fq_codel in Gargoyle can replace their /etc/init.d/qos_gargoyle.sh scripts with the attached. I will be watching for any comments.

[dumas777]

I also have noticed that the link limit cap on my upload at times gets exceeded but since I set the limit a little more than %10 below the usual maximum which along with the link layer adjustment seems to prevent QOS from breaking down. I have replaced hfsc with htb in the past but disliked that solution for reasons I can't quite remember. As for messing with the link layer my router is not doing PPPoE my DSL modem is (found using the DSL modem as a transparent bridge caused problems especially with a prior version of CeroWrt so decided to let the DSL modem do PPPoE as its what it does best and haven't had problems since) but I still need to limit the connection speed so its measured correctly before it gets to the DSL modem so QOS doesn't break down. My DSL modem QOS is garbage so I have it disabled. Anyway great project. The ACC is IMHO the killer feature that puts Gargoyle over the top.

[usergar]

I've also set my modem to half-bridge mode (letting modem do PPPoE), would that be a reason for ACC not quite working?

How does gargoyle know the link speed in my case, if it does at all, if it isn't doing the login? Can someone explain what the ATM link layer changes might do?

[pbix]

I recommend all users using PPOoE putting their modem in bridge mode. In this way the link layer parameters are correctly applied and port forwards (including uPnP) work properly. Also your public IP address and data show nicely on your Gargoyle Status page.

If you do not care about these features then it obviously does not matter which way you go. Of course if you have the knowledge and the gumption to study, modify scripts and test you can accomplish some/all of these same features without your modem in bridge mode as dumas777 has done. But you will have done a lot of work for no gain in my view.

For the record link layer parameters when used allow the QoS system to properly account for extra bytes added to the data stream by the PPPoE modem. This makes the accounting more accurate and can avoid QoS breaking down before it should, especially when not using ACC. When using ACC QoS will not break down but allocations will still be off some. These parameters have no effect on the actual throughput of the WAN connection its just that the bandwidth may not be allocated between classes as accurately. These parameters have no relation to ACC working or not.

[dumas777]

Yeah basically if you have to ask you probably should be using the dsl modem as a transparent bridge. pbix is right I did have to do things by hand on DSL router which you would get free by using a transparent bridge (this also includes having to setup a manual target for ACC). Can't remember for sure but if I remember right I never did have any MSS issues on Gargoyle using the DSL modem as a transparent bridge like I did some of the other firmwares (also stupid 1492 MTU BS is why PPPoE DSL is dying). In my case I need the DSL router to always be up due to a device plugged directly in feeding info to the power company (very low throughput doesn't affect overall QOS) whereas because I mess with my WNDR3700 and or don't want to be a afraid to reboot it, I don't setup a transparent bridge. Personally also I did find what I believe to be a slight performance advantage not using a transparent bridge but this is probably very dependent on my DSL modem, router (may be due to modem and router sharing load better, or transparent bridge mode being semi borked on my crappy CenturyLink provided modem) and general usage pattern which will vary to others. Also on my DSL modem once you set up a transparent bridge generally requires a 30/30/30 reset to ever log back into the modem which I do want control over. Still if in doubt use the transparent bridge.

[CarpeNoctem]

Sorry to necro, but once I replaced the original script, is it normal to have Congestion Control show as Disabled?

Sorry again, very interested in the topic but not half as knowledgeable as the previous posters.

Also, how would i notice the difference as a layman, mostly interested in online gaming?

[CarpeNoctem]

Asked and answered (well, one question at least)

Renamed it with a typo, all is well.

Second question still remains tho, how would i see the difference between original script and this one?

Thanks in advance.

UPDATE: Sadly if I replace the original QoS script with this one, my WDR 3600 running 1.7.1. goes into a reboot loop. Oh well, thanks anyways.

[pbix]

Yes I have already confirmed the fq_codel does not work on Gargoyle v1.7.x. There is a bug somewhere in it or IMQ. If you want to play with fq_codel on v1.6x that will work with my script.

Don't look for fq_codel to be offered anytime soon since there are no measureable benefits to using in in Gargoyle and problems with using it continue.

[tapper]

Yes I have already confirmed the fq_codel does not work on Gargoyle v1.7.x. There is a bug somewhere in it or IMQ. If you want to play with fq_codel on v1.6x that will work with my script.

Don't look for fq_codel to be offered anytime soon since there are no measureable benefits to using in in Gargoyle and problems with using it continue.

Hi what about sqm_scripts from openwrt can that work in Gargoyle?
The good thing about sqm_scripts is you dont have to set your up and down line speed.