Thanks. Couldn't find a definitive answer to if and when the interface method could be usefull. Unfortunately my question remains unanswered :).

We haven't got around to digging into that one yet, lots of other higher priorities.

@remlei said in Inaccessible pfsese web admin page when traffic shaping is enabled: internet speed to compensate the congestion with the bandwidth. You looking to mitigate the bufferbloat on WAN ? http://www.dslreports.com/speedtest

found this Bandwidth (root queues) The amount of bandwidth available on this interface in the outbound direction. For example, WAN-type interface root queues list upload speed. LAN-type interfaces list the sum total of all WAN interface download bandwidth. https://docs.netgate.com/pfsense/en/latest/book/trafficshaper/advanced-customization.html so set 32 Mbit on the WAN interface and 50mbit on LAN Interfaces. These settings are not limiting the max bandwith in case I would get more bandwith, just used for the algorithm priorizing the packets, right?

Thanks! That worked for the ping issue. I managed to get the traffic shaping queues to work by modifying the rules and setting the traffic to outbound and adding the codel queues to the in and out pipes and then I set the main CoDel Queue rule below the traffic shaping rules.

@daemonix you should see a difference in pfsense but i would use flent for testing just because it's easier and it utilizes download and upload at the same time.

@johnpoz Thanks. That proves your point about the missinformation out there and why it's a good thing that it's back on default. Will give an update if my issues remain after what I did before and/or if I gathered more insights. Vincent

@Gertjan Yes, the R6900 is from Netgear, and with ASUS-merlin firmware(not pfSense), but it is working great.

Jim, I installed cron and see this: /etc/rc.filter_configure_sync scheduled every 15 minutes, which you suggest in another thread is probably because of using a schedule. So I guess if you use a schedule, Queue stats are cleared every 15 minutes. Thanks, -Steve

No, I didn't make any adjustments. Everything has been working fine regardless of my drop count. It seems like it doesn't matters unless there is actual contention for bandwidth. In that case, I would assume the higher priority queues such as VOIP will "win". As you mentioned, the speed test may not be the best metric even if it appears to correlate to drops. I wish I could suggest a better test, but I really don't know how to properly test traffic shaping otherwise I would have done it to test my setup. I'm simply going by my end users phone call quality. If those drops were really impacting my setup I would have had people complaining about call quality.

Some more information on what you have done so far is needed then.

Same here. I haven't managed to figure out whats going on. My only clue is that this specific line of code in /usr/local/www/firewall_shaper_vinterface.php loads something : require_once("shaper.inc"); if you check it, you'll find that it's a humongous piece of code: [2.4.4-RELEASE][root@test]/root: wc -l /etc/inc/shaper.inc 5281 /etc/inc/shaper.inc Other than that, no clues.

Still haven't got this working. Can anyone help me out? Usenet traffic is hitting queue but not utilizing all of the available bandwidth.