Possible SQM issue, p2p download bogs down the network

I think I have an issue with SQM in my home network. When I am making a download from a P2P network using QBittorrent on my computer, it affects the entire network. It slows down so much that most webpages become inaccessible unless I refresh the page for a few times. I use a Mi 4A Gigabit as my router. I do not think I had this issue before buying the router. I can make direct downloads using the browser on my computer and still download from P2P networks with the torrent app on my phone without experiencing any issues.

What do you think is the cause of the issue here?

So you have issues when you try unlimited torrenting and latency-sensitive browsing on the same computer, but not if you separate these two uses to two different devices?

In which case, respectfully your problem might be that your torrent client is misconfigured.... Just enable sensible rate limits for download AND upload direction also limit the maximum number of connections to something sane. SQM will by default treat all flows equally and if an application like a torrent client uses a lot of parallel flow it gets more throughput than an application that uses only a few flows....

If however your problem occurs on all devices when you use the torrent client ob your computer sqm seems not to work as intended..

Please post the output of the following command issued on your router's command line interface (you can copy and paste the text from the terminal/ssh window into the forum, just click he </> preformatted text button and paste your text over the "type or paste code here" placeholder):

  1. ifstatus wan | grep -e device
  2. cat /etc/config/sqm
  3. tc -d qdisc
  4. tc -s qdisc

That will give baseline information about the sqm configuration and statistics.

1 Like

The issue occurs on all clients in the home network when I use QBittorrent on my computer. It persists even when I am downloading a single file with both download and upload speeds capped at lower values for testing.

Here is a link to the output of the commands if anyone deems it too long for a post.

root@OpenWrt:~# ifstatus wan | grep -e device
	"l3_device": "wan",
	"device": "wan",
root@OpenWrt:~# cat /etc/config/sqm

config queue 'eth1'
	option qdisc 'cake'
	option script 'piece_of_cake.qos'
	option enabled '1'
	option download '70000'
	option upload '4000'
	option debug_logging '0'
	option verbosity '5'
	option linklayer 'ethernet'
	option overhead '34'
	option interface 'wan'

root@OpenWrt:~# tc -d qdisc
qdisc noqueue 0: dev lo root refcnt 2 
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64 
qdisc noqueue 0: dev lan2 root refcnt 2 
qdisc noqueue 0: dev lan1 root refcnt 2 
qdisc cake 8009: dev wan root refcnt 2 bandwidth 4Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 34 
qdisc ingress ffff: dev wan parent ffff:fff1 ---------------- 
qdisc noqueue 0: dev br-lan root refcnt 2 
qdisc noqueue 0: dev wlan1 root refcnt 2 
qdisc noqueue 0: dev wlan0 root refcnt 2 
qdisc cake 800a: dev ifb4wan root refcnt 2 bandwidth 70Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 34 
root@OpenWrt:~# tc -s qdisc
qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64 
 Sent 1283982 bytes 6882 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev lan2 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 8009: dev wan root refcnt 2 bandwidth 4Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms noatm overhead 34 
 Sent 1250310 bytes 6830 pkt (dropped 1, overlimits 3224 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 165760b of 4Mb
 capacity estimate: 4Mbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:       62 /    1534
 average network hdr offset:           14

                  Tin 0
  thresh          4Mbit
  target            5ms
  interval        100ms
  pk_delay       4.66ms
  av_delay        504us
  sp_delay         11us
  backlog            0b
  pkts             6831
  bytes         1250376
  way_inds            5
  way_miss          685
  way_cols            0
  drops               1
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len          3028
  quantum           300

qdisc ingress ffff: dev wan parent ffff:fff1 ---------------- 
 Sent 6446826 bytes 7661 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 800a: dev ifb4wan root refcnt 2 bandwidth 70Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms noatm overhead 34 
 Sent 6543618 bytes 7654 pkt (dropped 7, overlimits 3064 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 141440b of 4Mb
 capacity estimate: 70Mbit
 min/max network layer size:           46 /    1500
 min/max overhead-adjusted size:       80 /    1534
 average network hdr offset:           14

                  Tin 0
  thresh         70Mbit
  target            5ms
  interval        100ms
  pk_delay       1.51ms
  av_delay        138us
  sp_delay          9us
  backlog            0b
  pkts             7661
  bytes         6554080
  way_inds            0
  way_miss          545
  way_cols            0
  drops               7
  marks               0
  ack_drop            0
  sp_flows            2
  bk_flows            1
  un_flows            0
  max_len          1514
  quantum          1514
1 Like

Mmmh, please try to add the following to your /etc/config/sqm"

	option qdisc_advanced '1'
	option qdisc_really_really_advanced '1'
	option eqdisc_opts 'nat'
	option linklayer 'ethernet'
	option iqdisc_opts 'nat ingress'

then issue /etc/init.d/sqm stop ; /etc/init.d/sqm start an repeat your test, the most important part is the nat keyword which will allow 'triple-isolate` to work... Please let me know whether that works better or not, and we will go to the next steps from there...

Outlook, triple-isolate tries to ascertain that no internal or internal host IP address can steal all the capacity for itself if other IP addresses also want to send/receive traffic, which often works quite well, but needs a correct view of the external and internal IP addresses and that is what the nat keyword is there for. But triple-isolate is not easy to predict and as an alternative, if the downloading and uploading directions are known is the use of dual-dsthost and dual-srchost as shown below which will implement strict per-internal-IP-fairness, which is relatively easy to predict and confirm.

	option qdisc_really_really_advanced '1'
	option eqdisc_opts 'nat dual-srchost'
	option iqdisc_opts 'nat dual-dsthost ingress'

Please note that this is in no way guaranteed to tackle your real problem, but IMHO worth trying....

2 Likes

Thanks for coming up with a potential solution. My tests will take a while because the issue is a bit random. I haven't changed any settings and can browse the internet while downloading on my PC right now. I will be sure to reply when I have the issue again and manage to test the new settings.

OK, if these issues are independent of your own router, maybe your ISP is at "fault" here maybe try one of the cake-autorate or sqm-autorate approaches that adaptively set the shaper limits to minimize latency under load... Because a static/fixed SQM configuration will only work if the true achievable rate through the ISP's network is >= the configured traffic shaper rate... if that is not the case than bufferbloat in your ISP's network will result in noticeable delay spikes on your side.

Came here having identical issues with OP, on the same router using the 21.02.2 build. Configuring the SQM with

Fixed the issue for me. I still limit P2P traffic but before setting this up, whole network would be bogged down even if I was downloading at 500KB/s now I am able to quadruple that.

Thanks !