CoDel - How to use
-
I think I get it.
Part of my confusion stemmed from when I tested CoDel, it caused my upload/download to drop to ~75% of my maximum bitrate and the throughput was unsteady. I never experienced this problem with "regular" queues. This caused me to assume that CoDel was doing something extra (shaping) to keep my queueuing delay low. Without CoDel, I achieved the bitrate assigned to the interface.
I now realize that CoDel should not have acted that way. I will need to revisit CoDel and see if I get the same results again.
My real-world internet speeds are 6.34Mb/666Kb.
Did you set an upload bandwidth limit? Set it at 95% if 666Kb and have another run at it.
-
I think I get it.
Part of my confusion stemmed from when I tested CoDel, it caused my upload/download to drop to ~75% of my maximum bitrate and the throughput was unsteady. I never experienced this problem with "regular" queues. This caused me to assume that CoDel was doing something extra (shaping) to keep my queueuing delay low. Without CoDel, I achieved the bitrate assigned to the interface.
I now realize that CoDel should not have acted that way. I will need to revisit CoDel and see if I get the same results again.
My real-world internet speeds are 6.34Mb/666Kb.
Did you set an upload bandwidth limit? Set it at 95% if 666Kb and have another run at it.
I did. I usually set to less than 600Kbit. CoDel's official site states that <768Kbit connections are troublesome.
Though, the reason for my download falling from ~730kB/sec without CoDel to ~500kB/sec with CoDel is still unknown to me. I had this type of result numerous times.
I may have misconfigured something back when I tested. Hopefully that explains it… :)
I used the CODELQ setup, not the "Codel Active Queue" check-box.
-
Codel uses a target of 5ms, which at 768Kb/s is only 480bytes. This means a single 1500byte packet will cause Codel to want to start dropping packets. On my 100Mb connection, 5ms is 62,500 bytes, which is nearly 42 1500 byte packets. A single 1500 byte packet is 5ms at 2.4Mb/s. May be best to recommend Codel to be only implemented on 3Mb/s+ connections. fq_Codel probably wouldn't fair much better for bandwidth utilization, but would do better for not dropping small packets that immediately followed a 1500byte packet.
I think I remember reading that 10Mb+ is recommended for Codel, but I'm not sure if that was an official value or just an easy to remember number given as a rule of thumb.
Anyway, 1500 bytes is way to large for slow connections when latency is an issue.
edit: I think the 10Mb comment was in reference that 5ms is not optimal for connections below 10Mb, but not to say it won't work. I assume there is a lower bound where Codel is definitely not good, like the 657Kb someone else said they read or the 2.4Mb/s rate required to transmit 1500 bytes in 5ms.
-
I just tried the "Codel Active Queue" on my outgoing bulk HFSC queue and it worked like a charm. Dropped my average queue size from ~30 to ~1 and dropped my ping from ~600ms to ~50ms during a single stream upload.
Now I need to test out FAIRQ with Codel check-marked to see how that setup deals with multiple concurrent streams.
-
Hmm… I just ran into an unexpected negative side-effect of CoDel. I knew it had some drawbacks. ;)
I check-marked Codel on my WAN HFSC qBulk queue, that was configured to have an increased worst-case delay with link-share [0Kb, 25, 300Kb], so other packets would be prioritized. It also had a queue limit of 500, so that if things got bad, it could just queue up packets and let the delay climb, but. CoDel won't allow that, because it keeps the packet queueing delay at 5ms… right?
Without much consideration, I excitedly chose to decrease the delay of the my greediest queue to resultingly decrease the delay of all other queues. Dumb... I think I should have taken the more direct route of exclusively decreasing the delay of the non-qBulk queues, leaving qBulk to become backlogged and delayed as it increasingly yields to packets with more priority.
Small queues are not always the answer, apparently. :)
-
I have a 15m/1m DSL line and tried implementing CoDel in pfSense last night. I was not able to detect any improvement, so I deleted the discipline; which in turn crashed pfSense and I had to reboot, which made me wonder if I did things right or not.
-
I have a 15m/1m DSL line and tried implementing CoDel in pfSense last night. I was not able to detect any improvement, so I deleted the discipline; which in turn crashed pfSense and I had to reboot, which made me wonder if I did things right or not.
No, lol… I experience the same thing; Put a traffic-shaper queue on LAN, remove it... crash. Though, pfSense did unfreeze itself once, but it took a good 60+ seconds
About your poor experience; CoDel or not, you should see latency improvement if you configured your pfSense gateway as the slowest hop in your route. Transferring egress queueing from your modem to pfSense and your ingress queueing from your ISP to pfSense, should always see some sort of improvement, unless you are lucky enough to have a great ISP.
What were you results exactly?
-
Nullify wrote:
"About your poor experience; CoDel or not, you should see latency improvement if you configured your pfSense gateway as the slowest hop in your route. Transferring egress queueing from your modem to pfSense and your ingress queueing from your ISP to pfSense, should always see some sort of improvement, unless you are lucky enough to have a great ISP."
Could you please describe how to do that "for the complete idiot?" Thanks.
I tested the changes with the new speed test over at DSL Reports (which has a buffer bloat meter–don't know exactly how it works).
-
Just make sure that your pfSense router is the slowest part of your upload and download traffic.
-
I love that new speed test. Should I have not been seeding 30Mb/s while running this test? lololol
-
Nullify wrote:
"Just make sure that your pfSense router is the slowest part of your upload and download traffic."
So, in order to do that, should I use the traffic shaping wizard (where CoDel is not an option) to set my bandwidth (and leave all other settings on default, since I don't need to prioritize traffic), or should I use the CODELQ option under "By Interface?"
Someone really should write the book, pfSense for Dummies.
-
You shouldn't even need to use the wizard. Just click on your WAN interface, set your bandwidth, and set it to codel.
Another thing you could try is to set your interface to fairq, create a child queue, set as the default, then configure that queue to be codel.
-
First run some download/upload tests to get a baseline. Subtract about 5-10%, and use thagt as your bandwidth for your manually setup WAN and LAN queues using CODELQ.
Run down/upload test to confirm that you are seeing queues registering some packets.
I was a pfSense/networking noob a few months ago. This forum, the official book, the official wiki, and the interweb in general has about a decade of pfSense knowledge just waiting to be read. :)
-
Thanks all, but as my upload speed seems to vary quite a bit, no changes I make to traffic shaping seem to have much of an effect. I'll likely have to wait for a faster internet connection before I am able to put these tools to good use–I might have to wait quite a long time, given my ISP's disinterest in improving its service.
-
Set your upload speed 80% of your "normal" max speed. It will help more than not doing anything.
-
Nullify wrote:
"Just make sure that your pfSense router is the slowest part of your upload and download traffic."
So, in order to do that, should I use the traffic shaping wizard (where CoDel is not an option) to set my bandwidth (and leave all other settings on default, since I don't need to prioritize traffic), or should I use the CODELQ option under "By Interface?"
Someone really should write the book, pfSense for Dummies.
+1 for pfSense for Dummies.
Sometimes you just want a clear and concise example and not to spend hours, days or even weeks combing the forum for that needle in a haystack answer.
-
Just wait 2-3 days. The same questions get asked over and over.
-
O.K., I set my WAN to use CODELQ with an upload speed of 800 kb/s. I, however, still get a "D" in relation to buffer bloat on the DSL Reports speed test. :P Do I need to reboot pfSense for the traffic shaping to take effect (it does not say so)?
-
Can you show us your config? I assume you have something simple. Maybe just a screenshot of your WAN interface under Traffic Shaping would be good.
I assume you have slightly more than 800Kb/s of upload bandwidth?
-
As per your request:
