Maybe if you post in the Traffic Shaping forum, complete with details about your configuration and the exact way it isn't working anymore, perhaps someone could try to help you.

Unless you have multi-WAN/multi-LAN, you only need create the 2 qIMAP and qHTTP queues. Set the WAN interface (root queue) to some number under 12Mbit (a few % below whatever you real-world download throughput is). Use link-share. Also, are you referring to download or upload?

known issue, refer to this post: https://forum.pfsense.org/index.php?topic=90486.0

Try just using CoDel or FairQ schedulers. They both should reduce bufferbloat and semi-fairly distribute bandwidth. They're dead simple to use and may be good enough. If you're trying to control download, you need to rate limit your LAN interface.

@Nullity: If you use a standard, 2 interface LAN & WAN setup, qLink is unneeded. I think it is only useful for multi-LAN setups. It's also useful if you run proxy caching on pfSense. Otherwise, the local cache stream would be limited by the default internet download speed setting.

@Harvy66: So limiters are not working? I never use those. When there is a limiter on a rule where NAT forward or reflection applies. https://redmine.pfsense.org/issues/4326 https://redmine.pfsense.org/issues/4590

Well, my question was if that were a problem which has been ever seen and/or fixed in some newer release.

"Real" bandwidth is always given, no matter what. It ignores link share and upper limit. But any bandwidth consumed by real will still count against link share and upper for all non-real bandwidth. example Say qInternet is 0.5Mb, and qVoIP is 1Mb and under qInternet. qVoIP will not only get at least 1Mb, even thought qInternet is only assigned a minimum of 0.5Mb, but when qVoIP attempts to use more than 0.5Mb/s. Well.. Simple math. 0.5Mb - 0.5Mb is 0Mb and 0.5Mb - 1.0Mb is -0.5Mb. Of course you can't have negative bandwidth. This just means there will be 0 bandwidth left to distribute among the child queues under qInternet, starving them.

Yes, however at the time my entire network had stopped working, prime time and all.  First and foremost that I needed to get the link back up.  I intend to revisit this again, I have another pfsense router coming in so I will be able to do some testing.  We are a software development company and Internet is important lol.  I am going to look at the blank value when I redo this.

I cleared out the state tables and rebooted, but I'm still limited to 20mb up and down.  This is the same as my original rule which I used for testing, but I deleted it and created a new rule for 46 mb up and down.  What else can I do to get the traffic shaper to use the new values? Thanks!

Seems to be (something like) working now … started with only configurating WAN interface (without LAN). Then a 2nd Interface ... bridged ... and then shaper wizard.

Hi Harvy66 thanks for the reply, yep they do unfortunately.  I think uploading is worst then torrenting lolz… especially when having 2mb upload and now these days there's so many sites to upload..like google drive,dropbox, mega, filepup ,etc :(

As far as I understand, traffic will bring some benefits only if you have already some contention. Shaping will then prioritize traffic as per your rules. I'm pretty sure you will get, assuming there no network contention, benefit from ads removal. Then debate is perhaps more to discuss about ads removal implementation  ;) Tweaking DNS is one option. Relying on features like Squid + Squidguqrd is another way, better from my standpoint. Do not expect throughput improvement when adding Squid in the middle. Benefit of cache is very little nowadays, especially if you perform tests with one single user, mainly because of the dynamic aspect of Web and the use of HTTPS almost everywhere. But I believe you will get more granularity and better (to me) control with Squidguard than DNS.

@KOM: How does the qACK and qACK/qGames differ? Does the qACK take priority? Does the qACK/qGames take more of a priority. TCP requires an ACK to initiate the sending of the next packet from the source.  You generally want to prioritize ACKs because that is what TCP uses to help it's flow rate calculations.  UDP does not use ACK since it's a connectionless protocol.  That's why you see TCP rules direct ACKs into qACK and UDP rules don't.  In most shaper configs I've seen, you want to put ACK and DNS in the top queue, VoIP is next, HTTP/S next and everything else last. I would like to know how assigning aliases helps this config. It makes the ruleset both easier to rad and maintain. Thanks!

If the modem literally hangs (like, requiring a power off/on), you'd better look for fixed firmware HW that's not broken

@stm110: Ok, there are some security traffic that really need to come through. So let´s narrow it down and focus on incoming traffic. Incoming from the WAN side?  You can't control that. You can only control what leaves the box. What arrives at the box is decided entirely be the sending side.  Furthermore, if what arrives at the box is congesting other traffic arriving at the box, it's just too bad, you can't control that. Exceptionally, under specific circumstances, there are techniques to limit the sending of TCP ACKs so that the sending side will quench their output, but this is pretty advanced stuff, and I'm not sure the traffic shaper can help with this. If you're dealing with UDP traffic, all bets are off. –A.

As you can see there: Target version changed from 2.2.3 to 2.3

I had the same issue this is how I solved it, I have 13down/2up i enabled the VOIP meaning that i cannot add more then the 30 percent from what I start. ex: you have 10down/1 up so you put 1000kbit x 30%= 300kbit upload but put 250kbit 10000kbit x 30%= 3000kbit download but put 2500kbit and I see the pics that you have some in kbit others in mbit, put everything in kbit and try it out also try with HFSC, and lastly you forgot to put your IP of your asterisk.  ;)