@lonnie said in Ackqueue versus Queue: downloading a little faster if I set Ackqueue to a higher priority queue than the regular queue Basically, yes. The idea is the ACKs get sent out as fast as possible so the web server streams the download more consistently. The shaping wizard does this by default. This may help: https://www.slideshare.net/NetgateUSA/traffic-shaping-basics-with-priq-pfsense-hangout-february-2016 I think that's from this? https://www.youtube.com/watch?v=it_5xvC28vs&ab_channel=Netgate

well good news and bad news, it seems everything is looking good in terms of FQ_CODEL for all real physical clients, and for virtual machines but not for docker containers. I run Pfsense in a virtual machine, on my esxi host as well as unraid in a virutal machine (both on the same physical host) and the unraid virtual machine runs docker containers. esxi host pfsense vm || unraid docker containers I have 2 physical ethernet ports on the esxi host, so I dedicated one for WAN and one for LAN for easy segregation. pfsense being the sole VM with access to WAN vswitch In order for docker to use subnet addresses for containers (hosting them at different addresses than the host address) requires macvlan or ipvlan network settings in docker. I opted for macvlan as some random internet article mentioned that cpu overhead was higher using ipvlan than macvlan. Now the way in which macvlan is done is through mac for forging the mac address. The security settings in esxi virtual networking permit this so I was forced to enable promiscuous mode and forged transmits, placing the docker host on its own port group within the same vswitch. This fixed the docker address issue but created problems in relation to FQ_CODEL as now when traffic was coming in destined for docker, it didn't appear to journey through the pfsense vm first. I thought it was strange that a rule which usually has 2k+ states created, only had 7 but didn't really think much of it at the time. i've now changed to ipvlan docker network setting but this hasn't resolved the issue. I have disabled promiscuous mode and forged transmits, and placed the docker host back on the same port group within the same vswitch. Traffic rules seem to all properly be flowing through pfsense now but I still have it bypassing FQ_CODEL for some reason. At this point i'm not really sure where to go from here, it could be pfsense it could be docker, it could be my own user error. What is a strange observation is that it sometimes works. For example starting a large downstream file transfer (for now I have set up quite low artificial limits of 50mbps down and 15 mbps up so I can easily observe if its clamping appropriately) [image: 7189836b9d8489bdc917f61635b7a4ce.gif] for a time it did clamp appropriately (although at a lower rate than it should) then it progressively gets higher. If the rules didn't exist then it would have started off at 600 mbps. During the times where its clamped at 25mbps (even though it should be 50) the traffic was visible and updating in the firewall rules. After it went beyond that the left hand counter stopped going up. Okay returned to this after a couple of hours of head scratching and found the culprit. The half speed is a result of lan side rules + floating rules, which in effect double up and cause half bandwidth. Disabling one of them resolved that part. Since this is a service which required port forwarding I had an additional rule (i don't use floating rules, i prefer the old rule style of applying them to lan interfaces with a single lan to lan rule at the top which doesn't use fq_codel). It appears that a racing condition was happening, in that traffic meant for the VPN was split between 2 different rules (the LAN rule and the port forwarding rule on the VPN interface). This was what resulted in the weird behaviour of it clamping for a time and then not. Once a significant amount of clamping had occurred, traffic was flowing through the VPN interface rule which didn't have FQ_CODEL limiters placed on it. Why this behaviour occurs I have no clue, its a fun little racing condition. When you add them both together, it results in the correct amount of traffic flowing through the interface too. [image: 68c6664a4e3604b52eec2a5f65600bad.png] Lan side [image: 4b7523bceb808b8a342794d0b8648cc9.png] VPN side This all occurred on PFsense CE 2.6 and now at this point I think I can comfortably say everything is working as normal. In my foolishness I sidegraded / upgraded to pfsense plus 22.05 and this caused the behaviour to perform differently / poorly. In CE 2.6 FQ_CODEL clamping happens instantly. In 22.05 it was delayed, which caused latency spikes until it got it under wraps. [image: dd82432d34fb0c242e3c107227e6c817.png] Might not be clearly visible, but you can kind of see the sawtoothing occurring in 22.05. Its more clearly visible on the 1h resolution but only shows 1 instance of it occurring. [image: 9ff859d28d31c27bb92ab970e8d2b1e5.png] So thats it! i've now got a working setup with pfsense 2.6.0 and i'll stick to this now until something major comes down the pipelines or some bugs exist.

How I see it, may not be accurate since I don't use Squid since a long time: When you are using Squid, the connection is no longer between the host and the web server. The connection is between pfsense itself and the webserver, thus the definition of proxy. The rule in which you applied the limiter will no longer be used. Transparent or explicit proxy, both are affected by this behavior. What you can do is to enable limiter in the squid itself, or set limits through Radius if you configure squid to authenticate through it. I didn't test the Radius authentication with Squid, so I'm not sure if it would work.

Same issue here, I have a totally unrelated interface with a 40 Mbps traffic shaper on upload and download, whenever I enable captive portal on an unrelated interface and enable per user bandwidth limitation any other interfaces with a traffic shaper completely lose internet. What is happening here?

@sysadminfromhell In general, a limiter limits bandwidth. A shaper prioritizes packets. Sometimes they are used together. Netgate has a page on bufferbloat also, which uses both. I've not set that up myself, I've used the shaper with other methods, like PRIQ only prioritizes packets.

"your experience with fq-codel is impossible unless you misconfigured it" I never said that. Yet your replies are contrary. My reply is still the same: If possible use CAKE (preferably with the ingress keyword) if you want to maximize throughput for a given increase of latency (which ultimately effects the packet loss rate). Question your solution if you have to sacrifice 40 % of your throughput in order for FQ-CoDel to have no packet loss on sparse flows. not to mention the dozens of lines that show you have not read the documentation you linked to I leave it to the reader to judge who has neither read nor understood it.

@jimp said in Old bug or new issue?: Those are not the same rule you have failing in the error message. The one in the error message has a different description. Check all the other tabs and see where that specific rule is, labeled "Connections From Upstream SIP Server" Rebooted today and the issue is gone.. bizarre

@demux To the 200Mbit and 20Mbit pipes you created, the remainder of your bandwidth does not exist. Any traffic that you assign to those pipes using firewall rules will only ever have access to a total of 200Mbit and 20Mbit of bandwidth respectively. If you assign all your traffic to one or the other of these two pipes, then the remainder of your bandwidth will just go unused.

@tman222 awesome! thanks for the information :)

@jaypfadmin You saved me HOURS of troubleshooting!

I created a small tool luckman212/stv to help make it a little easier to debug states. In case it's useful to anyone else.

I think I figured it out. I was using one limiter for all interfaces. I created one limiter per interface and it appears to be working as desired. Sorry for asking a dumb question.