@mickeyil use limiter with PRIO as scheduler and setting weight in the queues should give you prioritization, not sure how much throughput the SG-1100 is capable off, but i would imagine that a couple of hundred Mbit wouldn't be a problem for it.

Looks like this floating rule worked after all - setting Match as 1st rule. Not sure why it wasn't working the 1st time, I didn't find any other contradicting rules. Maybe something didn't reload correctly...

@pieterdevries I am seeing the same thing with scheduler set to FIFO and increasing queue length to 200000 doesn't make a difference. Testing WFQ, QFQ, Round Robin and PRIO as scheduler does work with default queue length of 1000. I am not sure if something is wrong in Pfsense but you could go with PRIO as scheduler for now.

@bobbenheim, thanks, understood :-(

Really last post, issue was the ISP modem, pfSense was not "dialing" the connection so i had a double NAT. After letting pfSense connect to the ISP through the modem, all is good, been working great since my last post.

For anyone coming across this that is Bell Aliant, the option is PPoE pass-through.

I found some interesting notes by the Dummynet AQM developer including a recommended configuration for FQ_CODEL here. Still old though and an update on what works best would be nice. https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/775

After playing around some more, looks like "Bandwidth" field uses parent-relative %, but " B/W share of a backlogged queue" (m2) uses absolute %. This makes a bit more sense now why both fields are provided -- but the UI is still atrocious.

Correction: "Bandwidth" field allows me to add sum of %s which exceed the parent's %. I'm not certain they'll be applied as relative

@hebein fq-codel is more of an automatic solution, in the way that it does'nt starve any connections of bandwidth and tries to keep latency low at all time. You give priority by creating more child queues under the limiter and set the weight parameter and thereafter make a rule to catch the traffic that needs priority. But as with all other type of QoS it needs the bandwidth to be available which could be a problem on LTE and although it might take a few more minutes to implement there is far less adjustments needed to get a good result contrary to the traffic shaper guide.
The difference fq-codel isn't just seen on low end connections, on the two speedtests below you can see the difference it makes on a 240 Mbit symmetric fiber connection. The black line is average of the four streams, and total bandwidth is four times the average.

test32_20480_flows_800_uplimit_800limit_20480_flows_download.png

all.png

Thanks for the reply.
I rebooted the system & now the limiter info is cleared out, but it still won't let me delete them.
I've gone through every rule and can't find any that have a limiter set. Why can't the error message just tell me which rule it thinks has a limiter set?

681101cb-448f-4b86-a944-86e88fe1f41d-image.png

@Harvy66 Thanks for the education and info, I really appreciate it. I will keep this in mind and refer back to this thread if I do have any issues. So far I haven't had any complaints from VOIP users.

I also tried to make this work with the tag and tagged fields, the original rule that I have working:

Action: match
Interface: WAN
Direction: in
Address Family: IPv4
Protocol: TCP
Source: any
Destination: Wan Address
Destination Port Range: 443

this is working ok tagging the traffic going to the HaProxy, not my finnal intente (I only what to filter the traffic going to the emby server) and now I tried to add:

Tag: fromwan
Queue none/none

Then I used the rule that I stated above:

Action: Match
Interface: LAN
Direction: Out
Address Family: IPv4
Protocol: TCP/UDP
Source: any
Destination: EmbyServer
queues qACK/qStream
Tagged: fromwan

Nothing, the traffic keeps not being assign to any queue. Just out of curiosity I tried to block the traffic from the wan to the emby server. I used the rule above

Action: Block
Interface: LAN
Direction: Out
Address Family: IPv4
Protocol: TCP/UDP
Source: any
Destination: EmbyServer
queues qACK/qStream

This rule was working blocking the traffinc, but now I added Tagged fromwan. The result was no blocking at all.

Floating rules are so hard to predict and test, but I need them to shape my traffic.

Hello!

Maybe delay pools in the squid package?

John

@bobbenheim Looks like that was the trick, I can see the rule working choosing LAN for the Penalty users, thanks Sir.

@Kaila said in pfSense CE:

I need to know if pfSense CE gives bandwidth use. If It does, how much is that?

Yes, bandwith is limited to the hardware pfSEnse is running on.
If you have x GB capable device, then that's what you get ^^

@Kaila said in pfSense CE:

do we need any routers or servers to work with pfSense CE?

Well, you will have to use some upstream "modem", or whatever other device that brings "Internet" to your site.
But no routers or servers are needed.

On Linux I'd know a way, netfilter actually has a module that switches chain/rule after a certain amount of time, but on BSD I actually don't because I never had the problem before.

Btw: Standards are a problem of their own. When stuff like HFSC gets implemented it doesn't necessarily mean it's following the whole standard. Always check the BSD docs on the corresponding version:

https://www.freebsd.org/cgi/man.cgi?query=altq&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html

Sadly I don't see a solution at this time, not with pf or even ipfw and limiters as there's no way to do anything based on time (e.g. 5 seconds).

There are workarounds with tables and PF's match rule, but that's nothing you want in production.

Cu