Cake QOS R7800, expectations

Can you post a link to the results page from a dslreports speedtest with those settings?

Sure;

So, that looks normal.

The behavior you mention about streams or downloads stalling, can you reproduce it consistently? or is it spotty?

I haven't used Usenet since the 1900's :slight_smile: but I looked up NZBGET and it says:

"Unlike downloads from www or ftp the download from usenet requires quite a lot of computation work. NZBGet is optimized for performance and uses very little memory at the same time."

Perhaps you have a CPU issue on your computer streaming two HD videos and, doing a Usenet download could be an issue for computing power?

I can reproduce it yes, I was downloading on the PC and trying to watch two twitch streams. One on an iPad pro and the other on a Galaxy S8, one of the devices would just stop and the others would continue. As soon as I stopped the download for the PC the other stream would continue playing back. The Usenet download didn't seem to be getting throttled that much to be honest.

I would say an average twitch stream is up to about 10Mbps at most but the gaming machine was still running at about 44Mbps. This is what made me think that I was expecting either too much or I didn't know how it should be working.

The traffic is HHTPS encrypted but I don't think that should matter should it, its all about fair sharing with Cake?

Yes, but perhaps you want per-internal-ip sharing, since my guess is your Usenet downloader probably opens up many many different connections, and so per-stream fairness is going to be giving most of the bandwidth to the downloader. per-ip fairness would require a few minor tweaks, @moeller0 is the expert there but you can start by looking at wiki: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#making_cake_sing_and_dance_on_a_tight_rope_without_a_safety_net

1 Like

The other option would be to somehow identify those streams and tag them with DSCP=CS1 and use a more complicated configuration described in excruciating detail: Ultimate SQM settings: Layer_cake + DSCP marks

1 Like

I will take a look at the links thankyou, the Newsgroup downloader is set to 8 as the maximum number of connections to the server. Would this be enough to make a difference?

Yes, as by default all streams get similar bandwidth, so your 8 download streams + 2 video streams would get 80% of the bandwidth to downloading and 10% to stream on iPad, 10% stream on phone. Whereas per-ip-fairness would get 33% to downloading 33% to stream on iPad, 33% to stream on Phone.

1 Like

Thank you that makes much more sense to me now, I will have a look at setting up the per-ip-fairness as that does indeed sound like what I want, going forward also looking at the second post that mentions tagging the streams as ideally I would want to substantially reduce any downloading traffic.

Looking at the wiki I am liking the look of " Per-Host Isolation" as that seems to deal with the issue that I am having with multiple connections taking more than their fair share.

I will give that a try now!

Also the last point that I must mention as it is strange to me as that I seem to be getting better range and throughput with the AC86U that I do with the X4S where all the reviews that I have read state that the X4S has better range and throughput which I find strange.

Per host isolation will solve your problem as stated, but you'll still have the issue within the one computer that does the usenet download. So if you try to stream a video there, you'd maybe get 8/9 of the bandwidth going to the download and 1/9 going to your video stream.

In that case you can maybe cut the number of simultaneous connections to say 2 or 3 and avoid this problem, or you can try to tag those streams and use diffserv4 or something. You may also have bandwidth limiting settings on your downloader, you could request that it uses no more than say 20Mbps at any given time, or during certain hours or whatever, will take longer to download, but since you're probably doing long downloads anyway, it's not something you're necessarily waiting on so its all good.

I entered the code as stated in the wiki but it made no difference and the buffering on both video streams was almost instant as soon as I started the download.

Here are the statistics of the traffic control after running the download and the two streams;

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 mq 0: dev eth0 root
 Sent 118132479 bytes 579578 pkt (dropped 0, overlimits 0 requeues 13082)
 backlog 0b 0p requeues 13082
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
 Sent 118132479 bytes 579578 pkt (dropped 0, overlimits 0 requeues 13082)
 backlog 0b 0p requeues 13082
  maxpacket 1514 drop_overlimit 0 new_flow_count 8536 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc mq 0: dev eth1 root
 Sent 1013670174 bytes 926835 pkt (dropped 0, overlimits 0 requeues 19369)
 backlog 0b 0p requeues 19369
qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
 Sent 1013670174 bytes 926835 pkt (dropped 0, overlimits 0 requeues 19369)
 backlog 0b 0p requeues 19369
  maxpacket 1514 drop_overlimit 0 new_flow_count 14253 ecn_mark 0
  new_flows_len 0 old_flows_len 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 eth1.1 root refcnt 2
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8004: dev eth0.2 root refcnt 2 bandwidth 17Mbit besteffort dual-srchost nat nowash no-ack-filter split-gso rtt 100.0ms raw overhead 0
 Sent 118131653 bytes 579571 pkt (dropped 1812, overlimits 105275 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 1Mb of 4Mb
 capacity estimate: 17Mbit
 min/max network layer size:           24 /    1514
 min/max overhead-adjusted size:       24 /    1514
 average network hdr offset:           14

                  Tin 0
  thresh         17Mbit
  target          5.0ms
  interval      100.0ms
  pk_delay        111us
  av_delay         13us
  sp_delay          8us
  backlog            0b
  pkts           581383
  bytes       120862900
  way_inds         2593
  way_miss         4563
  way_cols            0
  drops            1812
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len          1514
  quantum           518

qdisc ingress ffff: dev eth0.2 parent ffff:fff1 ----------------
 Sent 1457720839 bytes 1053214 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc cake 8005: dev ifb4eth0.2 root refcnt 2 bandwidth 60Mbit besteffort dual-dsthost nat wash no-ack-filter split-gso rtt 100.0ms raw overhead 0
 Sent 1464595474 bytes 1048008 pkt (dropped 5206, overlimits 1170090 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 420Kb of 4Mb
 capacity estimate: 60Mbit
 min/max network layer size:           60 /    1514
 min/max overhead-adjusted size:       60 /    1514
 average network hdr offset:           14

                  Tin 0
  thresh         60Mbit
  target          5.0ms
  interval      100.0ms
  pk_delay        1.6ms
  av_delay        362us
  sp_delay         10us
  backlog            0b
  pkts          1053214
  bytes      1472465835
  way_inds        28551
  way_miss         4768
  way_cols            0
  drops            5206
  marks               0
  ack_drop            0
  sp_flows            0
  bk_flows            1
  un_flows            0
  max_len          1514
  quantum          1514

qdisc fq_codel 0: dev pppoe-wan root refcnt 2 limit 10240p flows 1024 quantum 1518 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
 Sent 108070640 bytes 581234 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1492 drop_overlimit 0 new_flow_count 51 ecn_mark 0
  new_flows_len 1 old_flows_len 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
root@OpenWrt:~#

These are the settings I am using on my R7800 with a PPPoE connection 50/10: no video buffering during any downloads. Your overhead value might be different, though. What is your connection to your ISP?

config queue 'wan'
	option debug_logging '0'
	option verbosity '5'
	option linklayer 'ethernet'
	option linklayer_advanced '1'
	option tcMPU '64'
	option qdisc_advanced '1'
	option ingress_ecn 'ECN'
	option egress_ecn 'NOECN'
	option qdisc_really_really_advanced '1'
	option iqdisc_opts 'nat dual-dsthost mpu 64'
	option eqdisc_opts 'nat dual-srchost mpu 64'
	option enabled '1'
	option interface 'pppoe-wan'
	option qdisc 'cake'
	option script 'piece_of_cake.qos'
	option squash_dscp '0'
	option squash_ingress '0'
	option linklayer_adaptation_mechanism 'default'
	option tcMTU '2047'
	option tcTSIZE '128'
	option overhead '34'
	option download '47500'
	option upload '9500'
1 Like

I have 64Mbps down currently and 20Mbps up, here is my config;

config queue 'eth0'
        option linklayer 'none'
        option enabled '1'
        option download '60000'
        option upload '17000'
        option interface 'eth0.2'
        option qdisc 'cake'
        option script 'piece_of_cake.qos'
        option debug_logging '1'
        option qdisc_advanced '1'
        option squash_dscp '1'
        option squash_ingress '1'
        option ingress_ecn 'ECN'
        option egress_ecn 'NOECN'
        option qdisc_really_really_advanced '1'
        option iqdisc_opts 'nat dual-dsthost'
        option eqdisc_opts 'nat dual-srchost'
        option verbosity '8'

root@OpenWrt:~#

Mmh, I assume this is a VDSL (aka Fibre to the Curb/Cabinet) link in the UK, correct?
In that case, I wonder whether you connect the router to a modem that does PPPoE?
(I guess the overhead values need a bit of tuning, but that most likely is not causing your observed issue.)
If that is true could you please get a reading of the modem's link parameters (the synchonization values with the dslam are off interest here)?
Finally you could try adding the keyword ingress to iqdisc_opts:
option iqdisc_opts 'nat dual-dsthost ingress'
That should make the bandwidth sacrifice automatically more-or-less scale with the number of concurrent incoming flows, which might slightly ameliorate your problem.

HI all,

I managed to get this sorted by restarting the config from scratch, after I did that and re-entered the commands I now have it working as intended. by default now if anything tried to take too much bandwidth, like the PC for example it is restricted and the other devices get a fair share of the bandwidth.

Should I expect the wireless coverage to be less when using OpenWRT? I have both the AC86U and the X4S at the moment as I am deciding which one to keep. With the routers in the exact same place when using 2.4ghz my Ring doorbell goes from a signal of -53db to -62db. Also my 5ghz is weaker than it is on the AC86U which seems to contradict the reviews for the X4S being the best in that regard.

Use speed tests to determine coverage rather than simply signal strength. Stand where your Ring device is and run a speed test on your phone or a tablet. Is there a difference?

Beamforming and mu-mimo and etc can be more relevant, and they are dynamic technologies that vary with conditions.

OT, but some info about the Ring devices: https://www.macrumors.com/2019/01/10/ring-employees-customer-camera-access/

1 Like

Thanks for the Ring info, looks shady on their part to say the least.

I still have both devices so I will have to put them to the test against each other, not sure what the best software to use is to measure. I have an iPad pro so I could just do a DSLreports speedtest from various locations maybe. I think that the X4S is holding its own for the most part, but in certain areas the AC86U is just better for some reason.

I have been playing around with the QOS tonight and it is working nicely now, I can have 5-6 streams going with a Usenet download going without issue. If I try and play a video on the PC with the Usenet download then the streams on that computer are the only ones to buffer as it is limiting the bandwidth the PC can have as a device compared to the others.

I like Cake QOS as it seems very fluid in operation and on its own without user intervention it does a good job, whereas the AC86U has to have a QOS script to make the Trend MIcro solution work well and also certain stuff needs re-tagging, however once that is done it does allow for more things to happen on the same bandwidth hungry devices but only if the traffic is tagged properly. I see that I can could use something like FireQOS but then that looks complicated compared to the FreshJR QOS script for the AC86U.