Having used the Web GUI for my SQM to set up cake, I was wondering if there is a way to test if diffserv4 is active and if per host isolation is working? In the queue discipline tab and under advanced and then dangerous in the option:
Advanced option string to pass to the ingress queueing disciplines; no error checking, use very carefully. - I have this code- diffserv4 nat dual-dsthost ingress mpu 64
And in the other option-
Advanced option string to pass to the egress queueing disciplines; no error checking, use very carefully-
I have this code- diffserv4 nat dual-srchost mpu 64
Is this correct? This is my first time using openwrt and I'm very new to it all!
Thanks in advance
(I attached a picture in case I made no sense!)
It seems right.
if you ssh into the router and run tc -s qdisc you will see a summary of info on your qdiscs... it should talk about the 4 tins into which traffic can flow and give a bunch of statistics etc.
This is what I get:
And with that setup I've noticed my speeds are not capped at the rate I set so the SQM is not working.
Yeah, SQM is not up and running (yet). So, having saved your SQM configs etc, the easiest thing is to do a simple reboot.
I seem to have problems if i leave diffserv4 in so I've removed it and all seems decent. Have to do some real world tests to see what's what.
I don't really know if diffserv4 is what I want anyway, I just want a smooth gaming connection without limiting other devices to a crawl.
diffserv4 should work, so if it doesn't I'm sure someone would like to know about it. On the other hand, it might not be all that useful for you, for example if you don't have DSCP tags on your packets then it won't work any different really.
1 Like
One way to test is to issue the following command on the router's command line interface:
SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm stop ; SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm start
or, if using OpenWrt >= 19.0 check the "Create log file for this SQM instance under /var/run/sqm/${Interface_name}.[start|stop]-sqm.log." checkbox in the GUI and start SQM then look under /var/run/sqm for a overky verbose log-file.
1 Like
OK, I've done that in SSH and have the results, what am I looking for to see if the correct things are active? I'll post pictures as well.
BTW, you can just copy and paste the text from the terminal window into the edit window of the forum, just put three backticks "```" in a line before and after the pasted text like so:
Example Text
2nd line
...
and you get a nicely quoted inset that contains machine readable text and is for example nicer to read on a small screen like a smartphone that large images.
And please select layer_cake.qos if you want to use DSCPs, piece_of_cake tries hard to force a single priority tier... (you can override it, but why not select the better fitting qos script in the first place?)
the "nonexistent directory error" is suspicius, could you please post the output of:
cat /etc/os-release
tc -s qdisc
Sorry for the slow reply, would've responded that I was out of town for today but didn't want to dilute the thread in case anyone used it in the future-
Output of first command-
NAME="OpenWrt"
VERSION="19.07.1"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 19.07.1"
VERSION_ID="19.07.1"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r10911-c155900f66"
OPENWRT_BOARD="ath79/generic"
OPENWRT_ARCH="mips_24kc"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt 19.07.1 r10911-c155900f66"
Output of second command-
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 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 9154433425 bytes 7050677 pkt (dropped 0, overlimits 0 requeues 4)
backlog 0b 0p requeues 4
maxpacket 1506 drop_overlimit 0 new_flow_count 8 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc cake 8031: dev eth1 root refcnt 2 bandwidth 6Mbit diffserv4 dual-srchost nat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 72
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
memory used: 0b of 4Mb
capacity estimate: 6Mbit
min/max network layer size: 65535 / 0
min/max overhead-adjusted size: 65535 / 0
average network hdr offset: 0
Bulk Best Effort Video Voice
thresh 375Kbit 6Mbit 3Mbit 1500Kbit
target 48.4ms 5.0ms 6.1ms 12.1ms
interval 143.4ms 100.0ms 101.1ms 107.1ms
pk_delay 0us 0us 0us 0us
av_delay 0us 0us 0us 0us
sp_delay 0us 0us 0us 0us
backlog 0b 0b 0b 0b
pkts 0 0 0 0
bytes 0 0 0 0
way_inds 0 0 0 0
way_miss 0 0 0 0
way_cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 0 0 0
bk_flows 0 0 0 0
un_flows 0 0 0 0
max_len 0 0 0 0
quantum 300 300 300 300
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
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 eth0.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8032: dev ifb4eth1 root refcnt 2 bandwidth 28Mbit diffserv4 dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 72
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
memory used: 0b of 4Mb
capacity estimate: 28Mbit
min/max network layer size: 65535 / 0
min/max overhead-adjusted size: 65535 / 0
average network hdr offset: 0
Bulk Best Effort Video Voice
thresh 1750Kbit 28Mbit 14Mbit 7Mbit
target 10.4ms 5.0ms 5.0ms 5.0ms
interval 105.4ms 100.0ms 100.0ms 100.0ms
pk_delay 0us 0us 0us 0us
av_delay 0us 0us 0us 0us
sp_delay 0us 0us 0us 0us
backlog 0b 0b 0b 0b
pkts 0 0 0 0
bytes 0 0 0 0
way_inds 0 0 0 0
way_miss 0 0 0 0
way_cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 0 0 0
bk_flows 0 0 0 0
un_flows 0 0 0 0
max_len 0 0 0 0
quantum 300 854 427 300
To me it looks like diffserv4 is working due to the different classifications, but I may be way off. How would you go about optimizing this for gaming to be priority over everything else? I have 35/10 FTTC BT line in the UK if that helps. Thanks so much for your help so far.
EDIT: The router did not have an active connection at the time as brother was uploading an important project and couldn't have any issues with restarts or setting changes
Yes, there are two cake instances on eth1 (egress) and in ifb4eth1 (ingress) that both are configured for diffserv4, but none of the shapers has seen any traffic. That might be okay, if tc -s qdisc was run immediately after instantiating these shapers, but if there was some uptime, this looks dubious.
And that nicely explains the complete lack of traffic I assume...
Personally, I would simply go and try how well this simple per-internal-IP-fairness mode might not already allow decent gaming. All you need to make sure is that the computer/console you game on is not doing crazy things in the back ground, like torrenting or downloading of bag patches...
Next step might be to selectively mark a few game packets such that they fall into the higher priority tins., but I would only do this if it proves to be necessary/helpful. Please note that I do not play on-line games myself, so have very little personal experience (I stopped playing/caring for FPS games with the original quake in the mid 90s)
Great, so this is a pretty recent sqm-scripts version. Thanks for the data.
I think I may have found the source of my issue, the internet has been up for about 15 mins with PC game and PS4 being played, a Tv show being streamed and then general activity like phone notifications etc look-
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 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 9410859611 bytes 7314291 pkt (dropped 0, overlimits 0 requeues 4)
backlog 0b 0p requeues 4
maxpacket 1506 drop_overlimit 0 new_flow_count 8 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc cake 8031: dev eth1 root refcnt 2 bandwidth 6Mbit diffserv4 dual-srchost nat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 72
Sent 16047802 bytes 128607 pkt (dropped 5, overlimits 33128 requeues 0)
backlog 0b 0p requeues 0
memory used: 73408b of 4Mb
capacity estimate: 6Mbit
min/max network layer size: 16 / 1500
min/max overhead-adjusted size: 72 / 1544
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 375Kbit 6Mbit 3Mbit 1500Kbit
target 48.4ms 5.0ms 6.1ms 12.1ms
interval 143.4ms 100.0ms 101.1ms 107.1ms
pk_delay 0us 1.0ms 0us 0us
av_delay 0us 52us 0us 0us
sp_delay 0us 13us 0us 0us
backlog 0b 0b 0b 0b
pkts 0 128612 0 0
bytes 0 16051142 0 0
way_inds 0 3981 0 0
way_miss 0 1965 0 0
way_cols 0 0 0 0
drops 0 5 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 3 0 0
bk_flows 0 1 0 0
un_flows 0 0 0 0
max_len 0 1514 0 0
quantum 300 300 300 300
qdisc ingress ffff: dev eth1 parent ffff:fff1 ----------------
Sent 254997982 bytes 262947 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 eth0.1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8032: dev ifb4eth1 root refcnt 2 bandwidth 28Mbit diffserv4 dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100.0ms noatm overhead 44 mpu 72
Sent 258603718 bytes 262897 pkt (dropped 50, overlimits 99872 requeues 0)
backlog 0b 0p requeues 0
memory used: 309504b of 4Mb
capacity estimate: 28Mbit
min/max network layer size: 46 / 1500
min/max overhead-adjusted size: 90 / 1544
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 1750Kbit 28Mbit 14Mbit 7Mbit
target 10.4ms 5.0ms 5.0ms 5.0ms
interval 105.4ms 100.0ms 100.0ms 100.0ms
pk_delay 0us 99us 0us 0us
av_delay 0us 35us 0us 0us
sp_delay 0us 9us 0us 0us
backlog 0b 0b 0b 0b
pkts 0 262947 0 0
bytes 0 258679240 0 0
way_inds 0 51 0 0
way_miss 0 1934 0 0
way_cols 0 0 0 0
drops 0 50 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 3 0 0
bk_flows 0 1 0 0
un_flows 0 0 0 0
max_len 0 1514 0 0
quantum 300 854 427 300
qdisc fq_codel 0: dev pppoe-wan root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn
Sent 13217877 bytes 128490 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
From my very inexperienced POV it looks like everything is classified into 1 tin, hence why the experience in games is poor.
Well, diffserv4 expects your traffic to use DSCP marks and the cake uses these DSCP marks to steer each packet into the desired priority tin. Leaving everything in the best effort tin is the default (dscp mark 0 is basically un-marked or what ~90% of internet traffic carries). So it is not at all puzzling that everything ended in best effort, the bigger question is, did the different uses actually interfere with each other? Looking at the minuscule number of drops and low XX_delay values I would assume that all flows should have been served with low latency, so did you encounter any gaming issues (are the PS4 and the PC connected via WLAN/WiFi or via cabled ethernet?)
Both are ethernet. The experience on both was similar, smooth about half the time, then big spikes in ping the other half (making it quite unplayable). I'm assuming that it was probably the video buffering or someone looking at something on their phone etc.
this is the typical issue. you can't control DSCP on the download direction because the IFB queues the packets before iptables gets them, so the usual way to control DSCP isn't available. however in the upstream direction it works fine, you can tag dscp with custom iptables rules and the wan egress queue will honor them.
I've been trying to do a thread on using nftables for QoS, but everyone had issues with nftables breakage in 19.x.x and there hasn't been any resolution on that.
1 Like
Okay, that is quite odd, could you post the tc -s qdisc output from after such a latency episode please?
With your fual-xxxhost isolation configuration different computers in your Homenetwork should be reasonably well isolated from each other, so unless you have very large number of active computers, videostrwaming and gaming should not interfere. Very large in comparison to your bandwidth, that is, assuming gaming traffic is roughly 2Mbps, then you should be able to afford around 16 additional active hosts....
There have been some vague reports about interactions between diffserv4 and the fual-xxxhost options, so could you also repeat you test without the diffserv4 added to the qdisc_opts and with piece_of_cake instead of layer_cake?
The point is for his use-case diffserv marking should not even be required if the host isolation would work well....
EDIT: That is not to say, that getting DSCPs for ingress up and running would not be a good thing and might help to further optimize the OP's configuration for additional robustness.
Yep, true enough. I wonder if it isn't just upstream stuff that's causing the issue. Perhaps cutting bandwidth to something like 15Mbps to try to reduce congestion in the local neighborhood switch or whatever. @Arcapulse
2 Likes
Ok, I have changed the settings to 15mbps and removed diffserv4 as well as gone back to piece of cake instead of layer of cake. The tc -s qdisc from before were after latency episodes, and I won't be able to play and have people on the network until later on (I might actually have to artificially have things running as I'm home alone for the next few days).
I thought it might be helpful to post the modem stats just in case there's anything that's alarming or may be helpful to change or not-
I don't think I've touched anything on it but browsing through the settings there are a few ones that caught my eye. Such as choice between path 0 and 1 and looking at the number of errors on path 0, but again I don't know if path 1 is actually usable. Then there was IP_Bridged mode when I thought it should be PPPoE bridged which is the other option, as I'm using PPPoE. Lastly there was an option somewhere for normal priority and high priority for something (possibly packets). Anyway, I've left all at default for now, thanks again!
