What is expected qAck rate?



  • Hi there.  I purchased a Netgate SG-1000 for my home internet, since I have a lot of users, mostly watching videos and playing online games.  My cable modem connection is 50Mbit download and 10 Mbit upload.  It measures that very consistently.  Most of my users are on one of two WiFi nodes with 802.11 a/g.  My internal network between my cable modem and my WiFi hotspots is 100mbit or 1000mbit.

    I setup the Traffic Shaper from the wizards with CBQ for both WAN and LAN, and I have these queues:
    WAN: ack, default, games, othersLow, othersHigh
    LAN: ack p2p, games, regular traffic, others low

    I've set the ack queue to be 30% of bandwidth on both WAN and LAN, to make sure I'm not being limited there.  I can see my P2P traffic being put in the p2p queue.  However, my qAck values on Status / Queues never gets above 10PPS or 10k/sec.  Even if multiple people are streaming Netfix and YouTube at the same time.  The default queue is getting all traffic except the small ack and p2p traffic.

    Based on the info I've read on multiple different sites, it seems like my Ack queue should have 10x or 100x more PPS than it has.  Does this value of 10PPS or 10k/sec make sense for the ack queue?  If it doesn't how can I correctly get those ack packets to get categorized correctly?

    Thanks for the help.



  • Create a catch-all TCP floating rule that matches all connections and set the ACK queue. qAck really doesn't need a whole lot of bandwidth. It really only needs to be about 1/30th to 1/50th of the bandwidth of the opposite direction. If you have 50Mb down, 1.7Mb/s is probably enough, or 17% of your WAN. On your download interface, the reverse. 1/30th of 10Mb up is  0.34Mb/s or 0.7% of your download bandwidth.

    It's generally a good idea to add 25% extra bandwidth to whatever you need, because of bursting. Assuming you're using HFSC, any unused bandwidth will get "fairly" split among the other queues, so adding additional bandwidth does not hurt.



  • Thank you, I will give that a try.



  • If you are using an SG-1000 then the reason it's not looking right is that Traffic Shaping with Match rules is currently broken in pfSense 2.4 beta.

    https://redmine.pfsense.org/issues/7116

    It's been on the bug list for a long time. Hopefully it will get fixed before 2.4 is released.



  • SG-1000 doesn't even support shaping unless you're using VLANs IIRC.



  • @KOM:

    SG-1000 doesn't even support shaping unless you're using VLANs IIRC.

    I think that may have been fixed.  ALTQ wasn't supported by the NIC driver initially and VLANs was the workaround.

    https://redmine.pfsense.org/issues/7199



  • Yeah, sorry, I should have specified I'm on 2.4 Beta (), latest one. 
    2.4.0-BETA (arm)
    built on Fri Jun 30 00:22:14 CDT 2017
    FreeBSD 11.0-RELEASE-p10

    Using CBQ for both WAN and LAN.

    I still see very low number of ack packets per second, less than 10, even when two video streams are going at the same time, about 6Mbit/sec total throughput.

    My Floating rule:

    Action: Match
    WAN
    Any Direction
    IPV4
    TCP only
    All sources, all source ports
    All destinations, all destination ports
    State Type = Keep
    Ackque = qAck
    Queue = qInternet (defined on WAN side)

    In the Floating Firewall rule list, it shows zero states, but hundreds of thousands of evals, which is what you would expect.

    Do you think changing it to Pass instead of Match will get the traffic marked correctly?  Anything else I should check?

    Thank you.



  • 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.