High (game) latency when AltQ enabled and traffic >40Mbit

  • Hi,
    we have 200mbit line. 2 pfsense nodes in active/passive with carp. If usage is below 40Mbit/s with AltQ enabled with default ruleset for games the latency is OK and queues are filled as expected. If the usage of the line goes above 60Mbit latency/pings start to fluctuate and soon games become unplayable (>150ms lag). If i artificially load the link even more to let's say around 100Mbit the latency goes out the roof. If i disable AltQ, at that moment, my ping comes down back to 7ms! As long as we don't come near 200Mbit there is no latency when AltQ is disabled. Also trough-put of whole line drops substantially when AltQ is enabled. Can any1 help me with removing this lag when using traffic shaper? I wouldn't ming sacrifice some BW to have better latency for games.

  • If this is 1.2+ you cannot do a thing from the gui, sorry.

  • Is this the case for both of my problems?
    I'm aware i cannot fix "bandwidth loss" when using AltQ in 1.2, but what about the latencies?

    What version should satisfy my needs? Maybe i can test it?

  • 2.0 and you have to tweak you tbr and queue length to have better response.

  • OK, so bad latency is only doe to queue length? What if i manually increase queue length on 1.2?

    I'll start testing 2.0 soon.

  • Its not only about queue length.
    Read this extracted from http://www.sonycsl.co.jp/~kjc/software/altq-new-design.txt
    It is very low level detail but still prevails with the tbr option you can configure on 2.0

    2.5 tokenbucket regulator
    The purpose of the token bucket regulator is to limit the amount of
    packets that a driver can dequeue.
    A token bucket has "rate" and "size".  Tokens accumulate in a bucket
    at the average "rate", up to the bucket "size".
    A driver can dequeue a packet as long as there are positive tokens,
    and after a packet is dequeued, the size of the packet is subtracted
    from the tokens.
    (note that this implementation allows the token to be negative as a
    deficit, and differs from a typical token bucket that compares the
    packet size with the remaining tokens beforehand.)
    It is important to understand the roles of "rate" and "size".
    The bucket size controls the amount of burst that can dequeued at a
    time, and controls a greedy device trying dequeue packets as much as
    possible.  This is the primary purpose of the token bucket regulator
    in ALTQ.  Thus, the rate should be set to the wire speed.  (even if
    the rate is set to a larger value, it does not matter much since our
    focus is excessive bursts.)
    On the other hand, if the rate is set to a smaller value than the wire
    speed, the token bucket regulator becomes a shaper that limits the
    long-term output rate.
    Another important point is that, when the rate is set to more than the
    actual transfer speed, tx complete interrupts can trigger the next
    dequeue.  However, if the rate is smaller, the rate limit would be
    still in effect at the tx complete interrupt, and the rate limiting
    falls back to the kernel timer to trigger the next dequeue.  In order
    to achieve the target rate under timer-driven rate limiting, the
    bucket size should be increased to fill the timer interval.

    From pf manual page

         tbrsize <size>Adjusts the size, in bytes, of the token bucket regulator.  If not
    	   specified, heuristics based on the interface bandwidth are used to
    	   determine the size.</size> 

  • Thank you for info.

Log in to reply