@TheNarc definitely not what I'm seeing in my setup. Probably something related to your VPN connection. My latency isn't affected at all. Did you try TCP Tunnel? I'm having latency issues and changes in speed as well when combining torrent with UDP tunnel. I wouldn't disable gateway monitoring, ping should just work and is a usefull quality indicator.

I have a similar problem. I have 1 500/100 Mbit/s Fiber thru vlan connection and a floating rule for limiters with interface wan and wan gateway, match, out.. I'm using this wan gateway in every out connection rule except one where I use a vpn gateway. As soon as I connect the VPN, my WAN only does 50 ish mbit/s upload. If I disable the floating rule, it returns to normal. If I disable the VPN, with floating ruleon, it returns to normal. 2.4.4-RELEASE-p3 (amd64) built on Wed May 15 18:53:44 EDT 2019 FreeBSD 11.2-RELEASE-p10 Intel(R) Atom(TM) CPU C2558 @ 2.40GHz 4 CPUs: 1 package(s) x 4 core(s) EDIT: Forgot to say that I solved my problem adding the queues in the rules and not using the floating rule.

That looks fine, what hardware are you running Pfsense on? Are you sure that Pfsense is the culprit and not some hardware elsewhere or user error?

@mickeyil use limiter with PRIO as scheduler and setting weight in the queues should give you prioritization, not sure how much throughput the SG-1100 is capable off, but i would imagine that a couple of hundred Mbit wouldn't be a problem for it.

Looks like this floating rule worked after all - setting Match as 1st rule. Not sure why it wasn't working the 1st time, I didn't find any other contradicting rules. Maybe something didn't reload correctly...

@pieterdevries I am seeing the same thing with scheduler set to FIFO and increasing queue length to 200000 doesn't make a difference. Testing WFQ, QFQ, Round Robin and PRIO as scheduler does work with default queue length of 1000. I am not sure if something is wrong in Pfsense but you could go with PRIO as scheduler for now.

@bobbenheim, thanks, understood :-(

Really last post, issue was the ISP modem, pfSense was not "dialing" the connection so i had a double NAT. After letting pfSense connect to the ISP through the modem, all is good, been working great since my last post. For anyone coming across this that is Bell Aliant, the option is PPoE pass-through.

I found some interesting notes by the Dummynet AQM developer including a recommended configuration for FQ_CODEL here. Still old though and an update on what works best would be nice. https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/775

After playing around some more, looks like "Bandwidth" field uses parent-relative %, but " B/W share of a backlogged queue" (m2) uses absolute %. This makes a bit more sense now why both fields are provided -- but the UI is still atrocious. Correction: "Bandwidth" field allows me to add sum of %s which exceed the parent's %. I'm not certain they'll be applied as relative

@hebein fq-codel is more of an automatic solution, in the way that it does'nt starve any connections of bandwidth and tries to keep latency low at all time. You give priority by creating more child queues under the limiter and set the weight parameter and thereafter make a rule to catch the traffic that needs priority. But as with all other type of QoS it needs the bandwidth to be available which could be a problem on LTE and although it might take a few more minutes to implement there is far less adjustments needed to get a good result contrary to the traffic shaper guide. The difference fq-codel isn't just seen on low end connections, on the two speedtests below you can see the difference it makes on a 240 Mbit symmetric fiber connection. The black line is average of the four streams, and total bandwidth is four times the average. [image: 1584881219804-test32_20480_flows_800_uplimit_800limit_20480_flows_download.png] [image: 1584881305873-all.png]

Thanks for the reply. I rebooted the system & now the limiter info is cleared out, but it still won't let me delete them. I've gone through every rule and can't find any that have a limiter set. Why can't the error message just tell me which rule it thinks has a limiter set? [image: 1584821229167-681101cb-448f-4b86-a944-86e88fe1f41d-image.png]

@Harvy66 Thanks for the education and info, I really appreciate it. I will keep this in mind and refer back to this thread if I do have any issues. So far I haven't had any complaints from VOIP users.

I also tried to make this work with the tag and tagged fields, the original rule that I have working: Action: match Interface: WAN Direction: in Address Family: IPv4 Protocol: TCP Source: any Destination: Wan Address Destination Port Range: 443 this is working ok tagging the traffic going to the HaProxy, not my finnal intente (I only what to filter the traffic going to the emby server) and now I tried to add: Tag: fromwan Queue none/none Then I used the rule that I stated above: Action: Match Interface: LAN Direction: Out Address Family: IPv4 Protocol: TCP/UDP Source: any Destination: EmbyServer queues qACK/qStream Tagged: fromwan Nothing, the traffic keeps not being assign to any queue. Just out of curiosity I tried to block the traffic from the wan to the emby server. I used the rule above Action: Block Interface: LAN Direction: Out Address Family: IPv4 Protocol: TCP/UDP Source: any Destination: EmbyServer queues qACK/qStream This rule was working blocking the traffinc, but now I added Tagged fromwan. The result was no blocking at all. Floating rules are so hard to predict and test, but I need them to shape my traffic.

Hello! Maybe delay pools in the squid package? John