I ended up switching to a PRIQ setup instead.  I limit the upload on my WAN slightly so I don't saturate my uplink.  I then set my LAN bandwidth to 980 Mb/s and squid then flows at almost full interface speed.  It would be nice to be able to depriortize squid but for now at least it works.

It was removed because it is broken in dummynet and does not operate as expected. It never did work, as evidenced by all the complaints in this thread. It isn't viable, so unless it gets changed upstream in FreeBSD, it won't be coming back.

Bounty suspended as belt9 has been circumventing a ban. Those interested may submit a new bounty. Considering his attitude we cannot take the responsibility if he will deliver the funds to the solution.

No.  I do have 3 VLANs setup on it.

you would do that in squid..

Changing scan mode to hyperscan also fixed suricata with traffic shaper

I would not use Codel for below 1Mb/s. You're on the fence, try it, but it may not be a good fit. I would just use FairQ. The default queue size is 50 packets, which is too much for your upload bandwidth. 50 1500 byte packets is nearly 1 second of bloat. A queue size of 8 would be about 120ms max latency before packets get dropped. I would recommend a separate ACK queue.

The most difficulty is to set up floating rules for inbound.  For example, I wanted to put http downloads for XBOX in a low priority queue.  I did a floating rule for 80 source,  destination (xbox IP), to go to my lowprioqueue.  But even though the floating rule is at the bottom, it never gets used.  It's hard to do inbound matching, any help on this?

@TauCeti: The short version is: The floating firewall rules that assign traffic to your queues have to have their Action changed from "match" to "pass". [image: pass-vs-match] Anyone reading this thread, be careful using PASS in floating rules, this can open your internal network up to the Internet. If you need to use PASS rules, don't use floating rules but put them in the LAN or other appropriate interface.

I've never used limiters, only shapers. I can only tell you how to limit your fail-over egress via shaping, but not how to limit your fail-over ingress via limiting.

https://redmine.pfsense.org/issues/7898

I stand corrected!

thanks this worked for me on 2.3.4. I saw on a few other threads that ue (USB interface) devices don't support altq, but I seems to be working fine for me. I've just set this up on one box, and another box has been running queueing on two ue devices for ~1yr. Is it just not that reliable? hence the default non-inclusion, or am I missing something?

Mine has also been stable with the tuned parameters so definitely agree this is a better solution than limiting queue length.

@Double: I'm having some issues with the Priority field in the GUI.  Could be my limited understanding of the tool. tl;dr - The GUI doesn't seem to be saving Priority=0 to the config file I thought I was alone in this, I also noticed that a priority of 0 cannot be saved, even though the GUI attempts to. would be great if a priority of 0 could be saved because it would allow us one more bucket/level of shaping

I would set the queue size to 1,000. The average packet size is about 600 bytes, or 4800bits, which is a bit over 1,000 packets for 10ms of buffer @ 500Mbit/s. Your upload is much slower, you'll want a linearly smaller queue.

Have had pfsense using PRIQ for over a year, luckily we have not ran into any of the corner cases, but our network is only a small home network.(I can definitely see where PRIQ could cause issues on larger networks.) It has also kept all the buffer bloat in check with this setup. What I have loved about PRIQ is that the important things ALWAYS get the bandwidth they need, no matter what, it has been wonderful. I am really curious as to whether or not PRIQ can support 8 buckets, I may try to dig into the code and see if I can change the default value from 1 to 0 and see if that allows me another bucket. Just have to find the right file to edit.

I tried plex pass 3 weeks ago.  That is interesting, I will have to try again.