..not sure if my Traffic Shaper settings are correct?



  • I have just setup HFSC traffic shaping, all the queues are working properly, however, when I saturate the bandwidth pfSense shows lots of LAN Errors In? and also there appears to be far too many DROPS in queues.

    I don't quite understand what percentages I should use for bandwidth and queue sizes etc, would be great if anybody could point out if there is obvious problems with my shaper:

    ISP Speed:
    70 Mbit/s Download / 18 Mbit/s Upload

    Interfaces:
    WAN + LAN + WLAN

    Queues used for:
    qOthersCritical > single VOIP Phone + 1x radio stream upload
    qOthersHigh > http/s + email + dns
    qOthersLow > torrent p2p

    LAN
    qLink > Priority 2 > Queue limit 1000 > Bandwidth 20%
    qInternet > Bandwidth 65 Mbit/s > Upperlimit m2 65Mb > Link m2 65mb
    qACK > Priority 6 > Bandwidth 20% > Link m2 20%
    qOthersCritical > Priority 7 > Explicit Congestion Notification > Bandwidth 10% > Real m2 320Kb
    qOthersHigh > Priority 5 > Explicit Congestion Notification > Bandwidth 20% > Link m2 20%
    qOthersLow > Priority 4 > Explicit Congestion Notification > Bandwidth 10% > Link m2 10%

    WLAN
    qLink
    qInternet > Bandwidth 32 Mbit/s > Upperlimit m2 32Mb > Link m2 32mb
    qACK > Priority 6 > Bandwidth 20% > Link m2 20%
    qOthersCritical > Priority 7 > Explicit Congestion Notification > Bandwidth 10% > Real m2 320Kb
    qOthersHigh > Priority 5 > Explicit Congestion Notification > Bandwidth 20% > Link m2 20%
    qOthersLow > Priority 4 > Explicit Congestion Notification > Bandwidth 10% > Link m2 10%

    WAN
    qLink > Priority 6 > Explicit Congestion Notification > Bandwidth 20% > Link m2 20%
    qDefault > Priority 4 > Default Queue > Explicit Congestion Notification > Bandwidth 10%
    qOthersCritical > Priority 7 > Explicit Congestion Notification > Bandwidth 10% > Real m2 320Kb
    qOthersHigh > Priority 5 > Explicit Congestion Notification > Bandwidth 20% > Link m2 20%
    qOthersLow > Priority 3 > Explicit Congestion Notification > Bandwidth 10% > Link m2 10%



  • I would simplify it. Just do VOIP & radio on WAN.



  • Ok I will give it a go, I will delete all queues apart from WAN. Are there any rules regarding the total amount of bandwidth percentage for all queues per interface? I just made up the percentages so I'm not sure if they are correct.



  • @wizbit:

    Ok I will give it a go, I will delete all queues apart from WAN. Are there any rules regarding the total amount of bandwidth percentage for all queues per interface? I just made up the percentages so I'm not sure if they are correct.

    Personally, percentages confuse me. I prefer explicit bitrates.
    VOIP, for example, usually uses 64-128Kbit, so allocate approximately (or exactly) that much.
    Radio is probably 128-256Kbit.
    Also, percentages are dynamic, which I do not like.

    If you constantly saturate download, the traffic-shaping is slightly different (than upload), so throwing generic values around will usually not get the results you want.

    If you want to better understand QoS/traffic-shaping, this QoS tutorial is the best I have came across.



  • I thought the whole idea of the traffic shaper is to be dynamic otherwise the traffic shaper will be acting like a limiter?



  • @wizbit:

    I thought the whole idea of the traffic shaper is to be dynamic otherwise the traffic shaper will be acting like a limiter?

    Let me clarify what I meant.
    Let's say you have a 128Kbit VOIP line and 512Kbit of total interface bandwidth.
    If you set the VOIP queue to 25% (128Kbit), everything is fine.

    Then you switch ISPs and now only have a 256Kbit upload, so you change the interface bandwidth. Now your VOIP queue is 64Kbit. No good.

    If you set actual bitrates, you will not have this problem. HFSC is about precise guarantees and predictabiity.



  • Right I see what you mean, however, how can I set a bandwidth for http/s as this can depend on how many users are viewing websites, downloading, etc ?



  • At 70Mb/s, the default queue size of 50 is too small. If you're concerned about dropped packets, increase the queue size. even better, enable CoDel as the child disc.





  • @wizbit:

    Right I see what you mean, however, how can I set a bandwidth for http/s as this can depend on how many users are viewing websites, downloading, etc ?

    Technically, you can only fully control traffic that you transmit. QoS/traffic-shaping is most effective on upload traffic. HTTP(S) browsing will primarily be download traffic, which you cannot really prioritize. Actually, downloads (incoming WAN traffic) are only controlled as a side-effect of controlling what the LAN interface is able to transmit.

    Ultimately, just create VOIP, radio, and bulk/other/default queues on WAN. Apply Codel to the default queue then see if that works. This will solve most problems with upload.

    Unless you are well-versed in the intricacies of traffic-shaping, I would stick with simple rules and only add additional rules if you have a problem that needs fixing.

    If you have problems with download bufferbloat, there are a few ways to deal with it, but sadly you are limited because of your multi-LAN setup, because interfaces cannot share bandiwdth… If you had one LAN interface, I would say setup 1 queue on your LAN with a bitrate of 90-98% (lower if traffic is p2p) of your measured download speed and set the queue size to 1 (so it acts like a traffic-policer, rather than a traffic-shaper). That would effectively stop bufferbloat on downloads.

    With your multi-LAN setup, you would need to do the same as above, but give each interface half of the bandwidth, which is no good...

    In theory, you could limit the outgoing WAN ACK rate which would limit download rates, but ACK rates are not an exact science, so this is pretty damn hard to configure, requiring a bit of trial and error. It should allow WLAN/LAN to better share the full download bandwidth than the sub-optimal 50/50 split though.


Log in to reply