@ispiff:

…
I guess i'm wondering if there is anyway to apply shaping to the outbound WAN traffic and not just each interface.  More so looking to balance traffic in real time between the vlans and the WAN internet connection without restricting inter vlan communications.

I think the Wizard creates a queue for LAN traffic on the local interfaces that explicitly avoids putting any restrictions on local traffic, so you might confirm that it is working. Is your problem caused by incorrect classification of traffic to the wrong queue? Is the queue bandwidth itself incorrect? Does simply enabling traffic-shaping cause the slow-down? We/you need to figure it out. Look at pftop and other diagnostics to confirm where the problem lies. Share more details.

A possibly simpler method would be to only create WAN queues, but this will mean only your uploads will be shaped. You could maybe use limiters on WAN to shape downloads (queues only work on outgoing traffic) since limiters are capable of shaping in both directions on an interface.

@fips:

Hi,

just went through the traffic shaper wizard and saved a capture file to check VoIP priority.
RTP traffic from phone (separate vlan) to pbx (which is in the cloud) has set the DSCP CS5.
RTP traffic from the pbx to the phone still has DSCP default.

Should it not be set in both directions??

Traffic-shaping primarily applies to transmitted traffic (which you control) rather than received traffic (which you have very little control over).

Do DSCP tags even survive outside your local network?

A good intro to the fundamentals of traffic-shaping/QoS can be found here: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/

"800 to 900MBytes/s."

800MBytes per sec – that is a neat trick ;) hehehe  I got to try this queue stuff.. Guessing you meant Mbits/s..

Jimp,

besides not using a laptop hardware at all,
I'm currently finding pointers to what would be the best recommendations concerning that particular hardware tuning in general at pfSense/FreeBSD layer

about the ue0 iface => USB 2.0 10100M Ethernet Adaptor (:udav0)
I agree that was cheap, not a valid solution at all - not only because of lack altq capabilities,
I cannot even set basic capabilities of card, this is plain macarrone when u actually need a whole yakissoba (see pic) - I recommend everybody not to buy it on the store next door for $10 bucks and use a better solution. TKS for the tip.

Concerning the Ethernet - and keep in mind I'm currently limited to USB2.0 bottleneck and also onboard NIC is 10Mb/100Mb only, but that will change in ten days when ethernet will be Gb and USB will be 3.0 :D - - can anyone point me towards the best setup for NICs?

The axge driver provides support for USB Gigabit Ethernet adapters based on the ASIX Electronics AX88179 USB 3.0 and AX88178A USB 2.0 chipsets
I'm talking about that dude here: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112

because might have local patches for the driver, maybe the driver backported to pfSense may require additional info so I need certification before spending more $bucks on USB to eth NICs. . . .. ….

should I go for it?


I would set it to 930. iPerf on my LAN shows about 940Mb/s logical, and about 970Mb/s raw. Toss in some inter-frame overhead and you're at 1Gb/s.

@hiryu:

Looking at your screenshot, it seems you're on the priority queue settings. This is for any limiters you've created under the limiter "tab".

I can't find a way to specify codel to limiter from "limiters"

Pfsense limiters are implemented via dummynet which can do exactly what you're looking for

Do you have any other limiters in addition to these? You say the hosts exceed these limits… but do they appear to hit any other limits?

I've personally run into an issue where my limiters weren't working as expected at all... but found the issue was a large discrepancy between what pfsense thought the internal numeric ID's of my limiters were vs what they actually were.

I solved the problem by creating a new tagged VLAN and assigning it to the LAN interface, leaving the actual parent interface and default untagged VLAN 1 unused.

@mevans336:

So I would do the following:

Create Overall Pipe
Name: 24MbpsLimiter
Bandwidth: 22Mbps
Schedule: None
Mask: None

Create a new queue
Name: UploadQueue
Mask: Source addresses

Create a new queue
Name: DownloadQueue
Mask: DestinationAddresses

Assign UploadQueue to In and the DownloadQueue to Out for the default (and only) rule on my ipsec tunnel.

Sounds about right, I limit my GUEST WiFi and just had a play with speediest.net wit one device then two.

Limited my download & upload to 5 Mbps, one device & speedtest = 5 Mbps two devices & speedtest = 2.5 ish mbps

You can do funky stuff with the masks, but mine are set to 32 & 128.

Actually I think thats the guide I used.

@Nullity:

AFAIK, it splits the bandwidth (10Mbit) proportionally among the active IPs, assuming you configure that way. It's not per flow.

I wonder why this one isn't doing that?

I have two rules as follows on my ipsec tunnel, where the traffic is flowing. Each has a 10Mbps in/out limiter:

0 /0 B IPv4 * * * 192.168.10.107 * * none sql replication limiter 0 /17.99 GiB IPv4 * 192.168.10.107 * * * * none sql replication limiter

Maybe I should make them floating rules?

Have you got a new version.

Because i have got a problem with DNS

Thanks

If this is right and if I corectly understood:
https://calomel.org/pf_hfsc.html

CBQ and PRIQ type queues with a higher priority are served first if the link is saturated and the "realtime" bandwidth is also exhausted.

PRIQ is doing the job from the moment the queues are over the size of the connections Queues systems, when in use induce latencies Don't forget I'm on VDSL, asymetric connection without garenteed (?) bandwidth

Let's get the following exemple:
Good days: 75Mbps Down/6MbpsUp.
Average:  50Mbps Down/5MbpsUp.
Bad days:  25Mbps Down/2,5MbpsUp.

If the connection speed is set to high value 75Mbps Down/6MbpsUp and the real value of the connection is under (for example 50Mbps Down/5MbpsUp):
– If my needs for connection are under the real connection capacity (50Mbps Down/5MbpsUp. ) : no problem
-- If my needs for connection are between the real connection capacity and under the value of my connection as declared (75Mbps Down/6MbpsUp): problem: PRIQ will not trigger and my VOIP can not function with quality. The network is consuming all the bandwidth so VOIP will sufer, the priq will not work because it will only work when my network is filling connection queues with 75Mbps Down/6MbpsUp
-- If my needs for connection are over my connection as declared (75Mbps Down/6MbpsUp) : PRIQ will triger, VOIP will work with may be a bit latency due tu queues system.

So IF I set my connection too high I risk PRIQ not to work when the needs for connection are between the triger and the realtime values of the connection.
If I set my connection too low, trigger will often work (when not needed) and PRIQ will work (when not needed) and induce latencies.

Is it right?

also the game runs on a 60 tick rate , do i have to adjust the d

@nils92:

…but they might be related to the fact that I run everything through a VPN which I can't seem to traffic shape on.

If you're tunnelling through the PFSense with a VPN connection, as far as the PFSense is concerned all the packets passing through the VPN are destined to the VPN server (assuming an outbound connection), not whatever they go to once they pop out the other end of the VPN. So you're correct - you can't shape traffic within a VPN.

@moscato359:

I had the same problem with sch_codelq, but sch_fairq with codel fixed it

I have the same problem (500/30 without shaping goes to 250/20 with codel shapers set to 20 for wan and 480 for lan)
Tried fairq shaper with the same result.

What is sch_codelq and sch_fairq? Is this the same as codelq shaper and fairq shaper in the gui?

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

See this thread

Yes it's a simple validation issue.  I also have those illegal priorities set due to numerous upgrades going back to 2.1.3 when it used to work.

@Nullity:

@davidmoore:

@KOM:

For floating rules last match wins (the Quick option is unchecked), so putting your rule at the top may be part of the problem.  Also, you need to clear states before the change takes effect.

Okay, so I read more about this and floating rules still do topdown processing, but it will choose the last rule that matches in the list unless Quick is selected. If Quick is enabled then it will stop processing that packet and go ahead and make the match.

I have quick enabled on that rule and it's at the top of the list.

According to https://doc.pfsense.org/index.php/What_are_Floating_Rules (at the bottom of the page):

"Rules using the Queue action do not work with quick checked."

Thanks. I think this issue is resolved.