@Nullity:

For exporting, pfSense should come with softflowd and pfflow.

Don't touch pfflowd. Completely no-op: https://redmine.pfsense.org/issues/4304

There are three issues with traffic shaping your download

You can't force the senders to slow down, but you can influence them The latency between the shaper and you is much lower than the shaper and them. It takes them longer to respond. You're going from a faster to slow link when you shape your upload. Shaping your download is going from a slow to fast link.

Addressing #1. You can't stop bad actors. They can take several forms, the most common being a DOS attack. Nothing you can do with your firewall if they consume all of your bandwidth. There's another kind of bad actor. An example is many cable companies have horrible amounts of bufferbloat, which can cause the latency between you and someone else to be incredibly high. This can cause a sender to retransmit data that wasn't lost, but the latency was so high, it triggers a resend.

#2 and #3 are your most common. You biggest enemy is TCP ramps up exponentially. This means you need enough breathing room to keep your link from getting flooded. If you have a good connection, you can probably set your upload to 98% and effectively traffic shape. With your download, you may need to set it to 95% or lower.

Remember, PFSense shapes outgoing. You need to shape the outgoing of your LAN. Multi-LAN gets messy and has limitations.

Could you explain a bit more?

Status - RRD Graphs - Quality.  I think Harvy nailed it so my suggestion is likely moot.

oh well, seems limiter is not working with squid transparent proxy  :(

https://forum.pfsense.org/index.php?topic=90486.0

@msmith9xr4:

I really hope so, I saw here yesterday that they're considering leaving this regression until 2.3 !!!! WTF!!!!

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

Big shame to let such an incredible regression linger through so many releases.

Definitely was one of the top 5 features of pfsense…

LAN is a start, but WAN limiting is critical for all but the most simple home networks- i.e. any that run any services... at all.

At least for anyone who wants to do voice with any quality control.

Limiters are useful but voice (VOIP?) quality would be better controlled by employing a QoS setup with CBQ or HFSC queues.

1st. I'm not sure if you can not have a default queue. The end result will either base the same as having a default queue or the data is going to get dropped.

2nd. Even if you can do that, don't use the traffic shaping system like a firewall rule. Just make rules to block traffic you don't want.

I used to be using a router w/ QoS, and can stream smoothly the net by just using 70kbps max download speed but when I switch to Pfsense for some reason (some reason that my router dont have that feature inside) the 70kbps is not smooth and slow.. thats why im researching for many days now to make this pfsense bandwidth limiter work just like the 70kbps on my router..

Maybe this may work

ISP(NET) xxx.xxx.0.1 >> PFsense (lan ruled, custom rule enabled) xxx.xxx.10.1 >> Router (bandwidth, wifi) xxx.xxx.2.1 >> LAN Clients (PC and Wifi devices) xxx.xxx.2.2~254

If u have some shaper limit settings to make it work.. Maybe it may work

@ermal:

But even if you need 15 you can use th emask functionality to not need to create that many and resuse the same limiter definition.

Didn't find any info about emask, I'd like to keep within standard config which can be set up via GUI so that backup config can stay safe.
If I use one single limiter queue for all the 30 directions (15 in  + 15 out), will they be limited to 2Mbit/sec all, or each (totalling 30Mbit/sec on WAN side max)? (provided that the same limiter is selected for both in and out and on each subnet interface)

Edit: it doesn't let me use the same limiter for in/out, the message is: " In and Out Queue cannot be the same. "
So would it be enough to just create 2 queues like "2mbit_in" and 2mbit_out" and select these on all 15 interfaces? Will these limit at 2Mbit separately or in total?

@Harvy66:

"I have been saying HFSC schedules both inter-queue and intra-queue. If HFSC does no Fair Queueing intra-queue then any flow could saturate a queue."

HFSC does not do anything with flows, it does not do hashing, it doesn't do anything with IP, nothing. All it does is pull the head packet from a child queue and decide which queue goes next. It's a queue scheduler.

Fair queuing, in the context of a queue, fights buffer bloat by isolating flows from each other within the queue.
Fair queuing, in the context of a scheduler, gives a fair amount of resources between queues.

Both HFSC and fq_CoDel do "fair queuing" at different levels.

No. Fair Queueing is exclusively concerned with flows.

https://en.m.wikipedia.org/wiki/Fair_queuing

Fair queuing is a family of scheduling algorithms used in some process and network schedulers. The concept implies a separate data packet queue (or job queue) for each traffic flow (or for each program process) as opposed to the traditional approach with one FIFO queue for all packet flows (or for all process jobs). The purpose is to achieve fairness when a limited resource is shared, for example to avoid that flows with large packets (or processes that generate small jobs) achieve more throughput (or CPU time) than other flows (or processes).

To claim "Fair Queueing", you must separate all flows (or most of the flows, like with SFQ). Above, it says each flow gets a "separate data packet queue", meaning this is automatic and not dependant on the user manually separating the flows like your "pseudo fair-queueing" setup. HFSC is a Fair Queueing algo therefore it separates all flows, by definition.

HFSC cites many other Fair Queueing algorithms including one paper which all modern Fair Queueing algorithms attempt to approximate as closely as possible, and it is titled "A generalized processor sharing approach to flow control in integrated services networks".

For the sake of clarity, the definition of a "flow" can be found here: https://en.m.wikipedia.org/wiki/Traffic_flow_(computer_networking)

Do me a favor and read the Generalized Processor Sharing paper (or even just the wikipedia entry) along with some papers cited by HFSC and any other academic papers you can find concerning Fair Queueing. Confirm or disprove your suspicions before replying. I have read all HFSC-cited papers and dozens of related papers and I can assure you that your posts in this thread are mostly misinformation.

Edit: Fixed link, trimmed cruft.

https://doc.pfsense.org/index.php/Limiters

Alright, thank you. That avoids me spending hours on this.

You can prioritize traffic leaving an interface, but you cannot make interfaces work together and prioritize among interfaces.

Unless you're running a VoIP call center, rate limiting UDP is not an issue. Except for BitTorrent, then UDP is sensitive to to rate limiting and will function similarly to TCP.

One of the ways the traffic is limited is by slowing it down. When the limiter is "full" then traffic will take longer to get through, so you see that as increased latency.

Or to put it both simply and more confusingly: There isn't a way to slow the traffic down without slowing the traffic down.

@KOM:

But Ill go ahead, read and see if I can figure it out.

That's how the rest of us do it.  Nobody has time to spoon-feed solutions, and you learn more by doing it yourself.

Best response ever!!!