SQM QoS problems

Installing and Using OpenWrt
1

Hi everyone, this is my first post here :slight_smile: i have been using a openwrt router for 2 weeks and i'm loving it. However there is one problem i am encountering: i set up SQM QoS to try and fix my bufferbloat (which is ridiculously high on my home connection), while that solved the bufferbloat, i am now having issues, in the sense that when i'm playing any game, the connection to the servers will just drop with a 10 seconds timeout if i am not the only one on the network, any idea how one could fix this? it's annoying having to disconnect every device just to play some matches every time. The guide i followed is https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm

here is my sqm qos config:



2

Your 3320 kbps down / 300kbps up connection is always going to be a little tricky. The main reason is imagine some process sends a full sized 1500 byte packet and immediately after your router sends it to the modem/ISP equipment a small 200 byte "game packet" comes in. The game packet will have to wait 1500 * 8 / 300000 = 40 ms for the first packet to be processed onto the wire until it can start to send the second 200 byte packet.

Furthermore, a game that sends 200 byte packets every say 0.01 seconds will use 160kbps or fully half of your upload bandwidth. A single VOIP call typically uses around 100kbps each way. Your connection is always going to be tight.

Now, that being said, there are some things you can do, and it seems like you shouldn't actually lose connection so that's something we can debug, but just be aware that your connection is never going to be super low latency, you'll always have around 50 to 100 ms of bufferbloat simply from how long it takes to send a packet down the wire, Worst case is you just sent 1500 bytes to the modem, and now you have a 1500 byte high priority packet to send, it will take 40ms to send the one "in the modem" and then another 40ms to send the high priority one.

All that being said, can you please run a DSLReports speedtest and post the results here: http://dslreports.com/speedtest

1 Like
3

At your ~3320/300 Kbps ADSL link you are unfortunately already deep in the "valley of pain". But still I would recommend to a) add the following to your /etc/config/sqm:

       option debug_logging '0'
        option verbosity '5'
        option qdisc_advanced '1'
        option squash_dscp '0'
        option squash_ingress '0'
        option ingress_ecn 'ECN'
        option qdisc_really_really_advanced '1'
        option linklayer 'ATM'
        option overhead '44'
        option linklayer_advanced '1'
        option tcMTU '2047'
        option tcTSIZE '128'
        option tcMPU '64'
        option linklayer_adaptation_mechanism 'default'
        option iqdisc_opts 'nat dual-dsthost ingress'
        option eqdisc_opts 'nat dual-srchost'
        option interface 'eth0.2'
        option download '3320'
        option upload '300'
        option qdisc 'cake'
        option script 'layer_cake.qos'
        option enabled '1'

This should give you per-internal-IP fairness (which at 300Kbps still will only help that much, if 10 devices want to send full MTU packets you are already seeing a delay of 0.4 seconds for the 11th). I would also try to DSCP mark the game packets for egress, so that they are send with higher priority than the normal packets. (This is conceptually easy for egress, but really nasty for ingress unfortunately).

Maybe you could post the content of:
0) tc -s qdisc # just as baseline

  1. tc -s qdisc # after gaming alone for say 10 minutes with no time outs
  2. tc -s qdisc # after gaming with concurrent users for the same 10 minutes (but at least long enough to actually encounter server timeouts).
1 Like
4


here are the test results :slight_smile:

5

Can you provide a link to the test results page so I can go there and look at the details? thanks.

6
7

i will try to do that asap and report back :slight_smile:

8

Thanks, the speed test and the bufferbloat both indicate that your speed is probably lower than the speed you're setting at 3320 / 300kbps, can you drop it to say 2600/190 and re-do the speed test?

9

will do, give me a second.

10

i have a feeling this isn't doing much, it's just slowing it down further, with 2600 set as the limit, it is now doing 2000. without any restriction it goes up to 4000 (in download)

11

But can you post a link to the results please? if it is doing something I can see the distribution of delays in the details section. Also, it was more important for the UPLOAD direction than the download. We can probably bump the download direction upwards again.

12

ok, here you go: https://www.dslreports.com/speedtest/44657160

13

Can you set your up and down stream count to 4 in the preferences and re-run? It looks to me like it's using 8 streams and this is just too much for your slow link and so i'm guessing it's failing to even be able to send the ACKs etc.

On the other hand, reducing the speed on upload did dramatically reduce the bufferbloat, with maximum pings now in the 200ms range instead of 1700ms, but the stalling out has to do with too many streams I believe.

1 Like
14

Please have a look at https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803/19 for how to use the dslreports speedtest for maximum information regarding bufferbloat (and have a look at Note 1 :wink: )

15

I see that he have to use QOS inbound with DSCP marks for ACK's ,SYN and other things!

16

I humbly disagree, special casing these is not going to help much. SYNs will be boosted by the sparse-flow boosting (during the handshake most/all flows are still considered to be sparse); and ACK prioritization can introduce packet reordering which is IMHO sub-optimal (and if an ACK flow is sparse it will also be boosted by the sparse flow mechanism). DSCPs, yes with that I can agree ;), and I would say that your thread over at https://forum.openwrt.org/t/ultimate-sqm-settings-layer-cake-dscp-marks/25832 would be a good place to start if ingress DSCP marking is "in play".
But this is orthogonal to his 10 second timeouts which seem to be the first thing to improve, no?

1 Like
17

I agree, it's really looks strange, but lets see how we would figure out the problem.

18

We may have scared off @icehax ? come back, we were just a few steps away from getting your connection tuned.