Joined: 26 Sep 2007 Posts: 67 Location: Fresno, CA
Posted: Sun Apr 28, 2013 3:46 Post subject:
Here's what I've gathered by "Googling them and studying":
SFQ = the original queueing mechanism for QoS.
This is a new option in the control panel, after all (and still undocumented in the sidebar "help"). So we can assume that FQ_CODEL and CODEL are related.
CODEL seems to be a new QoS implementation (within the past year from Googling). FQ_CODEL seems to be the name of a Wiki page I stumbled across calling itself "CODEL" but refers to the method itself as "fq_codel".
So, using this information, I selected FQ_CODEL. Websites now load comically fast. Haven't done much testing yet, but the result is definitely not negative. Even on my (newly discovered via direct-plug SpeedTest) 55mbps down/10mbps up Comcast connection _________________
Just reviving this thread as I have been doing much research in this subject today. There are some great lectures by one of the Codel developers to a university explaining how codel works.
Fq_codel is a hybrid between sfq and codel, but there is a lot of nay sayers about codel algorithum using wifi as wifi has it's own buffer queue system that almost negates the codel algorithum. Mix that with modern programs using multiple tcp streams and this also lowers codel's effectiveness. Fair queuing codel and normal codel work off the same idea of packet queuing.
Sfq is the original that was developed way back n the 80's but in my humble opinion is the best option for wifi qos, as it's plain and simple and uses less CPU and it's the most effective at not letting one person hog all the bandwidth.
The ddwrt wiki on qos is horrible, saying to use Hfsc scheduler with fq_codel with a lot of outdated info. Htb scheduler is what you want to back down bandwidth. Codel is only designed to try and prioritize low latency, low bandwidth apps like VoIP and DNS. But if you have pele bittorrenting and downloading a lot you want to back the bandwidth off, and in that case htb is the best scheduler and sfq the best queuing discipline. (which I think is why brainslayer keeps those the default)
If any experts would like to correct any of my understanding of this I would welcome it.
Posted: Wed Apr 02, 2014 17:52 Post subject: some bits about fq_codel and codel
Thank you for the kind words on the various "bloat-videos".
In one of the early lectures I characterized fq_codel as a blend between SFQ and codel. It's more like DRR, codel, with a core bit thrown in from SQF. (we had just spent 9 months trying to get SFQ to scale up and I'd had SFQ on the brain)
We've finally produced internet drafts for this stuff for the ietf, where we hope we've got it exactly right:
1) SFQ is definitely not the best choice for wifi. Neither is fq_codel in it's current form, as the underlying buffers in the wifi stack are generally too huge, txops are mishandled, 802.11e is busted, and how packet aggregation is done is too haphazard, and a raft of other problems that the bufferbloat project has been seeking funding for years to resolve. (see what's wrong with wifi talk at mit)
We do get very good results from fq_codel on a wifi station, but not as good as we'd like, and better than SFQ in most cases. APs not so much.
2) Most of our early testing of codel and fq_codel algorithms focused on systems in the 4Mbit to 10Gbit range.
Only later did we realize that some tuning was needed below 2.5Mbits, and also that HTB was horribly broken in terms of DSL/PPOe compensation until about 3.10.12. So first, fix DSL compensation, second, at least with htb, we are finding it
necessary to increase the fq_codel target and interval to account for 1 MTU worth of data
(this is partially due to an interaction with htb which
buffers up an extra packet that didn't show up in the models)
I suspect brainslayer and many other dd-wrt users are working mostly below 4mbits. Below 4Mbits SFQ remains a pretty good choice. Below 768k I think it is the best choice (if you disable permutation). However I think fq_codel target X quantum 300 is pretty comparable to SFQ down to this lowest level, with some benefits from the "fast queue" idea that make it perform better in the general case.
Here's a recent rrul test comparing sfq and fq_codel behaviors at 8mbit.
Although cerowrt is testing a sfq+codel-like thing called nfq_codel thus far the results haven't been worthy enough to publish. Frankly there are so many constants like iw10, and 1500 byte MTUs etc, which I point to in the wondershaper rant below, messing up peoples lives that I hope 1mbit links go the way of the dodo soon.
Above 2mbits and certainly above 10mbits it makes increasing amounts of sense to use fq_codel (with a small quantum 300). Above about 40mbit, no need to fiddle with the quantum...
For some analysis of wondershaper's behavior at various speeds, see:
But fixing the DSL atm cell compensation was very important, and the code for using it right in cerowrt's SQM system was just submitted to openwrt head.
I hope that other QoS systems like those in dd-wrt can adopt some of these techniques.
2) I honestly have no opinion regarding hfsc. It drops and schedules packets in it's own way that is exceedingly hard to analyze and understand, so we worked on improving htb + fq_codel which was much more predictable. I would like benchmarks, such as the rrul benchmark suite, taken against dd-wrt's hfsc system at various bandwidths, notably on cable.
"Codel is only designed to try and prioritize low latency, low bandwidth apps like VoIP and DNS. But if you have pele bittorrenting and downloading a lot you want to back the bandwidth off, and in that case htb is the best scheduler and sfq the best queuing discipline. (which I think is why brainslayer keeps those the default) "
Um, no. Codel is designed to keep tcp friendly flows like cubic tcp with a low minimum queue size and minimal delay, without compromising goodput. fq_codel is designed to optimize for "sparse" flows - like voip and dns - while still giving elephant flows full goodput and low delay with codel.
In terms of dealing with bittorrent it is remarkable how well you can do without any classification at all with just a single tier of htb rate limited bandwidth + fq_codel, but IF you have the classification chops you can benefit from a 3 tier fq_codel model of priority, best effort, and background queues.
I do hope others continue to experiment in these areas notably with things like weighted fair queuing and different control laws for fq_codel! We are far from done yet and I would like to include dd-wrt's systems in an upcoming internet draft:
