CoDel - How to use
-
“CoDel Active Queue Management
The CoDel Active Queue Management (AQM) discipline was recently added to pfSense 2.1. The name is short for Controlled Delay and is pronounced "coddle". It was designed to combat some of the problems associated with bufferbloat in networking infrastructure. Bufferbloat is described in detail at http://www.bufferbloat.net/projects/bloat/wiki/Introduction. Basically, due to the size of buffers in network equipment, traffic can pile up and go in chunks rather than a smooth stream. By controlling the delay of the traffic this effect can be lessened.
CoDel has no specific configuration controls or options. When activated for a queue, it will automatically attempt to manage traffic as described in the CoDel wiki at http://www.bufferbloat.net/projects/codel/wiki. It attempts to keep traffic delays low but does permit bursting, it controls delays but it does not pay attention to round-trip delay, load, or link speed, and it can automatically adjust if the link speed changes.
The target for CoDel is mid-range networking. It does not work well at very low bandwidth (512Kbps or less) and it does not gracefully handle large numbers of simultaneous flows or datacenter-grade traffic loads.”
Excerpt From: Christopher M. Buechler. “pfSense-2.1-book.epub.” iBooks.
They haven't yelled at me for excerpting the book yet. It really is worth the cost of a Gold membership. If you want more than that, I suggest opening a support ticket.
-
I submitted a ticket but it asks me to login to view it now. I do not have an account and I see no where to register.
https://portal.pfsense.org/support/index.php?/Tickets/Ticket/View/OMS-55668
-
You have to pay for support.
I see you were unsatisfied with the answers here and have now gone to the mailing list too.
Do you really want someone to spend their time rewriting the bufferbloat.net site just for you.
You just enable codel. That's it. What's so hard to understand?
-
The only reason that I am perusing the issue is because there are conflicting views of how the webui implements the settings put in along with it. I see when I do implement it that it only enables one scheduler so I will have to assume that putting anything in along with the codel setting for the traffic shaper for just an interface does nothing.
Just because bufferbloat says that it is parameterless does not mean that the parameters do nothing in the pfsense webui.
This is the only question I have. If it follows what bufferbloat says then nothing on a Traffic Shaper interface page should matter if I select CoDel.
I suppose instead of asking in this forum, irc, and a mailing list I will just look at the web form code and dig into it myself.
Thanks for the help, but even this forum post shows people are confused on how it works in pfsense.
The point is, I have to assume. I have spent many hours asking around if anyone knows how that single page works because I did not assume that it works someway.
Maybe I should get a gold subscription but you know what: The guide does not say much about it either.
-
OMG.
1/ Go to Firewall - Traffic Shaper - By Interface
2/ Click your WAN
3/ Check Enable/disable discipline and its children, select CODELQ from Scheduler Type dropdown.
4/ Click Save.
5/ Click Apply.What guide you need for this?
-
He's talking about it is of my opinion that CoDel won't be as effective if you don't set your interface bandwidth. It is logically impossible for CoDel or other forms of traffic shaping or queue management to work without having some means of knowing how quickly the queue should be drained. This is easy for a synchronous interface like plugging a 1Gb WAN into a 1Gb internet connection, but it is not so simple when you plug a 1Gb wan into a 30Mb internet connection. If your upstream does something like sending back pause frames, the WAN port can know to back off, allowing packets to buffer and CoDel to do its magic. Pause frames still mean that buffering is happening on the receiving interface, which is not desirable because you cannot control buffers in other systems.
CoDel doesn't need to know the bandwidth because it's the interface's job to know how fast it's allowed to dequeue. CoDel just monitors the delays on the packets. Without something to limit CoDel, it will dequeue at full interface rate.
-
This thing is "no knobs" by design. https://tools.ietf.org/html/draft-ietf-aqm-codel-00#section-4.2
-
But many think "no knobs" or needing to tell CoDel about your bandwidth means you don't need to rate limit your interface so your interface doesn't attempt to dequeue packets at line rate. CoDel tells your interface which packet to dequeue next, not how fast to dequeue them.
-
But many think "no knobs" or needing to tell CoDel about your bandwidth means you don't need to rate limit your interface so your interface doesn't attempt to dequeue packets at line rate. CoDel tells your interface which packet to dequeue next, not how fast to dequeue them.
I'm using CoDel and see no difference setting my line rate or leaving it blank. On a 30/5 Mbps connection. Love it so far, even with VoIP.
-
What happens when you completely max out your upload? If CoDel is fully working, your latency should barely budge, maybe an increase of 10-15 ms, but minor packet loss.
-
What happens when you completely max out your upload? If CoDel is fully working, your latency should barely budge, maybe an increase of 10-15 ms, but minor packet loss.
That's exactly what is happening.
My main issue was maxing out my download connection (newsgroups) causing latency on my home network. Now it doesn't matter how bad I saturate upload/download, VoIP works and web browsing (latency) is snappy. Very impressed.
-
Strange since codel works on the sending interface. Hard to believe your bottleneck was LAN, but glad it's working for you.
-
You apply codel to both lan and wan. That way it shapes traffic both directions. Even though logic says that if the packet has already made it to you, you should keep it. But if you drop it, that causes a resend which in turn causes the remote end to slow down the sending which then allows packets from other flows to traverse the queue faster.
Admittedly, as the lan is typically faster than the wan, there should not be any slow down or drops. But I applied codel to both lan and wan.
-
Strange since codel works on the sending interface. Hard to believe your bottleneck was LAN, but glad it's working for you.
The heavy downloading (30 simultaneous newsgroup connections) lagged my home network web browsing likely because of the uplink ack packets it needed to send to sustain the speed.
In any event, I've enabled codel on both my wan/lan and it has totally changed the experience.
-
@ tuffcalc,
You might want to drop the number of newsgroup connections in half. Depending on you newsgroup provider, they may be able to fill a smaller number of streams at a higher rate.
-
You apply codel to both lan and wan. That way it shapes traffic both directions. Even though logic says that if the packet has already made it to you, you should keep it. But if you drop it, that causes a resend which in turn causes the remote end to slow down the sending which then allows packets from other flows to traverse the queue faster.
Admittedly, as the lan is typically faster than the wan, there should not be any slow down or drops. But I applied codel to both lan and wan.
I turned codel off on the LAN side and notice no difference.
I'm running an SG300-50P switch with 3 Engenius EAP1750 AP's for wireless clients, so admittedly a pretty fast LAN. I'm just going to leave it off for the LAN side - intuitively it makes more sense to me.
-
I removed all my shapers and applied only codel. My downloads were as fast as I've ever seen them and simultaneous pings to my ISP's first hop were unaffected. Uploads, however, resulted in ping latency going from about 12ms to about 175ms. HFSC completely cures that at the expense of a little top-end speed. I did leave the codel checkboxes checked on all my queues though.
-
Strange since codel works on the sending interface. Hard to believe your bottleneck was LAN, but glad it's working for you.
The heavy downloading (30 simultaneous newsgroup connections) lagged my home network web browsing likely because of the uplink ack packets it needed to send to sustain the speed.
In any event, I've enabled codel on both my wan/lan and it has totally changed the experience.
I don't doubt that it has helped, but I wonder by how much in actual numbers. If you could find an IP that returns table pings, get maybe 30 seconds of samples, then start downloading and get another 30 seconds of samples.
Unfortunately, I cannot do any sort of tests on my network because my ISP has designed their network to have no buffer bloat and stable bandwidth. If I had my old ISP, I could have done such tests. While they were pretty good, they had classical issues of buffer bloat and bandwidth could briefly drop upwards of 30% during peak hours. Nothing horrible, but not "perfect".
I recently watched an interview from one of the CoDel people showing a reduced number of pause frames when using CoDel, but unfortunately did not show his exact network setup or where CoDel was applied, so I made some assumptions that sound as if they are a bit incorrect. The difference between theory and practice, implementation details. Perhaps pause frames are sent some time prior to full buffer.
Thanks for everyone helping to fix some of my false assumptions. There is obviously something more at play that I am missing. I love learning and I apologize for spreading somewhat false information.
-
I use some stuff out of a youtube video.
You run one process that pings 5 per second and outputs to a file.
You run another that plots it with gnuplot.
The video (which includes the very short scripts) is here: https://www.youtube.com/watch?v=EfXImr5q-sw
 -
I wonder if my ISP uses fq_CoDel. This was taken during my recent issue with BitTorrent flooding my connection with up to 103Mb/s, yet my average was 98.6Mb/s as reported by RRD.
Even then, my pings remained low. I cannot think of a way that my pings could remain so low while still maintaining large enough buffers to be practical. Packet loss indicates a full buffer, yet the pings do not reflect such a thing. fq_CoDel is the only algorithm that comes to mind. It was not this way prior to their recent upgrades. Packet loss was typically accompanied by latency, albeit 10-20ms.
edit: Seems Cisco used the idea of CoDel and made PIE. Both are similar. Cisco even has fq_PIE. I assume this is why I see stable latency from my ISP.
