CoDel - How to use
-
Yes, but no ETA
https://forum.pfsense.org/index.php?topic=87931.msg485936#msg485936
I saw that, but I read that as "yea it would be nice", but not firm "yes we are going to to this", now we just need to pick the release.
-
Time for a bounty!
I wouldn't expect it before 2.2.3 at the earliest. Looks like a good backlog of bugs to stomp. It would be nice if it was added to Redmine as a feature request, just so it's official.
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Thats why the developers of CoDel say you should actually deploy FQ-CoDel.
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Try settings your WAN rate to about 95% of your stable upload rate and see what happens.
-
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Try settings your WAN rate to about 95% of your stable upload rate and see what happens.
That fixed it…
Well, 200ms is a lot less than what I thought it would have been, so just enabling CoDel without setting bandwidth is probably doing something, just not as effective as in conjunction with settings your bandwidth.
Just wondering, what was your ping during saturation when you have your bandwidth set?
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Try settings your WAN rate to about 95% of your stable upload rate and see what happens.
That fixed it…
Well, 200ms is a lot less than what I thought it would have been, so just enabling CoDel without setting bandwidth is probably doing something, just not as effective as in conjunction with settings your bandwidth.
Just wondering, what was your ping during saturation when you have your bandwidth set?
I've been all over the place and probably gave some false information (because I am new to this and didn't really understand what I was doing). Anyway, let me try and clear up my findings:
1. No traffic shaping, all bandwidth available - ping 10ms
2. No traffic shaping, download saturated - ping 60ms
3. No traffic shaping, upload saturated - ping 500+ms4. CODEL active with no bandwidth limit set - all pings same as scenarios 1,2 & 3.
5. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, all bandwidth available - ping 10ms
6. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, download saturated - ping 60ms
7. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, upload saturated - ping 50 to 80msSo it does work, although during a saturated upload I notice my VoIP phone going a bit "robotic", but much improved over no traffic shaping (VoIP calls would be largely unusable). Did not have that issue with PRIQ when prioritizing VoIP as first in line. That being said, CODEL is much easier to setup and it looks like it doesn't completely starve other queues like PRIQ. I'm sticking with CODEL.
Interested to see if FQ_CODEL will make my pings even lower. Will test it as soon as it is available in pfsense.
-
Thanks for the info. I've done my fair share of "false" information with good intentions. It happens.
Yes, the whole PRIQ replacement is kind of interesting. The eventual fq_codel will actually do similar things of PRIQ, but better for general usage. Except in the case where you need certain traffic to always get priority, fq_codel will do what most people want, keep latency low without the hassle of floating rules.
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Try settings your WAN rate to about 95% of your stable upload rate and see what happens.
That fixed it…
Well, 200ms is a lot less than what I thought it would have been, so just enabling CoDel without setting bandwidth is probably doing something, just not as effective as in conjunction with settings your bandwidth.
Just wondering, what was your ping during saturation when you have your bandwidth set?
I've been all over the place and probably gave some false information (because I am new to this and didn't really understand what I was doing). Anyway, let me try and clear up my findings:
1. No traffic shaping, all bandwidth available - ping 10ms
2. No traffic shaping, download saturated - ping 60ms
3. No traffic shaping, upload saturated - ping 500+ms4. CODEL active with no bandwidth limit set - all pings same as scenarios 1,2 & 3.
5. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, all bandwidth available - ping 10ms
6. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, download saturated - ping 60ms
7. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, upload saturated - ping 50 to 80msSo it does work, although during a saturated upload I notice my VoIP phone going a bit "robotic", but much improved over no traffic shaping (VoIP calls would be largely unusable). Did not have that issue with PRIQ when prioritizing VoIP as first in line. That being said, CODEL is much easier to setup and it looks like it doesn't completely starve other queues like PRIQ. I'm sticking with CODEL.
Interested to see if FQ_CODEL will make my pings even lower. Will test it as soon as it is available in pfsense.
Out of curiosity, which exact places do you have CoDel active for? As the shaper discipline for the interface, or using HFSC with "Codel Active Queue" on specific queues? And if the latter, which queues?
The more good/working examples we can get the better, I can put them up on the wiki for future reference.
-
I take back what I said about Codel. When I saturate the upload fully for a long period of time my pings still shoot through the roof (200+ ms).
Try settings your WAN rate to about 95% of your stable upload rate and see what happens.
That fixed it…
Well, 200ms is a lot less than what I thought it would have been, so just enabling CoDel without setting bandwidth is probably doing something, just not as effective as in conjunction with settings your bandwidth.
Just wondering, what was your ping during saturation when you have your bandwidth set?
I've been all over the place and probably gave some false information (because I am new to this and didn't really understand what I was doing). Anyway, let me try and clear up my findings:
1. No traffic shaping, all bandwidth available - ping 10ms
2. No traffic shaping, download saturated - ping 60ms
3. No traffic shaping, upload saturated - ping 500+ms4. CODEL active with no bandwidth limit set - all pings same as scenarios 1,2 & 3.
5. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, all bandwidth available - ping 10ms
6. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, download saturated - ping 60ms
7. CODEL active (WAN side only) with bandwidth limit set at 98% of uplink speed, upload saturated - ping 50 to 80msSo it does work, although during a saturated upload I notice my VoIP phone going a bit "robotic", but much improved over no traffic shaping (VoIP calls would be largely unusable). Did not have that issue with PRIQ when prioritizing VoIP as first in line. That being said, CODEL is much easier to setup and it looks like it doesn't completely starve other queues like PRIQ. I'm sticking with CODEL.
Interested to see if FQ_CODEL will make my pings even lower. Will test it as soon as it is available in pfsense.
Out of curiosity, which exact places do you have CoDel active for? As the shaper discipline for the interface, or using HFSC with "Codel Active Queue" on specific queues? And if the latter, which queues?
The more good/working examples we can get the better, I can put them up on the wiki for future reference.
It's active only for the shaper discipline for the WAN interface.
-
It's active only for the shaper discipline for the WAN interface.
OK. Now I'm confused. If codel has no knobs, what is actually doing the shaping based on the bandwidth value?
-
It's active only for the shaper discipline for the WAN interface.
OK. Now I'm confused. If codel has no knobs, what is actually doing the shaping based on the bandwidth value?
CoDel is not a traffic shaper, it does not do any rate limiting, that is the job of your rate limiter. All CoDel does is figure out which packets to dequeue next or which to drop.
See my quotes from the makers of CoDel
https://forum.pfsense.org/index.php?topic=88162.msg488220#msg488220
-
Exactly.
The question I have is why tuffcalc sees a difference in behavior when he sets a bandwidth value of 98% of his upload when his scheduler type is CODELQ?
As I understand codel, it should make no difference, so what is actually doing the shaping? Is it built into altq itself absent any HFSC, PRIQ, etc?
-
Ahh.. I assumed PFSense/FreeBSD had a built in interface rate limiter that functioned separately of queue management like AQMs or shapers. To me, they are all orthogonal problems. The interface can be rate limited and not care about how queues are implemented, how many queues there are, or which queue to dequeue next. Traffic shapers can decide which queues to pull from and how fast to dequeue those queues, and AQMs can decide which packet to dequeue from a given queue.
Interface->InterfaceRateLimiter->TrafficShaper(HFSC)->AQM(CoDel)
Like a pipeline, with none needing to know anything about the others. Not to say this is how it is implemented, but it could be implemented this way as none of them have any overlap or unique dependencies on each other. Some traffic shapers may need to know how fast to expect the interface to dequeue from them. HFSC might not actually be really "limiting", it might be just "scheduling", while the interface limiter might be doing the limiting. I'm not sure about implementation details, just looking at it from an abstract point of view and what could be done. I am ignoring the fact that HFSC does have the notion of an upper bound, but ignoring that, pretty much all other features of HFSC could be done without any rate limiting, only scheduling.
-
This is what I get when I set scheduler type to CODELQ and a 900Mbit bandwidth:
altq on em0_vlan1003 codelq bandwidth 900Mb queue
Absent any other requirements, that is probably sufficient to eliminate any buffer bloat one might have at their ISP (assuming bandwidth set to about 90-95% of reasonably-expected uplink.)
-
This is a very informative thread, I've been searching this forum on general traffic shaping methods / tricks and I've bookmarked a couple of threads including this one…I'm yet do to my setup, I like doing the research first so I can have an idea of what I'm dealing with.
I have a question tho'; from what I read CoDel is only meant to work (well) with high speed connections? 2.5mbit and above?. I'm currently using a very low ADSL connection 1770kbps down 550kbps up (thats what I get from speedtest although the ISP sells as 2mbit down 1mbit up), would CoDel work for me with this speeds?
I'm looking to upgrade to 10mbit down 2.5mbit up soon but I kindly need to know if CoDel would work for me with my current speeds.
Another question is; I'm I right to assume that CoDel can work side to side with PRIQ and the Limiter (I intend to use the Limiter to implement share bandwidth evenly on LAN as foxale08 has illustrated here; https://forum.pfsense.org/index.php?topic=63531.0 )
Regards.
-
This is a very informative thread, I've been searching this forum on general traffic shaping methods / tricks and I've bookmarked a couple of threads including this one…I'm yet do to my setup, I like doing the research first so I can have an idea of what I'm dealing with.
I have a question tho'; from what I read CoDel is only meant to work (well) with high speed connections? 2.5mbit and above?. I'm currently using a very low ADSL connection 1770kbps down 550kbps up (thats what I get from speedtest although the ISP sells as 2mbit down 1mbit up), would CoDel work for me with this speeds?
I'm looking to upgrade to 10mbit down 2.5mbit up soon but I kindly need to know if CoDel would work for me with my current speeds.
Another question is; I'm I right to assume that CoDel can work side to side with PRIQ and the Limiter (I intend to use the Limiter to implement share bandwidth evenly on LAN as foxale08 has illustrated here; https://forum.pfsense.org/index.php?topic=63531.0 )
Regards.
Answer to your first question: No (but it couldn't hurt to try… :))
If you check CoDel's official site you would see that there are a few known problems. Here is a quote from http://www.bufferbloat.net/projects/codel/wiki/Wiki/
At very low bandwidths (e.g. .5Mbps) on ADSL, we're having to play with the target; Kathie did not have to in her simulations. This is due to inevitable buffering
in htb or in the device driver. We have a version under development that does bandwidth limiting without buffering an extra packet, called cake. It's looking good so far.The quote mentions "playing with the target", but this level of configuration is only available in the Linux kernel's Codel/fq_codel implementation (please correct me if I am wrong). I am assuming they mean target delay. Please refer to to the following link for more information: http://man7.org/linux/man-pages/man8/tc-fq_codel.8.html
Regarding your second question; I have only used Codel as a stand-alone queue, never as part of another queueing algorithm like PRIQ or HFSC. I have no reason to think it wouldn't work though. Make sure to reset the firewall states and test your queueing configuration to confirm that it is working as expected.
-
I use Codel in conjunction with HFSC on my 100/100 connection. In theory they're independent of each other. HFSC schedules which queue to dequeue and Codel deiced which packets to dequeue or to drop.
In practice, I never see any packets dropped according to the queue statistics, but I also never see any measurable latency spikes.
I'm not sure of a goad way to load test because my connection is "too" stable.
It is possible that if HFSC isn't "smooth" enough at interleaving the queues, a queue could wait longer than what Codel wants and could create packetloss when there isn't any real congestion, but HFSC seems like freaking magic. I assume bad things could happen with an older machine with 10ms timers or 10/40Gb interfaces that have fq_Codel tuned for 0.5ms, which is recommended for those rates. but right now, we do not have fq_codel nor do we have a way to tweak the target delay via the interface.
-
Here is how I have mine setup for testing right now:
