Nope! Fair enough :)

Sounds like I have the basics of PRIQ set up correctly, thanks!

so are you using floating rules, lan rules, or both?
right now I'm using floating rules. if this is correct, which interface are you choosing

@Harvy66:

Limiters don't guarantee bandwidth, they limit bandwidth. If you create a limiter that limits your special subnet's bandwidth to 8Mb/s, that doesn't mean they'll always get 8Mb/s, just that they can never exceed it. You also need to place limits on the complement of that subnet.

I personally prefer to use HFSC, which defaults to specifying minimums instead of maximums, although you can also do maximums.

Thanks for the suggestion Mr.Harvy66. Really appreciate it. I will work on HFSC now.  8)

so in the above image, I am allocating 10% of my bandwidth to games, and games have a very high priority, just below qACK

now I have circled in green the 10% bandwidth and the checkbox "Borrow from other queues when available"

in this particular pfsense page, does that checkbox mean, share my 10% bandwidth with the other queues (qP2P and qOthersHigh)

or does that checkbox on that page mean, when I need more than my 10% bandwidth, go borrow from the other queues.

Hi

I also find the removal of L7 a bit sad. Snort's OpenAppID feature is nice, as long as you want to block traffic, but what if you want to use L7 to send specific traffic types to a traffic shaper queue? Then OpenAppID wont work.

One idea might be to replace ipfw-classifyd with something like nDPI (http://www.ntop.org/products/deep-packet-inspection/ndpi/). It's opensource and has the advantage of being able to inspect SSL encrypted traffic as well. I've already created a feature request for it - https://redmine.pfsense.org/issues/5813

@sofakng:

I'm not sure the difference between ALTQ and dummynet, but I would absolutely love for pfSense to support fq-codel regardless of how it's implemented.  (as long as it works correctly… right?)

In pfSense ALTQ is known as traffic-shaping queues, and dummynet is known as limiters.

It won't make 10.3, too late for that, but hopefully gets into 11. We'll get it sooner than later if that happens (post-2.3 regardless).

thanks

I don't want to share the internet between vlans I  want to restrict every users that  don't have speed more than 20 KiloByte  for download and uploada

A large increase of latency is not an inherent characteristic of a saturated link, only a characteristic of a saturated link with too much buffer. You can use something like CoDel to limit buffer bloat to something more reasonable and it has a side-effect of causing streams to be mostly fairly balanced. That may be your 80/20 rule. If you need even more control and if you have a limited number of clients, you could use HFSC, but limiters seem to be easier for most people to grasp.

Even with limiters, give CoDel a try.

Dialup PPP was about 48kbps with about 220ms delay at best. Toss in about 5% packet loss to mimic overbooked ISP T1 uplink for good measure. Next time some kid bitches about slow internet, show them what it was like in the good old days. Have fun. :) And get off my lawn.

likely same issue as in https://redmine.pfsense.org/issues/5721

pfctl related code is mostly (completely?) unmodified from FreeBSD, so look to the FreeBSD man-pages/forums for a better answer.

@esseebee:

Thanks, Nullity.  I was doing a download speed test when I was noticing the latency. I was also only using stand-alone codel, not the codel active queue.  What do you recommend? I'm still obviously learning about this stuff.

If you have complex needs, like running multiple cloud backups while wanting to watch Netflix and play games, then use HFSC/CBQ/PRIQ/FAIRQ and "codel active queue".

Otherwise "codelq" might work well.

Read http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/ for a great intro into traffic-shaping/QoS. He does a great job demistifying misconceptions and explains the differences between the solutions to fixing download & upload latency/bandwidth problems.

@jonathanbaird:

Hi,

I am not sure wether or not I need to set up Traffic Shaping for what I am doing, but I will go over my setup… We have a PBX installed at a datacentre, which sits behind a pfSense instance. The pfSense instance handles all of our NAT and IPSec VPN tunnels. We have currently around 6 VPN tunnels connected, and clients phones connect to the PBX over these VPN tunnels. Each client has its own PBX insance using 3CX's Multi Tennant.

I am not sure if I need to implement Traffic Shaping or not, as it stands the bandwidth is around 500Mbps down and 750Mbps up so we aren't short of bandwidth, but would traffic shaping still help prioritize VoIP traffic, even though there is not other traffic in and out of this pfSense instance?

I welcome your comments.

regards,

Jonathan.

Unless you are saturating your connection, QoS/traffic-shaping is virtually unneeded.

QoS can give you guarantees that if something were to saturate your connection, the VOIP (is that what PBX is?) will continue to see optimal latency and bandwidth.

@keelingj:

OK, this isn't a viable workaround.  Disabling "upper-limit" allows heavy internet usage to saturate the uplink and cause ping spikes.

If you are not multi-LAN, qInternet is unneeded.

IIRC, qInternet is meant to separate intra-LAN traffic (in a multi-LAN setup) from LAN<->WAN (internet) traffic.

@pteek:

pfSense + a managed switch.

How will this work?

You can search for other posts on the topic. I have no actual experience in this area.

I would assume that you would shape the traffic by IP/port on a single interface within pfSense, then the managed switch would split it off into the seperate LANs.

Thank you for your help. I hope I can find.

Best regards,

Im with muswellhillbilly here.. Not sure what you think you are doing but running same network on both your wan and lan is BROKEN!!!  And it not going to work!