QLEN remains zero



  • Hello all,

    I have HFSC traffic shaping set up as shown in the screenshot attached (see file shaper.png).
    I am monitoring the queues in pfTop (see file pfTop.png).

    It is clear that that the different queues are being matched as the stats are increasing when a file transfer is done.
    However, the queue length (column QLEN in pfTop.png) remains zero.

    I've read somewhere that if the queue length remains zero, it means that no packets are going into the queue and therefore no shaping is being done. Is this correct?
    I increased the queue length of queue qIPVPN-Default on the root_re2 interface to 1000, but the QLEN column stats stay at zero when I started a file transfer.

    Can someone please shed some light?

    Thanks





  • Hello,

    Any help from anyone?



  • Hello,

    No one else having a similar issue?



  • Hello,

    An update:

    The bandwidth of the Internet connection WAN is 2Mbps (symmetrical).
    The bandwidth of the Internet connection WAN2_VLAN12 is 4/1 Mbps (ADSL: asymmetrical).

    I have made 2 changes since I posted this question:
    1. upgrade to version 2.1 BETA
    2. set the Upperlimit m2 value for the following parent queues:
      qWAN-Internet on interface WAN: 2Mb
      qLAN-IPVPN on interface LAN_VLAN6: 2Mb
      qADSL on interface LAN_VLAN6: 4Mb
      qInternet on interface WAN2_VLAN12: 1Mb

    Now, I see that the QLEN column in pfTop changes a little bit.

    Anyone can shed some light please?



  • Your queue length will remain zero because your are not in a backlogged state.

    Theses queues are known as the "backlogged queue."  Under normal conditions, packets are leaving the queues as quickly as they are entering, resulting in a zero net result.

    When your link becomes saturated and hits maximum bandwidth, backlog queuing will start to occur.  If the queue overflows, you will see packets drop to compensate.  This is when your priority queue settings become very important.  You generally want to see lower priority queues drop before high priority.



  • Thank you for having replied to my question.

    I agree with you 100%. However, I could see (from RRDTOOL) that the bandwidth used by the line was 100% or close to 100%, but the queue lengths were still not increasing.



  • Another function of the traffic shaper is the delaying of ACK packets when traffic reaches 100%.  This moderates the flow of traffic through your firewall and attempts to keep it from backlogging.

    Under normal conditions, backlogging should occur during severe spikes in network traffic, in which case your queuing will kick in.  This can literally happen in millisecond time frames and be difficult to observe.

    Your traffic shaper is most likely performing as it should.


Log in to reply