@mloiterman:

Just giving this a bump, as I would like to deal with the latency resulting from lack of upload bandwidth on my very assymetric Uverse connection.

I added some instructions how to setup fq_codel in a few steps in this thread:

https://forum.pfsense.org/index.php?topic=142321.msg776278#msg776278

Hope this helps, but please let us know if you have any additional questions.

Ok, thanks for clearing this up.

I'll see what I can do on the torrenting.

Probably "easier" to have a local WSUS and shape all of its outgoing traffic and forward to WAN2.

Is there a reason you need/want to micromanage your bandwidth? Why can you just use something like fq_Codel that maintains low latency for all connections while semi-fairly distributing bandwidth?

https://forum.pfsense.org/index.php?topic=126637.0 is probably all you need. Depending on your upload bandwidth, you may need to tune the "quantum" and "target". In general, fq_Codel absolutely needs some tuning below 1Mb, highly desirable below 2Mb, still useful below 5-10Mb, depending on how picky you are about maximizing your bandwidth.

Thanks for taking the time to respond!

That looks VERY promising, but FAR beyond my ability to sink the time into.

I'm only new to pfSense and even just the basics are proving tough (ie VPN's of any sort .. yet to get one working).

Maybe once there is a web UI I can give it a go. Has there been any word on that being implemented?

I tried the wizard available in pfSense and as far as I can tell it hasn't had any effect.

Regards,
Michal

As with any shaping, you need to know how to match the traffic. No, I know of nothing specific here for that provider. Have you tried searching for Nextiva up in the search box?

Otherwise try pfsense nextiva in google. :)

Great - glad it worked out for you… Shitty Ass ISPs  So they want your devices directly attached?  And you can have only 1?

You could write a patch to make this edit for you, since every time you update and that file gets updated your change will be lost..

Click on the queue.

"and under LAN:HFSC the bandwidth is: 20971.52Kb (what does this means?, what does this queue means ?)"

Out of the box there are no queues or shaping or limiting done… So you would of created those.. So I take it you didn't set up this pfsense?

Is it current 2.4.2_p1?

I would suggest you remove any old queue/limiting/shaping that would of been done by previous persons and create correctly for your current needs and bandwidth.

Dropping 1 out of nearly 19,000 packets is worrisome? Dropping packets is normal unless you have a synchronous connection directly connecting only two devices.

@KOM:

So is it worth my time to make use of TS with such a low bandwidth allocation?

The need for a shaper has nothing to do with your bandwidth.  The question is, are you having any problems on the network that a shaper could help with?  If your voip calls always work well and you aren't having any problems then I'd leave it alone.  If your voip calls & video streams are getting stepped on when there is a lot of other traffic then yes you could use a shaper.

Start with PRIQ instead of HFSC.  PRIQ doesn't require any bandwidth allocation like HFSC does, and it's a LOT easier to understand and configure.

I will give that a try! And yes, my phone calls are horrible, so that is my highest priority.

The Queues page is useful for seeing if traffic is going into the queues as expected.

I can't think of how PRIQ could affect your line stability.  Modem resets shouldn't be happening at all.  All PRIQ does is let you define an order of packet processing and then it just follows it blindly, irrespective of bandwidth.  Other shapers like HFSC care very much about bandwidth settings, but PRIQ is dumb & simple.  I use PRIQ at my company.

@jimp:

Floating rules have many more options which are hidden from the rules on the individual interface tabs.

One of these is the shaper wizard's default of "match" rules, which do not pass or block traffic, but only classify it for the purposes of traffic shaping. The floating rules can also match traffic in the outbound direction, which is necessary for proper/expected shaping. Interface tab rules only match inbound traffic.

Ackqueue/Queue are there to pick the shaper queues. Queue is for the arriving packets, Ackqueue is for reply/ACK packets

Thank you for a very clear answer that helped me solve some traffic shaping issues

is this concept possible with pfsense?

pfSense has no cap management features that I'm aware of.

That is a scary setup, but I guess if it "works".

The interface validation uses the pre-bandwidth change calculated child bandwidths instead of post change. Scaling up the parent bandwidth is fine, but down does not work.

Is the 2MB for the entire interface or is it for each individual device?

It depends on how you configure it.

I found this helpful:

https://www.reddit.com/r/PFSENSE/comments/3e67dk/flexible_vs_fixed_limiters_troubleshooting_with/