Significant speed drop when enabling SQM on a slow ADSL2+ service

My parents have an extremely slow ADSL2+ service and I'm trying to see if SQM can help improve their connection.

After running tests with speedtest-netperf.sh with -c and -n 3 options on the router (EA7300) and multiplying the numbers with 0.95, I entered 5747 for the download speed and 256 for the upload speed. I have set the link layer adaptation values to ATM and 44. Please note that this router is behind a modem/router combo but no other devices are connected to the modem/router so SQM is running on EA7300.

After enabling SQM and running the same tests, the download speed drops to 3090 and the upload speed drops to 90. The CPU utilization is about 5% while running the tests.
This is a little unexpected to me because I see a very little drop in my own cable connection and with following the same procedure.

I'm not sure what's causing this issue but I'd really appreciate any input or suggestions.

Here is the output of a few commands I ran that might help diagnose the problem.

cat /etc/config/sqm

config queue 'eth1'
	option debug_logging '0'
	option verbosity '5'
	option qdisc 'cake'
	option script 'piece_of_cake.qos'
	option interface 'wan'
	option linklayer 'atm'
	option overhead '44'
	option download '5747'
	option upload '256'
	option enabled '1'

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 1427708843 bytes 4246989 pkt (dropped 0, overlimits 0 requeues 121)
 backlog 0b 0p requeues 121
  maxpacket 17256 drop_overlimit 0 new_flow_count 27422 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc cake 8011: dev wan root refcnt 2 bandwidth 256Kbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms atm overhead 44
 Sent 927192 bytes 5092 pkt (dropped 304, overlimits 7731 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 181727b of 4Mb
 capacity estimate: 256Kbit
 min/max network layer size:           28 /    1420
 min/max overhead-adjusted size:      106 /    1643
 average network hdr offset:           14

                  Tin 0
  thresh        256Kbit
  target           71ms
  interval        166ms
  pk_delay        116ms
  av_delay       32.1ms
  sp_delay        516us
  backlog            0b
  pkts             5396
  bytes         1244692
  way_inds            0
  way_miss          190
  way_cols            0
  drops             304
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len         15774
  quantum           300

qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
 Sent 4885792 bytes 5037 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 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 lan3 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan4 root refcnt 2
 Sent 0 bytes 0 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 br-vpn 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 noqueue 0: dev wginterface root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8012: dev ifb4wan root refcnt 2 bandwidth 5747Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms atm overhead 44
 Sent 4947706 bytes 5031 pkt (dropped 6, overlimits 3575 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 20800b of 4Mb
 capacity estimate: 5747Kbit
 min/max network layer size:           46 /    1420
 min/max overhead-adjusted size:      106 /    1643
 average network hdr offset:           14

                  Tin 0
  thresh       5747Kbit
  target            5ms
  interval        100ms
  pk_delay       2.55ms
  av_delay        494us
  sp_delay         24us
  backlog            0b
  pkts             5037
  bytes         4956310
  way_inds           60
  way_miss          202
  way_cols            0
  drops               6
  marks               0
  ack_drop            0
  sp_flows            1
  bk_flows            1
  un_flows            0
  max_len          1434
  quantum           300

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 cake 8011: dev wan root refcnt 2 bandwidth 256Kbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms atm overhead 44
qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
qdisc noqueue 0: dev lan1 root refcnt 2
qdisc noqueue 0: dev lan2 root refcnt 2
qdisc noqueue 0: dev lan3 root refcnt 2
qdisc noqueue 0: dev lan4 root refcnt 2
qdisc noqueue 0: dev br-lan root refcnt 2
qdisc noqueue 0: dev br-vpn root refcnt 2
qdisc noqueue 0: dev wlan1 root refcnt 2
qdisc noqueue 0: dev wlan0 root refcnt 2
qdisc noqueue 0: dev wginterface root refcnt 2
qdisc cake 8012: dev ifb4wan root refcnt 2 bandwidth 5747Kbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms atm overhead 44

ifstatus wan

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 29863,
	"l3_device": "wan",
	"proto": "dhcp",
	"device": "wan",
	"updated": [
		"addresses",
		"routes",
		"data"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "192.168.1.79",
			"mask": 24
		}
	],
	"ipv6-address": [

	],
	"ipv6-prefix": [

	],
	"ipv6-prefix-assignment": [

	],
	"route": [
		{
			"target": "0.0.0.0",
			"mask": 0,
			"nexthop": "192.168.1.1",
			"source": "192.168.1.79/32"
		}
	],
	"dns-server": [
		"192.168.1.1"
	],
	"dns-search": [

	],
	"neighbors": [

	],
	"inactive": {
		"ipv4-address": [

		],
		"ipv6-address": [

		],
		"route": [

		],
		"dns-server": [

		],
		"dns-search": [

		],
		"neighbors": [

		]
	},
	"data": {
		"leasetime": 86400
	}
}

ouch

at that speed, a single full size packet takes 1500*8/256 = 47 ms which is a quite long time for networking. Also your download/upload ratio is quite large 5747/256 = 22, I suspect you're probably seeing issues with insufficient upstream bandwidth to get good acknowledgement to keep the packets flowing, that's my first guess at least.

in the cake advanced settings try adding the setting ack-filter or even ack-filter-aggressive https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details

2 Likes

Thank you very much for your suggestion. I tried adding the parameters but that didn't change the outcome. I'll see if I can change their plan to something with a higher upload speed.

Mmmh, I would always also run a number of ookla (www.speedtest.net) and netflix (fast.com) speedtests to get a better feel of what the actual achievable speedtest results to close by servers are. the bufferbloat.net infrastructure is super sparse and hence not a good yard stick to estimate an internet access link's capacity. Maybe also run a dslreports speedtest, where after a free registration, can select the server locations from a list to make sure unfortunate trans-atlantic/pacific paths are avoided.

Also it would be good to look at the sync rates as reported by the ADSL modem to sanity check the speedtests.

Mmmh, this looks like the ISP is using some extreme encapsulation/tunneling (often a sign of problems ahead).

Not sure how long the uptime was, but 304 drops is not that much, nor are peak and average delay (compared to the target and the interval)

So that does not seem to indicate that cake throttles too hard here....

But with your router cascade the ISP modem-router might do whatever. Is there a chance of putting that into bridge mode or replace it by a plain modem (aka a privately bought modem router that can be configured into bridge mode, real plain modems do not seem to exist anymore).

1 Like

@maximusc A word of caution, though, with Ookla. If you measure the throughput to a server that belongs to your ISP, it measures the throughput between you and the ISP rather than your actual throughput on the Internet that's limited by the contracted speed.

Frop example, I have my BTHH5A reading VDSL2 download data rate of about 40Mbps, while my contracted speed is 30Mbps. Now if I use Ookla's Speedtest with a server of my ISP's (even if it's not anywhere near my exchange, but over 200km away, I get throughput well over 30Mbps, but if I use a servero f a different ISP, the throughput seems to be limited by the contract speed. So watch out for false results.

I think for your case, and considering this 5747/256, I think you probably check with your ISP about the theoretical upload throughput you are supposed to have because if they have a problem their side, you are unlikely to find the solution at yours.

1 Like

the bufferbloat.net infrastructure is super sparse and hence not a good yard stick to estimate an internet access link's capacity

This is certainly true. After running tests on speedtest.net, I got slightly better numbers, i.e. 6.6Mb/s for download and 0.5Mb/s for upload.

Not sure how long the uptime was

The uptime was less than a day.

Is there a chance of putting that into bridge mode

I'll see if I can put the modem/router combo in bridge mode and will report back.

Thank you for your suggestion. I used another ISP's servers when measuring download/upload speed.