CoDel - How to use



  • 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.


  • Banned



  • 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.



  • @Harvy66:

    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.



  • @Harvy66:

    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.


  • LAYER 8 Netgate

    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.



  • @Derelict:

    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.



  • @switchman:

    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.


  • LAYER 8 Netgate

    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.



  • @tuffcalc:

    @Derelict:

    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.


  • LAYER 8 Netgate

    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

    ![Screen Shot 2015-02-07 at 10.44.39 AM.png](/public/imported_attachments/1/Screen Shot 2015-02-07 at 10.44.39 AM.png)
    ![Screen Shot 2015-02-07 at 10.44.39 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-02-07 at 10.44.39 AM.png_thumb)



  • 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.



  • @Derelict:

    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.

    While not perfect, it seems CoDel and make things a lot better without any configuration. I would love to see this same test with fq_codel, if we remember by then.  ;D



  • @Harvy66:

    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.

    I just wondered if inputing a number in the Bandwidth box would actually do anything because CoDel is knobless.  It does do something.  It does limit the connection.  (I tested it by limiting my connection severely)  The only reason I wondered if this knob/setting would work is because everything describes CoDel as knobless.  But I also understood that it was an evolution of RED.  RED having all the settings it did I could see that knobless in relation to CoDel ment, no settings but still takes a Bandwidth setting.

    This has, at least, turned into an interesting post with all these result studies.  I may mirror some of the methods and post my results just to compare.



  • I use the bandwidth settings to make sure that my upstream never ever receives data from me faster than it can process it. Even the CoDel people have stated in at least one of their many videos that it is desirable to make sure that your upload speed is slightly less than your actual rated speed. I have 100Mb, so I set it to 96Mb. If your immediate upstream buffer already uses CoDel or similar AQM, then you gain little or nothing, but most ISPs do not implement modern AQMs or any AQM.

    You want CoDel on the egress interface at any junction of a fast and slow interface pairing. Example, if you have a 10Gb interface that feeds into a 1Gb interface, you want the egress side of the 1Gb interface to have CoDel, as that is where the choke point is located. Another more common example would be a 1Gb uplink with 2 or more 1Gb feeds, then you want CoDel on the egress side of the 1Gb uplink.



  • I just found this on their page. They have a whole section in tuning your rate limiter to work best with CoDel. They even warn against using hardware offloading because stuff like TSO can ignore your rate limiter, causing your interface to send data too quickly.

    http://www.bufferbloat.net/projects/codel/wiki/Best_Practices_for_Benchmarking_CoDel_and_FQ_CoDel

    Broadband Links
    Fq_codel runs extremely well on asymmetric links such as your commonly available 24.5/5.5 service from a cable modem provider like Comcast. (in conjunction with setting a shaper to your providers's rates and htb rate limiting)

    Lastly, just running fq_codel by itself, does not help you very much when the next device in line is overbuffered (as in a home router next to today's cable modems). (it DOES help break up microbursts, however, and generally "does no harm") In that case, using HTB to rate limit your router to below the next gateway device and then applying fq_codel will work. See the note above about limitations to HTB.



  • Just another cent that keeps me wondering…..

    Basically both WAN and LAN are using Scheduler Type: HFSC . ( see attached pf1.jpg)
    But all its children (qACK, qDefault,qP2P…etc) are using Scheduler Options: Codel Active Queues (attached pf2.jpg)

    =========================================
    pfctl -sa

    ALTQ:
    queue root_vmx2 on vmx2 bandwidth 1Gb priority 0 {qLink, qInternet}
    queue  qLink on vmx2 bandwidth 976.50Mb qlimit 500
    queue  qInternet on vmx2 bandwidth 23.50Mb hfsc( codel upperlimit 23.50Mb ) {qACK, qP2P, qVoIP, qOthersHigh, qOthersLow, qDefault}
    queue  qACK on vmx2 bandwidth 5.88Mb hfsc( codel )
    queue  qP2P on vmx2 bandwidth 2.35Mb hfsc( codel )
    queue  qVoIP on vmx2 bandwidth 96Kb hfsc( codel realtime 96Kb )
    queue  qOthersHigh on vmx2 bandwidth 8.22Mb hfsc( codel )
    queue  qOthersLow on vmx2 bandwidth 1.18Mb hfsc( codel )
    queue  qDefault on vmx2 bandwidth 3.52Mb hfsc( codel default )
    queue root_vmx0 on vmx0 bandwidth 1.14Mb priority 0 {qACK, qDefault, qP2P, qVoIP, qOthersHigh, qOthersLow}
    queue  qACK on vmx0 bandwidth 285Kb hfsc( codel )
    queue  qDefault on vmx0 bandwidth 171Kb hfsc( codel default )
    queue  qP2P on vmx0 bandwidth 114Kb hfsc( codel )
    queue  qVoIP on vmx0 bandwidth 96Kb hfsc( codel realtime 96Kb )
    queue  qOthersHigh on vmx0 bandwidth 399Kb hfsc( codel )
    queue  qOthersLow on vmx0 bandwidth 57Kb hfsc( codel )
    =========================================

    Does this best-of-both-worlds "hybrid" setup actually works for more granular control?






  • @chrislee

    Yes. CoDel manages queue latency and HFSC manages queue bandwidth. The other thing to remember is that any queue that is not using all of its bandwidth should effectively have "0'" latency. So if I give my qGames 5Mb of bandwidth, but it is only using 4Mb, then the latency should be 0, except for microbursts.

    CoDel only really helps when you do not have enough bandwidth. Technically, enabling CoDel on every queue is probably a good thing, but some traffic types tend to be low or fixed bandwidth and I see no reason to use CoDel if I've given them enough real time.

    HFSC and CoDel used together really shines when you are using all of your bandwidth and you want to keep all queues low latency, even bulk data queues, like web traffic. You might have web traffic set with lower bandwidth than VPN traffic, but web traffic can be bursty or consume large amounts of bandwidth for long periods of time. CoDel is great for this because it keeps web traffic low latency and responsive for users attempting to browse while allowing good bandwidth utilization for file transfers.

    HFSC is not as good as a simple priority queue if your link bandwidth is not stable because HFSC does not dynamically adjust to changing bandwidth conditions.

    fq_CoDel will be that much better once available.



  • I am going to put this in place for my configs I use at LAN parties. Going to test at home then apply to the routers used for the LAN's.

    I use the following queues for high traffic - qGames and qHTTPSteam so using CODEL on them should have the desired effect as they are commonly the most used queues.

    Next LAN isnt' until March but I might be able to squeeze some testing in at a smaller event in Feb.



  • @Harvy66:

    fq_CoDel will be that much better once available.

    Have the developers indicated they plan on supporting fq CoDel in pfSense.  I have not seen any post that they are.  I probably should set up HFSC plus CoDel .  Today I just have CoDel applied to the lan and wan ports with no other traffic shaping. This way at least my traffic is dynamically reacting to congestion in the network.

    During prime time, I can see the slow down.  If I have a lot off file transfers happening, I can see the link speed up as it gets later in the night.  By about 10:30, my link is running a full speed and can pull a sustained 100/5 transfer either direction.

    Fq CoDel would be a great solution as it is adaptive.  I really hope it gets implemented.





  • @Harvy66:

    @switchman

    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).



  • @tuffcalc:

    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.



  • @tuffcalc:

    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.



  • @Harvy66:

    @tuffcalc:

    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…



  • @tuffcalc:

    @Harvy66:

    @tuffcalc:

    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?



  • @Harvy66:

    @tuffcalc:

    @Harvy66:

    @tuffcalc:

    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+ms

    4. 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 80ms

    So 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.



  • @tuffcalc

    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.


  • Rebel Alliance Developer Netgate

    @tuffcalc:

    @Harvy66:

    @tuffcalc:

    @Harvy66:

    @tuffcalc:

    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+ms

    4. 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 80ms

    So 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.



  • @jimp:

    @tuffcalc:

    @Harvy66:

    @tuffcalc:

    @Harvy66:

    @tuffcalc:

    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+ms

    4. 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 80ms

    So 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.


  • LAYER 8 Netgate

    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?



  • @Derelict:

    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


  • LAYER 8 Netgate

    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.


  • LAYER 8 Netgate

    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.)