Thanks @dave14305.
With your shaper settings 54/17 the best you can expect as IPv4/TCP goodput (close to what many speedtests report):
IPv4:
54 * 64/65 * ((1500-8-20-20)/(1500+34)) = 50.32 Mbps
17 * 64/65 * ((1500-8-20-20)/(1500+34)) = 15.84 Mbps
IPv6:
54 * 64/65 * ((1500-8-40-20)/(1500+34)) = 49.63 Mbps
17 * 64/65 * ((1500-8-40-20)/(1500+34)) = 15.62 Mbps
So your 47.2/15.7 are not that bad...
Note: you specified ptm that is why the 64/65 reductiob is in there, but realistically instead of doing additional math for each individual packets, simply reduce the shaper rate to be <= 100-100*64/65 = 1.54%-age points below your PTM carrier's reported sync speed and you have done the same accounting but with static configuration time only calculations...
Yes, the dual-XXXhost modes really want to be used in combination with nat if used on an IPv4 link that uses masquerading...
Yes, it should for NATed IPv4...
2 Likes
You can add the ptm, overhead and ether-vlan to the script options if you want to try to get it as close to your qosify settings, but only if you trust those values. I’m a simple docsis guy, so not much advice here.
Your stats show you’re only configured now with noatm overhead 34.
But what does port 8080 map to in cake-qos-simple? I would assume the default to be always CS0/BE, no?
Exactly - I think packets (including those on 8080) will default to cs0. So @francisuk1989 is just comparing different cake bandwidths?
Again I would fold the PTM accounting into the shaper rate settings (given the non-cake speedtests, both 54 and 17 Mbps are small enough not having to bother about PTM) and instead of specifying ether-vlan I would adjust the numerical overhead... speaking of which 34 bytes in top of pppoe-wan accounts for VDSL2/PTM/VLAN/PPPoE so probably is just fine...
1 Like
Good point as i have no idea what port 8080 defaults with cake-qos-simple or if there no DSCP been broadcasted? where dos it go?
@Lynx i was giving an example on how i max out 55 compared to cake-qos-simple as i was only getting about 47 compared to qosify at 55 but @moeller0 has explained why. 
@francis I think the differences are just related to what you are setting the bandwidth and overheads to in cake-qos-simple here:
cake_ul_rate_Mbps=20 # cake upload rate in Mbit/s
cake_dl_rate_Mbps=7.5 # cake download rate in Mbit/s
cake_ul_options="diffserv4 dual-srchost nat wash no-ack-filter noatm overhead 0"
cake_dl_options="diffserv4 dual-dsthost nat nowash ingress no-ack-filter noatm overhead 0"
# cake-qos-simple configuration options:
ul_if=pppoe-wan # upload interface
dl_if="" # download interface override (normally left blank and IFB derived for $ul_if ingress)
cake_ul_rate_Mbps=17 # cake upload rate in Mbit/s
cake_dl_rate_Mbps=54 # cake download rate in Mbit/s
cake_ul_options="diffserv4 dual-srchost nat wash no-ack-filter pppoe-ptm ether-vlan noatm"
cake_dl_options="diffserv4 dual-dsthost nat nowash ingress no-ack-filter pppoe-ptm ether-vlan noatm"
# end of cake-qos-simple configuration options
/etc/init.d/cake-qos-simple download
qdisc cake 8008: root refcnt 2 bandwidth 54Mbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34
Sent 2815784 bytes 2052 pkt (dropped 1, overlimits 1425 requeues 0)
backlog 0b 0p requeues 0
memory used: 155392b of 4Mb
capacity estimate: 54Mbit
min/max network layer size: 40 / 1492
min/max overhead-adjusted size: 74 / 1526
average network hdr offset: 0
Bulk Best Effort Video Voice
thresh 3375Kbit 54Mbit 27Mbit 13500Kbit
@Lynx In your script where does ports e.g 80 or 443 map to in cake-qos-simple if theres no DSCP been used? Bulk?
Or do we just do; 192.168.1.253 been downloading over port 443
# designate packet for cake tin: bulk
chain dscp_set_bulk {
counter ip dscp set cs1
ip saddr 192.168.1.253 tcp dport 443 counter ip dscp set cs1 comment "James Xbox Downloads"
ip saddr 192.168.1.253 udp dport 443 counter ip dscp set cs1 comment "James Xbox Downloads"
Unless explicitly set, all DSCPs will be cs0 (Best Effort).
To set cs1 for a specific IP and port, I would put a line in here - something like (just guessing, not tested, and in haste):
chain classify-dscp {
meta l4proto . th dport vmap @rules_proto_dport
ip saddr 192.168.1.253 protocol { tcp, udp } dport { 80, 443} goto dscp_set_bulk
# IoT devices (uncomment to use)
# ether saddr $BULK_MACS goto dscp_set_bulk
}
i.e. it is applied after the initial purely port-based classification, as an override.
Probably that will give a syntax error, but perhaps @dave14305 can advise as to the most appropriate nftables form - he's the resident nftables expert.
Take a look here:
https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes#Ip
1 Like
Im more then happy to test anything. Will let you know in 5mins.
I would set the Xbox to $BULK_MACS but that would also cover the high end ports used for Gaming traffic and Steam for PC using 27000-27100 https://help.steampowered.com/en/faqs/view/2EA8-4D75-DA21-31EB
No need for name-calling. 
Minor adjustment, no idea if it actually does what’s intended but it passes the nft -c syntax check.
ip saddr 192.168.1.253 meta l4proto { tcp, udp } th dport { 80, 443 } goto dscp_set_bulk
1 Like
@Lynx
Error but good try
In file included from /dev/stdin:203:1-65:
/usr/share/nftables.d/ruleset-post/cake-qos-simple.nft:53:26-33: Error: No symbol type information
ip saddr 192.168.1.253 protocol { tcp, udp } dport { 80, 443} goto dscp_set_bulk
^^^^^^^^
The rendered ruleset contains errors, not doing firewall restart.
I added counter just see if it hits.
chain classify-dscp {
meta l4proto . th dport vmap @rules_proto_dport
ip saddr 192.168.1.253 meta l4proto { tcp, udp } th dport { 80, 443 } counter goto dscp_set_bulk comment "Xbox Downloads"
ip saddr 192.168.1.20/31 meta l4proto { udp } th dport { 4500 } counter goto dscp_set_voice comment "WiFi Calling"
# IoT devices (uncomment to use)
# ether saddr $BULK_MACS goto dscp_set_bulk
}
nft list ruleset
chain classify-dscp {
meta l4proto . th dport vmap @rules_proto_dport
ip saddr 192.168.1.253 meta l4proto { tcp, udp } th dport { 80, 443 } counter packets 5322 bytes 242519 goto dscp_set_bulk comment "Xbox Downloads"
ip saddr 192.168.1.20/31 udp dport 4500 counter packets 8 bytes 232 goto dscp_set_voice comment "WiFi Calling"
When devices such as Xbox and Google Pixel, Samsung galaxy series decide to use DSCP (for WiFi Calling, Large Downloads from Play Store,) then i will take the rules out but at the moment, They are set it CS0 by default, hints for the forced DSCP needed.
Again not need for Xbox Party Chat, i can confirm this uses the Voice tin if using a LAN cable but not sure on Wireless connection.
Edit: 2 hours later
Bulk Best Effort Video Voice
thresh 3750Kbit 60Mbit 30Mbit 15Mbit
target 5ms 5ms 5ms 5ms
interval 100ms 100ms 100ms 100ms
pk_delay 10.9ms 1.54ms 1.33ms 456us
av_delay 6.23ms 171us 107us 131us
sp_delay 2.32ms 23us 47us 33us
backlog 0b 0b 0b 0b
pkts 443869 4016573 306 127749
bytes 602863175 3962794180 72347 20409452
way_inds 178 38024 0 0
way_miss 1296 22310 257 110
way_cols 0 0 0 0
drops 103 9515 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 1 1 1 1
bk_flows 0 0 0 0
un_flows 0 0 0 0
max_len 1492 1492 1452 1452
quantum 300 1514 915 457
1 Like
Typically the default is CS0/BE, but I have no idea whether cake-qos-simple has other defaults. (My router is still on iptables/OpenWrt21, so even if I would I could not really test it...)
1 Like
Thx to moeller0 for the heads up about this thread. I work at Comcast and am working on AQM and low latency stuff (among other topics). As part of that work I've been mucking around with DSCP values and WMM to prep for dual queue networking. I noticed the post saying packets hit the WLAN marked CS1 and that might drop packets into AC_BK. I see the same marking on my WLAN, though upstream packets to my AP are marked CS0.
Anyway - issue noted & being discussed internally.
5 Likes
I configured and tested out something that can be useful (I think) - So basiclly any ports that are not listed will be class as bulk traffic. But ports above the line should get CS1 or whatever class you set them as.
Can you test on your Windows machine if any DSCP matches still with this? As im not sure if the last one will DROP the DSCP packets from e.g a Windows Client
chain classify-dscp {
meta l4proto . th dport vmap @rules_proto_dport
ip saddr 192.168.1.252/31 meta l4proto { tcp, udp } th dport { 444-65535 } counter goto dscp_set_besteffort comment "Xbox Gaming Ports"
ip saddr 192.168.1.20/31 meta l4proto { udp } th dport { 4500 } counter goto dscp_set_voice comment "WiFi Calling for Mobiles"
ip saddr 192.168.1.0/24 counter goto dscp_set_bulk comment "Everything eles gets Bulk CS1"
# IoT devices (uncomment to use)
# ether saddr $BULK_MACS goto dscp_set_bulk
}
Setting everything save for certain exceptions to bulk doesn't make sense to me. Instead just sparingly prioritise what needs to be prioritised. The situation, as I see it, is this. Your connection has a bandwidth limit. When there is more data to push through than available bandwidth, a sacrifice needs to be made. So long as the data you want to be prioritised has a higher priority (say voice), then cake will ensure that that data is not sacrificed. Setting everything other than what is voice to bulk won't achieve anything. If my explanation is incorrect or misleading here, I'm sure @moeller0 can help explain.
Understood.
you can verifiy in wireshark if dscp work
like this
95.179.222.141 192.168.2.160 UDP 74 CS0 30720 3074 30720 → 3074 Len=32 30720 → 3074 Len=32 0.017754000 230.164133000 3074
and now cs4
95.179.222.141 192.168.2.160 UDP 74 CS4 30720 3074 30720 → 3074 Len=32 30720 → 3074 Len=32 0.017754000 230.164133000 3074