@FreeYourMind: But then again this wouldn`t apply to PRIQ where there is no bandwith sharing but just a priorization of traffic, is that correct? Thank you I don't think so because each PRIQ interface is still unaware of any other interface's bandwidth. It's an ALTQ limitation, which all traffic-shaping queue algorithms use (HFSC, PRIQ, CBQ, FAIRQ). Also, generally, fair queueing is fair per each flow ("connection") so each host could get an unfair amount of bandwidth by having more flows. The limiter approach I linked is much closer to accomplishing your goals. Though, it may not be able to evenly share beyond a /24 network, so you may need to have both of your LANs in the same /24. Dunno… your problem is a common one but I haven't yet ran into a simple solution that I can link you to. :( Good luck. You'll surely learn some stuff along the way.

Anyone?

I have the same problem. How will I set the rule ? Thanks for your help!

USB Ethernet device uses udav driver which indeed supports altq. Now the question is: does pfSense support altq on bridges? I would wonder if it is not the case, according to information found on the internet it should.

So, I've figured out that my floating rule wasn't working as intended, through a back door way.  And I have a solution that may help others. I ended up creating a LAN rule like this: Action: Pass Interface: LAN Protocol: TCP Source: Single IP, any port Dest: Any IP State Type: Keep Ack Queue: qAck Queue: qGames With this rule, I've homed in on the IP that I really want to make sure gets high priority (for Netflix and Games) and makes sure the Ack packets are getting high priority.  In this mode, the number of Ack packets per second on the WAN side is in the hundreds.  This is what I am expecting, and solves several problems at once. Hope that's helpful for someone else.

@MLIT: @Harvy66: Depends on what layer of "bandwidth" we're talking about. If you assume Ethernet, every 1530 byte Ethernet frame received will result in a 92byte frame sent assuming these frames represent a TCP connection. Nagle is enabled on most systems, so let change that to 92bytes sent for every 3060byte received. That's a 33:1 ratio. 1Gb down will result in 30Mb up of traffic. This ratio completely changes if you only assume Layer3 data transfers. Then it's 60bytes up for every 3000bytes down, which is a 50:1 ratio or only 20Mb up for 1Gb down. I assumed the worse of the two. A single ACK can acknowledge several received packets. TCP doesn't acknowledge each packet individually. It can but only does so in the case of Nagle, which is 2 packets and I addressed above, or you have packet loss. Either way, that doesn't change the fact that you're sending the data. For 99.9999% of network streams, your TCP ingress:egress will typically be either 33:1 or 50:1, depending on what layer you're looking at and what types of layer2s your packets go through.

Have you checked the floating rules?

@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?