Traffic management via the shaper is done with the use of queues and Floating Rules.

@Derelict:

Get rid of the burst until you understand what it does.

Done.

Your comment says 1Mbit, but your limiter is 10Mbit.

I was tweaking the settings without updating the comment.  You can ignore the comment.

If that rule is on the customer interface, in is upload and out is download.

What do you mean customer interface?  It is a type of LAN interface.  It is a VLAN (1003) of the LAN interface.

There are countless questions asking how to do this.  Do a search.  You probably want a main limiter that gives your guests a pool then child limiters with a mask to evenly distribute the data while letting one user monopolize the entire pool if they're the only one on.

Yes there are.  I have & will continue to search.  Is the main limiter with child limiters required?  I don't understand "a mask to evenly distribute the data".  I won't have problems with a lot of people being on it at one time.  It's for my home network & mainly just to keep the occasional guest from using my primary WiFi so I don't have to give out my WPA2 key & at the same time keep said guest from using up all my WAN pipe.

Thank you all so much the issue is resolved ;D. Just in case it becomes handy for someone else. Ill briefly write what I have learned and what I have done to fix the issue. As I already stated im pretty new to this networking stuff so if im not 100% right please correct me.

What I understood in general about TCP/IP is dropping packets is a way to control speed. So I figured dropping packets at such a low transfer rate was bad. If these were packets for something not time sensitive like web browsing it would go unnoticed.

-On my SRVS lan in Qinternet I added a new queue called MCservers.
-On my SRVS lan I deleted the games queue as I have no other game traffic on that subnet.
-On my WAN I set the game queue bandwidth to 5% service curve Link share 5%
-On my WAN I set the MCserver queue bandwidth to 40% service curve (Real time : 7Mb, Link share : 40%)
-On my firewall rules in the floating section I found the minecraft port entry and I edited the advanced features to use the ACK/MCServer Queues

So far with 2 days of testing ive had up to 15 people = aprox 2-3 Mbps uploads and no complaints of lag and no more dropped packets in my graph.

Actually it seems like this traffic is not showing on my RRD Queue graph at all anymore. Is this normal behavior with the real time service curve? I guessing that Realtime traffic skips the queue all together or for some reason just doesn’t show up on the graph?

I still have more to learn about the service curve I found some awesome links in this forum. I should be ok from here. Thanks again!

@stenio:

@Harvy66:

Is there a reason why you can't treat this as a dual LAN setup, where the actual LAN is one network and the DMZ is another?

Hi Harvy,

Yes, there is: I would like to share the download bandwidth between the two interfaces.

Thanks,
Stenio

Yes, seems I derped a bit there. I realized it when I read another post a few days later. Am I interested in how to best handle the issue of multi-lan where queues can't share interfaces. If there was a way, outside of yet another firewall, to have a single QoS queue for both Interfaces, that would make it simple.

That would work.  Read this to start.

little update: the problem is only vof trafic from remote site to my device in nat1:1.

Upload is good.

Thnx

its built-in pfSense…

Status - RRD Graphs

What I did wrong?

Posting a Squid question in the Traffic Shaping forum, for starters ;D

You will have better luck getting a reply in the proper forum.  Questions about packages like Squid and Squidguard should be directed to the Packages forum.

@georgeman:

Real solutions to this at the time:

Use another pfSense in front of the other one, to shape based on the origin and destination subnets Bridge the interfaces so you can apply the shaper to the bridge as a whole (you can still somewhat control traffic among them but it is more a clever hack than real networking stuff) Use VLANs on the same physical interface

As you can see, all of them are based on the principle of applying the shaper to a single physical interface

Hi Georgeman,

I've a similar situation in which I would like to limit the download speed of my DMZ and LAN interfaces. Could the limiter be another option to solve the problem?

Thanks,
Stenio

You are correct on torrents but I have a seperate torrent box at home (NAS computer) so I can direct its traffic to lowest priority queue by ip without a problem. I can advice everybody to do this.
While it is easy to prioritize certain activities like voip and games to highest priority, it is becoming harder and harder to seperate traffic coming from port 80 generic servers. These include steam downloads and now this.
So I created 3 seperate port80 queues. I'm trying to further prioritize certain web traffic from youtube,google etc. While doing this, I'm trying to deproritize port80 downloads to low priority port80 queue. But this isn't the best solution. It is still better than nothing.

You won't know about your priorities working or not working unless you set up a test where one of the higher priority queues is running enough traffic to shove the lower priority queue down, adequately continuously and for a long enough period that you can see what is or is not happening.

It may be that "borrow must be on" for any of the children to borrow, rather than "it's trying to share your qlink." If qLink is not borrow=on, I think the borrow=on setting on qInternet does not provide it with any access to your 1GB LAN/qLink. You could explicitly set qLink to borrow=off and see what happens, but I think that is the default - but I'm also still very much in the place where the depths of what I don't know about the shaper exceed what I do know by a huge margin.

You could also try setting qAck to borrow=off and see if you lose about 40% of your download on qLow, I guess. But that may not be the way borrow actually works. It would be a simpler experiment to set up, though.

I would assume so.

Hi Georgeman,

I'm really interested in the solution you're using, we have to connect 4 remote sites and bring phones trafic to central site and priorise VOip in the VPN tunnel.

Could you post the TS configuration you've done?

Thanks,

Thomas

I just set my receive queues to 2.5k. It's pretty much an issue just limited to traffic that can burst in quickly. Because interactive streams, like games, are on their own separate queue with reserved bandwidth, it seems to not affect anything except their own queues. Because the burst is being rate limited to fit into 48Mb/s in a much smoother fashion via PFSense, than Cisco, my machine cannot ACK data that it has not received yet, so the other side backs down. It seems to be that it's not so much the burst causing issues, but that my machine would normally ACK all of the data in that burst as quickly as it came in, indicating to the other side that I'm ready to receive more, when it really needs to back off before Cisco clamps down hard.

This is mostly me just theorizing, but I am seeing much better results.

I did find that I need to limit my P2P's queue size. During the ramp-up of a heavily seeded torrent, like Fedora, the hundreds of sending end-points would still peak over 50Mb/s on my WAN interface before leveling off, even though PFSense was making sure that I was only getting 48Mb/s. So while a large queue to soak the burst from a single sender works fine, a large queue for many senders that are all ramping up at the same time can cause issues.

P2P also has a lot less burst than Google services. I don't really have the issue of 1gb micro-bursting from Torrents. If I remember correctly, Google uses a custom TCP setup where they purposefully burst the first X bytes at or near full line rate, to make better use of available bandwidth. They let network buffers worry about the bursts. The "problem" is that between my ISP and Google is Level 3, and no congestion. It just lets that 1gb burst right on through 8 hops and 250 miles.

@KOM:

From what I have also read, blank LAN bandwidth equates to "100%".  We might get more detail with the output of the pfctl command.

Since bandwidth is just LinkShare, based on what I've read, the m2 in LinkShare should always override what's in bandwidth. Having said that, I went back and removed all of my link shares and just set my values in bandwidth instead and I set Real to the same as Bandwidth.

It works! I may not have it set optimally, but good enough. I'm just a home user.

It's easy for me to test my download, but it's hard to test my upload. Anyway, here's the results. You'l notice that my quality graph shows my ping going down. My ISP's gateway seems to respond to pings more quickly under load… Probably a thread scheduling thing, since ping responses are handled by the host CPU and not the ASIC.

This has solved my random packet-loss during high utilization. I normally get 0%, but some times when hammering my connection, it will get into the 0.04% range.

Thanks everyone!

P.S. If someone has a better way to loadtest my connection than Torrenting Linux ISOs while running SpeedTest.Net, I'm all ears.

Again, I have little experience and am just learning myself. You could set the default queue to have virtually no bandwidth, then create other queues for stuff like games and web. So 80/443 would get web, and you could add a list of known common games and add their ports.

But if you have multi-LAN and limit each LAN to it's proportional share of the WAN, then are you not essentially setting an upper limit for each LAN?  If you have a 40 Mb link and 4 LAN queues and giving each LAN queue 10 Mb, then if you have a busy LAN and 3 quiet ones, you are limiting the busy LAN to 10 Mb.  This all depends on how the WAN/LAN speed settings affect everything.  If it's just a value used in calculations and the queue will absorb whatever bandwidth is available, then fine.  If it also acts as a hard cap then that's a problem.

How will I setup port forward if I have 2x WANS? with LAGG!

@Ecnerwal:

I do not concur that "no documentation is a good thing."

FAIRQ is not an option in the Wizard setup (at least on 2.1.3, where my applicable system sits for now, but I bet the same is true in 2.1.5) though is IS an option for scheduler type on the shaper, non-wizardly. My experience of the "wizard" is not all that happy anyway. I suppose you could try PRIQ in the wizard and then change it to FAIRQ. Either way it's the moral equivalent of wiggling a screwdriver blindly in a high-voltage box in the hopes that it makes the right connection, with the documentation where it sits now.

It appears to me that most of what's mentioned in this retired topic from 2010/11 still applies to the shaper today. It certainly feels all too familiar and current. The fact that the shaper documentation (as linked from 2.1) still starts off with 1.2.x and then has 2.0 (work in progress) [but the work has never progressed] is rather depressing.

https://forum.pfsense.org/index.php?topic=26782.msg139435#msg139435

I don't see a question in there…  ???

There are (many) more places to find pfSense documentation than the official wiki.
I gained a bit of insight by reading source-code for FAIRQ, which was initially introduced in DragonflyBSD. Maybe that will help you too? I'm no C coder, but there are useful comments in the source-code.

For a super simple FAIRQ setup, you simply select your outbound interface in the Traffic Shaper, select FAIRQ and click Add queue. I think it is best to explicitly direct traffic into the queue because I think the maintainer of FAIRQ recently fixed a bug that was causing problems when traffic was defaulted into FAIRQ, and I'm not sure if that bugfix has been merged with pfSense's FAIRQ yet. (Disclaimer: I may not know wtf I am talking about.)

P.S. - I never said "no documentation is a good thing". Documentation is out there, you just need to find it. I did, and I'm a newb. :)