PRIQ doesn't need to know the bandwidth, but your interface still needs to have the bandwidth rate limited, otherwise your interface will just pump out data as fast as the interface, which is probably 1Gb/s. When data comes in faster than 1Gb/s, PRIQ will start to re-arrange packets.

Thanks Harvey, worked like a charm…

PFSense has two types of shaping, interface shapers like HFSC and limiters. HFSC can shape the egress of an interface. In other words, you can shape the data leaving your WAN and you can shape the data leaving each of your VLAN interfaces, but you cannot have your interfaces share state. Each interface does not know anything about the shaping of another interface. Some people claim there are some round-about ways to effectively share bandwidth across several interfaces, but at least for easy setups, you'll need to forget sharing bandwidth and instead just carve out dedicated bandwidth.

@stephenw10: You are probably hitting this: https://redmine.pfsense.org/issues/4326 Set the limiter on the LAN side or try a 2.2.3 snapshot where I believe a patch has now gone in: https://redmine.pfsense.org/issues/4596 Steve Steve, Thank you!  A quick scan of that bug looks like it's a good bet as to the source of the problem.  I've been pulling my hair out trying to figure out what's wrong.  Everything's working and then I insert the two limit queues into the firewall rule and everything just stops. Regards,   Fred

Ah thank you. I was trying to make sense of why such a broad rule was created by the wizard.

@mcwtim: Proper upgrade procedure is to backup your config, uninstall any packages, do your upgrade, reinstall your packages then re-import your config. RTFM  ;) Thank you, all this time and I did not know that. What must have happened was that I tried to setup traffic shaping on the old release, it failed, updated to latest, re-ran the traffic wizard and failed. Could have been that the box did not reboot. Couldn't get to a prompt on the local console .Had to have someone on site hit the power button. Client is still up. I'll build a new box and ship it to them. Thanks again TL

jr.fenol, could you create your own thread instead of spamming someone else's?

Hi Harvy, If applied to both WAN Interfaces, both WAN Queues are working for Upload. –> This should be OK. Currently, i'm not load balancing because i'm afraid for overloading 1 of the Download Lines. I want to shape the Download, and this seems to only work when the LAN Interface is selected in floating Rule.

Maybe disable ECN?

Ok So I an use a priority queue to guantee the uplink on a single WAN which is good as that is more limited, and dedicate a fixed bandwith to the VOIP on the downlink, which means there is some wasted when no calls are happening, but isn't too bad. If I had 2 boxes, the first with just 2 interfaces, then I could queue both in and out based on destination quiet happily. What about some clever configuration where by all traffic coming in on the wan got routed out of an interfaces with a queue, which just came back in on another spare interface to be then processed as normal. Would that work / have any disadvantages? Clearly would need 2 spare interfaces to do it.

You can't shape ingress traffic, but most traffic is not a DOS and follow rules. UDP traffic is typically fixed bandwidth and will not attempt to fill up your pipe, while TCP will attempt to fill up the pipe, but backs off on packet-loss. In my case, prior to my ISP having an AQM and had a hard cut-off for bandwidth by using the rate limiting built into my ONT which was very strict, setting my LAN interface to about 95% of my bandwidth pretty much kept ping spikes out, which means no buffering on my ISP's side. I could have reduced my bandwidth further and tightened the ping spikes, but way too much diminishing returns. I was already down near 10ms. While 98% link speed resulted in packet-loss and some major ping spikes. That 3% different was pretty big. My point is TCP is pretty good at responding to congestion. Latency is a big issue. My tests were primarily against busty traffic like speedtests or youtube, which I had between 10ms and 20ms. If the sender is further away, like 200ms, it will take that much longer for the packet-loss signal to reach them. It really depends on your typical use cases.

I have never used the L7 stuff, but just wanted to point out the bug in your XML.

sorry about the confusion. if i set the limiter to 2Mbit/s upload or anything else I get 0.09 Mbit/s Upload but if i take off the limiter in firewall rules i get my full 4 Mbit/s Upload. I suspect something weird is going on here.

I have not been able to get limiters working at all, since 2.1.5 or earlier. Could just be me though… but I would expect SOME life to show in the limiters when most of my other configs work as I assumed they would. Is there a standard practice for enabling debugging or verbose logging? I think I remember something at boot about verbose logging. Is there a debug toggle for ipfw/pf/altq?

No, they are ignored unless you craft your own traffic shaping rules to prioritize the traffic.

Thanks Derelict, will set the limiters and report results.

On your WAN Scheduler Type: fairq Bandwidth: 95% of your maximum. If you have really stable bandwidth, then possibly 98%. If you have very unstable bandwidth, then closer to 80%. Create a default queue, set the length to 4096, check codel. Results may vary. It should keep latency low.

I'll we glad when we can have our Cake and delete it too.

Okay. I will have to test those settings as well.  I saw the other post about Codel with UDP and dropping packets. Maybe that was some of my issue I was having. Will have to test with putting UDP only queues under some other queueing and then using Codel for TCP only queues. There were some complaints of packet loss in some of the games using UDP solely