traffic shaping - beginner to opnsense

[reefer123]

a question:

playing around with traffic shaping "FQ_CoDel"

i did 2 sets of pipes (each set for up and down /load)

all of them have the FQ_CoDel as a scheduler type
one set have weight 100 the other set have weight 50

but in the docs it says "FQ_CoDel ignores the weight: set to 100" - so that means there is no priority between them ?
or the "100" one will be 1st in line and the "50" second ?

also the rules sequence for the 100 (set) are 1 and 2
and for the 50 (set) 11 and 12 - will that put the 100 (set) ahead ?



practically i want 2 pipes with one of them being more "important" then the other ...


thanks

[meyergru]

Caveat emptor:

While there is an official guide, I recommend to work through this - and I really mean "through", because it does not only apply to IPv6, but also to specific rules for ICMPv4 traffic. Also, you will find that changing the traffic shaper sometimes requires a reboot before the settings are applied - this is not in the official guide.

[reefer123]

Caveat emptor:

While there is an official guide, I recommend to work through this - and I really mean "through", because it does not only apply to IPv6, but also to specific rules for ICMPv4 traffic. Also, you will find that changing the traffic shaper sometimes requires a reboot before the settings are applied - this is not in the official guide.

thanks

yes i did expected this to be a complicated adventure ...
so i did try something - probably it is a silly idea but at least it did not "broke" the router (after some of my silliness i had to do the full reset)

i am trying to "prioritize" Fortnite gaming - specifically the "ping" in the game 
so i did ↓

2 sets of pipes/ques/rules (each set for up and down /load) with "fair weighted que"

1st with protocol udp / any / any - this one has weight 100 and rules are 1st in line
2nd with protocol ip / any / any

↑ does that make any sense ?

it seams to work well , did not do any "proper testing" i get A+ in the Bufferbloat test , in the game looks good but my internet always vary depending of day / time etc.

any idea ?

thnks

[Seimus]

but in the docs it says "FQ_CoDel ignores the weight: set to 100" - so that means there is no priority between them ?
or the "100" one will be 1st in line and the "50" second ?

also the rules sequence for the 100 (set) are 1 and 2
and for the 50 (set) 11 and 12 - will that put the 100 (set) ahead ?

It means what it said. FQ_Codel e.g the FQ of the FQ_Codel doesn't care about weights. Thus this means FQ_C can not do any BW  prioritization whatsoever. FQ splits the traffic equally. If you have a Pipe that has 100Mbit, if you have only one stream it can get whole 100Mbit. If after that second one comes, FQ will share the BW equally thus 50/50.

The ping in games or the ping to check for latency in services, if it has a dedicated BW doesn't represent the real performance of the application. Its intended to have it go thru the same Pipe as is the service itself.

In OPNsense, we do not have the possibility to do packet prioritization/we dont have PrioQ. We can only allocated BW, we can call it BW prioritization. If you need this you need to use Weighted schedulers such as WFQ of QFQ. But the weights are only locally significant, to the Pipe/scheduler running the Weighted scheduler, it will not affect other Pipes.
However these schedulers cant control and help during bufferbloat.

As long as the dedicated Pipe/Queues for the specific service you did created will not be congested + you will always hit the BW availability specified by your Pipes (summation of all pipes) you will not get latency even with Weighted schedulers. The problem starts when you will not met these conditions.

For that we have FQ_C or FQ_PIE. FQ_C was created in mind for Real-time-traffic such as voice audio and gaming.

Regards,
S.

[reefer123]

but in the docs it says "FQ_CoDel ignores the weight: set to 100" - so that means there is no priority between them ?
or the "100" one will be 1st in line and the "50" second ?

also the rules sequence for the 100 (set) are 1 and 2
and for the 50 (set) 11 and 12 - will that put the 100 (set) ahead ?

It means what it said. FQ_Codel e.g the FQ of the FQ_Codel doesn't care about weights. Thus this means FQ_C can not do any BW  prioritization whatsoever. FQ splits the traffic equally. If you have a Pipe that has 100Mbit, if you have only one stream it can get whole 100Mbit. If after that second one comes, FQ will share the BW equally thus 50/50.

The ping in games or the ping to check for latency in services, if it has a dedicated BW doesn't represent the real performance of the application. Its intended to have it go thru the same Pipe as is the service itself.

In OPNsense, we do not have the possibility to do packet prioritization/we dont have PrioQ. We can only allocated BW, we can call it BW prioritization. If you need this you need to use Weighted schedulers such as WFQ of QFQ. But the weights are only locally significant, to the Pipe/scheduler running the Weighted scheduler, it will not affect other Pipes.
However these schedulers cant control and help during bufferbloat.

As long as the dedicated Pipe/Queues for the specific service you did created will not be congested + you will always hit the BW availability specified by your Pipes (summation of all pipes) you will not get latency even with Weighted schedulers. The problem starts when you will not met these conditions.

For that we have FQ_C or FQ_PIE. FQ_C was created in mind for Real-time-traffic such as voice audio and gaming.

Regards,
S.

YES

so will this help ?

2 sets of pipes/ques/rules (each set for up and down /load) with "fair weighted que"

1st with protocol udp / any / any - this one has weight 100 and rules are 1st in line
2nd with protocol ip / any / any  - weight 50

apparently
"Fortnite primarily uses the User Datagram Protocol (UDP) for its ping and gameplay data transmission"

[Seimus]

If you have two pipes and only 1 queue in each with any rules, the weight doesn't matter. Additionally if you don't set MASKs in queues the BW for WFQ is 1st come 1st server & STARVE OTHERS, it will not be shared towards multiple hosts. The configuration you mention should be used for reserving BW for dedicated Applications and not any/any rules.

Also what is your end-goal here?
If you target is to have stable connectivity for Games use FQ_C as games are latency prompt.

Regards,
S.

[reefer123]

If you have two pipes and only 1 queue in each with any rules, the weight doesn't matter. Additionally if you don't set MASKs in queues the BW for WFQ is 1st come 1st server & STARVE OTHERS, it will not be shared towards multiple hosts. The configuration you mention should be used for reserving BW for dedicated Applications and not any/any rules.

Also what is your end-goal here?
If you target is to have stable connectivity for Games use FQ_C as games are latency prompt.

Regards,
S.

the fortnite ping is the end-goal

so if i understand correctly i would have to make 1 pipe (1up and 1down) that have 2 different ques / rules ?

will try that

[Seimus]

so if i understand correctly i would have to make 1 pipe (1up and 1down) that have 2 different ques / rules ?

The answer is not that simple, but no.

What exactly about the Fortnite ping is bothering you?
Please expand a bit, what is the issue?

Regards,
S.

[reefer123]

so if i understand correctly i would have to make 1 pipe (1up and 1down) that have 2 different ques / rules ?

The answer is not that simple, but no.

What exactly about the Fortnite ping is bothering you?
Please expand a bit, what is the issue?

Regards,
S.

when the internet fluctuate (the usage and internet quality)
i want the "ping" be taken care 1st (is the most important for us here LOL)

[Seimus]

Ping is just a ping for measurement, it doesn't interpret the real performance of an application.
If you give dedicated BW to ping so be it, but the reality is you may have OK ping yet lags in games.


You are speaking about fluctuation of BW I presume?
Meaning ISP is not consistently delivering you the contracted BW?

If that's the case there is no proper solution for this. Shaping/QoS is made on the premise that when you set 100Mbit for example you always have 100Mbit at your disposal.

The only Scheduler available on FreeBSD that can handle latency cause by a fluctuating BW on WAN is FQ_C. It will not be perfect but it can make a huge difference in such scenarios lowering 5000ms latency to >150ms.

They way how you want to configure a Shaper in your case to have stable and best connectivity possible. Is to set the BW on the Pipe to the lowest possible you can get during a fluctuation event and use FQ_C on it. If the cut would be to much, you can still use you average achievable BW, but it will not be as good as to cap it to the lowest achievable. In the FQ_C doc is a section for base tuning which should be follow in such cases.

Regards,
S.