Playing with fq_codel in 2.4
-
ALTQ and Limiters are two different systems. My understanding is ALTQ is PF traffic shaping and Limiters are IPFW traffic shaping. Two competing firewall systems that FreeBSD has.
-
Why wouldn't it be a check box next to where we already have codel, random, random in and out, and explicit congestion notification
All of those things are already implemented.
It's just a different control algorithm tied in at the same place
One big reason is because the area you're referring to is in the queues (ALTQ) section while fq_codel was implemented in limiters (dummynet) section.
Why don't we "just" send humans to Mars? We already have robots there.
Like I said, back-seat driving is easy.
Why is it under limiter, when the rest of them are under altq?
I'm a bit unclear about what you're asking but if you are asking why fq_codel was implemented in dummynet rather than ALTQ you'd need to ask the devs: http://caia.swin.edu.au/freebsd/aqm/
I'd like to know as well. Maybe they think ipfw/dummynet is more future-proof than ALTQ? I dunno…
-
By default, fq_codel uses ECN.
This often doesn't work properly for upload so you may need to try without it. For my config this meant using:
ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn
Swap ecn/noecn as needed depending on the order you created the limiters in.
-
Interestingly, on Linux, fq_codel is in mainstream kernel, and enabled by default now.no settings required.
-
By default, fq_codel uses ECN.
This often doesn't work properly for upload so you may need to try without it. For my config this meant using:
ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn
Swap ecn/noecn as needed depending on the order you created the limiters in.
I know what are you talking about.
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
But FQ_CODEL revision was updated several times since this article was published and no official remarks about ECN and recommended settings in docs.
I have read a lot and played a bit with ECN option, but in my case it have no effect directly. If anybody suggest some simple way to test ECN I will be much thankful. -
@w0w:
By default, fq_codel uses ECN.
This often doesn't work properly for upload so you may need to try without it. For my config this meant using:
ipfw sched 1 config pipe 1 type fq_codel ecn && ipfw sched 2 config pipe 2 type fq_codel noecn
Swap ecn/noecn as needed depending on the order you created the limiters in.
I know what are you talking about.
https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
But FQ_CODEL revision was updated several times since this article was published and no official remarks about ECN and recommended settings in docs.
I have read a lot and played a bit with ECN option, but in my case it have no effect directly. If anybody suggest some simple way to test ECN I will be much thankful.You can use tcpdump to see whether ECN has been negotiated/used, then run downloads & uploads with ECN disabled/enabled to see if there's any difference in speeds and/or latencies.
For me, it improved download (or was it upload? or both?) speeds by a few percent but over a few days of using ECN (Linux client /proc/sys/net/ipv4/tcp_ecn = 1) had a couple of sites completely fail to work so I set tcp_ecn back to it's default (2).
Whether your pfSense router supports ECN is a separate condition from your client supporting it, so make sure to configure it appropriately on both.
I only played with ECN very quickly so take my input with a grain of salt… ;)
-
…
For me, it improved download (or was it upload? or both?) speeds by a few percent but over a few days of using ECN (Linux client /proc/sys/net/ipv4/tcp_ecn = 1) had a couple of sites completely fail to work so I set tcp_ecn back to it's default (2).Whether your pfSense router supports ECN is a separate condition from your client supporting it, so make sure to configure it appropriately on both.
I only played with ECN very quickly so take my input with a grain of salt... ;)
Do you remember URLs of sites failed to work with ECN?
I've seen some reports like "Measuring the State of ECN Readiness in Servers, Clients" and others too, all of them stated that there is some % of servers that have wrongly configured ECN and this is the real problem, even if percentage of those servers lowered over years, but the real quantity raised up, so the simplest way is to test ECN enabled FQ_CODEL against some of those " ECN-failed" sites. -
Setting my bandwidth to 95% of my always results in about 20mb off of my total bandwidth in tests. It seems that to use this you have to take a bandwidth hit….
-
I have a 150Mb connection, I set my bandwidth to 99%, or 148.5Mb, and I get about 147.8Mb/s with speed tests. If you're losing more than a small faction of a percentage, it's because something is misconfigured, low quality network equipment, or you're dealing with very small amounts of bandwidth where dropping a single packet results in a sizable bandwidth difference.
-
I have a 150Mb connection, I set my bandwidth to 99%, or 148.5Mb, and I get about 147.8Mb/s with speed tests. If you're losing more than a small faction of a percentage, it's because something is misconfigured, low quality network equipment, or you're dealing with very small amounts of bandwidth where dropping a single packet results in a sizable bandwidth difference.
This is my experience as well. Only when I was beginning my traffic-shaping journey did I experience strange things like that. My assumption is that I was misconfiguring.
I suppose it's possible that these algorithms incorrectly calculate bitrates but that is very unlikely since transmitting at the configured bitrate is perhaps the most fundamental aspect of any traffic-shaping algorithm.
-
I have a 150Mb connection, I set my bandwidth to 99%, or 148.5Mb, and I get about 147.8Mb/s with speed tests. If you're losing more than a small faction of a percentage, it's because something is misconfigured, low quality network equipment, or you're dealing with very small amounts of bandwidth where dropping a single packet results in a sizable bandwidth difference.
I also have 150mb connection and am running an i5 mini PC with PFsense. It seems like a simple configuration so I'm not sure what could actually be misconfigured but I'm not ruling it out. Any ideas?
-
I have a 150Mb connection, I set my bandwidth to 99%, or 148.5Mb, and I get about 147.8Mb/s with speed tests. If you're losing more than a small faction of a percentage, it's because something is misconfigured, low quality network equipment, or you're dealing with very small amounts of bandwidth where dropping a single packet results in a sizable bandwidth difference.
Full disclosure, I am running a VPN, but it pins at 147mb no matter what….until this config.
-
HeatmiserNYC
So, with FQ_CODEL you have 130Mbps max, right? You said -20Mbps…
The misconfiguration can be interference with other limiters or rules if you have used same limiter twice or more — I did not checked but it was possible in certain conditions.
Also TS mentioned that this FQ_CODEL setup equalizes traffic and with VPN it can be a real problem if you have concurrent or even the same traffic on both.
Anyway, I did tests some time ago and there was 1-2 Mbps difference with bandwidth limit, if we compare to traditional HFSC this is about twice less. Now I don't use bandwidth limit but delay limit that is set to 0ms, this causes FQ_CODEL scheduler to process all traffic by using only internal parameters, I think. Double check everything and if problem persists, please provide some configuration sample. -
Cool, thanks for replying.
Yes, I get about 125-130 down when I set my limiter to 143mb (95%). My connection without the limiter will tend to burst initially to a bit over 200mb according to testmy.net. I have a simple setup following the guide detailed in the first post.
I use the VPN for all outbound traffic, it's not a separate situation.
I have tried traffic shaping before and this has been true for any configuration I have ever tried. If I try to shape close to my line speed it takes about 20mb off the top. How do you not use a bandwidth limit? Adding a delay limit in the field doesn't take.
Just need a successful example of this to get running…
Again, thanks.
-
Cool, thanks for replying.
Yes, I get about 125-130 down when I set my limiter to 143mb (95%). My connection without the limiter will tend to burst initially to a bit over 200mb according to testmy.net. I have a simple setup following the guide detailed in the first post.
I use the VPN for all outbound traffic, it's not a separate situation.
I have tried traffic shaping before and this has been true for any configuration I have ever tried. If I try to shape close to my line speed it takes about 20mb off the top. How do you not use a bandwidth limit? Adding a delay limit in the field doesn't take.
Just need a successful example of this to get running…
Again, thanks.
Perhaps your speed drop is related to overhead like VPN, TCP, etc. I assume you are referring to goodput bitrates?
On downloads you will commonly see below the configured bitrate because each time you hit the limit pfSense will tell the sender to slow down below the limit. Personally, I found very little useful benefit by limiting downloads because my ISP has minimal bufferbloat and allowing them to do the rate-limiting gives me 100% speeds.
-
What about to try to move shaper/limiters from LAN side to VPN side firewall rules?
-
That's an idea, I'll give that a shot!
-
Yea, that didn't work.
-
Just for testing purpose, try to change bw limiting to delay limiting :
pipe 1 config delay 0msfor both pipes
-
Sorry gone for a few days, vacation.
I gave that a shot by changing the /tmp file, it doesn't seem to have an affect. I am only changing the /tmp file, maybe it needs to be rebooted and hardcoded into the file? The only reason I haven't done this is because I haven't seen the results everybody is reporting…
