I'm not aware of anything in pfSense that would disable an interface based on some threshold.  There are a couple of dashboard widgets that will show you the traffic totals, but I don't know how often they reset and there are no configuration options.  Status - RRD Summary (an add-on package that is not installed by default) gives details & totals per interface and starts at the first of the month.

Hi had the same problems many times before with limiters. I don't think it's browser related. I use chrome all the time. Limiters handling seems to be unstable sometimes. To modifie one existing limiters I have to delete them and recreate them all in order to get them working properly.

Also, you need to limit your upload/download to lower bandwidths, otherwise your current setup has virtually no effect. I pay for 6mbit/768kbit ADSL, but my real-world upload is ~666kbit. For proper QoS (so you can control latencies by avoiding any buffering at the ISP), you need to limit your upload to something below your real-world upload. I use 600kbit, in my case. I know it is unfortunate, but to properly employ QoS, you will need to do some more research. I had to… I have been crashing down this rabbit-hole for months. :) Here is a good introduction, in my opinion. http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/

The GUI page runs that same command in a loop, it's not as "real time" as it might seem. There's no way I know of to sort that data at the moment.

I've follow this tutorial https://forum.pfsense.org/index.php?topic=63531.msg364520#msg364520 And now when I download from 2 differents PC they got each one half bandwidth, the same for more PC. Getting close to resolve the problem! Still can't figure out why the traffic shapping give the same speed even if one queue is 1% share and the other one 61%. PS: I've got the last build: 2.1.5-RELEASE (amd64) built on Mon Aug 25 07:44:45 EDT 2014 FreeBSD 8.3-RELEASE-p16

It was a fat finger error on the rule that catches qAck.  Everything works as advertised.

It's not "unfixable", it's just not easy to fix and has never worked so it got pushed off to a future release. As I stated in the linked bug report, there is no "quick solution". If there was, it'd be fixed in 2.2 already.

What happens if you disable your L7 rules?

maybe you could try to limit it based on ip addresses. Maybe this thread could help. I am also new to pfSense just trying to help. https://forum.pfsense.org/index.php?topic=63531.0

Just to give an update on this… I am running pfSense 2.2 RC1, and it appears this is working now. I'm a happy camper.  :)

Thanks for the response.  I ended up actually just reinstalling since I was just getting started.  It might be nice to have in future versions a "reset to defaults" button for certain packages….like snort.  :)

I have a 50/50 connection and I had to up my queues to 2500 to avoid dropped packets because of micro-bursting. You may want to try something smaller, but give 200 a try and see if it makes a difference in your throughput.

There are diagrams in the 2.1 book.  I'm not exactly sure where floating rules come in. Here's one paste.  I am operating on the assumption that a floating rule on WAN out pushes the firewall rules on WAN back into the path and that's the proper order.  LAN rules, then floating on WAN out for outbound states.  

@KOM: No idea.  I don't use captive portal. Maybe i'm the only one to use captive portable with the traffic shapping. I'll continue my research. Thanks.