in my opinion, on wifi, applying the right dscp marks and landing in the right wifi queue on the clients matters more than doing so on the AP. Has anyone got anywhere on that part?
OpenWrt snapshots allow to configure hostapd's qos_map_set feature which allows to define DSCP to AC mappings and that are distributed to the clients IIRC. But that still leaves the challenge of setting DSCPs on the clients.
Something where windows seems to be the easiest to configure, from my old notes:
# windows QoS: https://docs.microsoft.com/en-us/powershell/module/netqos/?view=win10-ps
Get-NetQosPolicy
# temporary -PolicyStore ActiveStore, otherwise omit -PolicyStore
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -ThrottleRateActionBitsPerSecond 1MB -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 47 -WhatIf
New-NetQosPolicy -Name "putty" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46
Get-NetQosPolicy -Store ActiveStore
Name : putty_ps
Owner : PowerShell / WMI
NetworkProfile : All
Precedence : 127
AppPathName : putty.exe
JobObject :
DSCPValue : 46
Remove-NetQosPolicy -Name "putty_ps" -PolicyStore ActiveStore
Seems to work, and I confirmed via tcpdump that putty's ssh packet originating from the windows VM host actually used DSCP 46 (aka EF). I note that powershell needs to be run as administrator, and the policies do not end up visible in Local Group Policy Editor. "-PolicyStore ActiveStore" will not survive a reboot, but for novice users that might be nice so a reboot cleans the slate in good windows tradition. I assume that after initial testing one could omit the "-PolicyStore ActiveStore" directive and store tested configs more permanently.
zoom, microsoft meet, etc would be an even better test.
what about wired, I now play games thanks to qosify and my rendering seems better with EF than with CS4, in diffserv4 yet CS4 is recommended for real-time gaming
in latency sensitive I see CS7 on the far left and CS4 on the far right
Does this have an impact on priority?
example CS7 much more priority then cs4 last
Sure there are better/more relevant test-cases than putty.exe, but the mechanism should be the same for any other application that is running from a single binary exe file. Not being a windows user myself, I have a somewhat hard time testing windows deeper
Your example works, this is how I set the policy to ensure my Parsec traffic in my WLAN is tagged as AF41 facilitating it landing in AC_VI queues.
For cake diffserv4 CS7 and CS4 are effectively the same, both steer a packet into the Voice priority tin, as can be seen on one of your lists. For WiFi WMM however the difference is that CS4 should map into AC_VI, the video access class while CS7 maps into AC_VO the voice access class (keep in mind please, that voice and video really are just names im WMM and diffserv4, nobody is forced to map actual voice traffic into AC_VO or cake's Voice tin).
The likelihood of getting the next airtime transmit slot in WiFi increases in the following AC order:
AC_BK, AC_BE, AC_VI, AC_VO
but AC_VO for example does not aggregate for longish periods and hence will not be as throughput efficient as the lower AC_VI, and AC_BE IIRC.
So sure, if you actually use time critical application over WiFi, DSCP marking them such that they map into AC_VO can reduce their latency and jitter, but at a considerable throughput cost of the whole WiFi channel. That can well be an acceptable trade-off, just keep that in mind...
As I keep repeating prioritization is mostly a zero sum game, for any packet treated better some other packet(s) need to be treated worse. If such packets exist, fine, but if not then prioritization is not going to help much.
Thanks a lot for the clarifications,
my environment is entirely dedicated to the video game network, the wifi is really not important, my mobile phone is in 4G and my console connected in ethernet cat5E for the moment,
test now with cs7
tc -s qdisc
Bulk Best Effort Video Voice
thresh 1Mbit 16Mbit 8Mbit 4Mbit
target 18.2ms 5ms 5ms 5ms
interval 113ms 100ms 100ms 100ms
pk_delay 3.1ms 137us 0us 2.15ms
av_delay 228us 10us 0us 109us
sp_delay 23us 3us 0us 4us
backlog 0b 0b 0b 0b
pkts 7595 514 0 480
bytes 772428 74336 0 106640
way_inds 0 0 0 0
way_miss 37 12 0 1
way_cols 0 0 0 0
drops 0 0 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 2 0 0 1
bk_flows 0 1 0 0
un_flows 0 0 0 0
max_len 3200 2726 0 1314
quantum 300 488 300 300
qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
Sent 13872968 bytes 10473 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 wlan0 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 1: dev ifb-wan root refcnt 2 bandwidth 56Mbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms ptm overhead 22
Sent 14021136 bytes 10416 pkt (dropped 57, overlimits 16618 requeues 0)
backlog 0b 0p requeues 0
memory used: 690489b of 4Mb
capacity estimate: 56Mbit
min/max network layer size: 46 / 1500
min/max overhead-adjusted size: 70 / 1546
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 3500Kbit 56Mbit 28Mbit 14Mbit
target 5.19ms 5ms 5ms 5ms
interval 100ms 100ms 100ms 100ms
pk_delay 5.45ms 77us 0us 39us
av_delay 3.69ms 9us 0us 6us
sp_delay 4us 4us 0us 4us
backlog 0b 0b 0b 0b
pkts 9746 361 0 366
bytes 13961982 66647 0 78805
way_inds 0 0 0 0
way_miss 37 16 0 1
way_cols 0 0 0 0
drops 57 0 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 1 1 0 1
bk_flows 0 0 0 0
un_flows 0 0 0 0
max_len 6056 3028 0 1330
quantum 300 1514 854 427
root@OpenWrt:~#
So, actually for a diffserv4 this would be the things that would match everything:
CAKE WMM
tin0 LE LE
tin1 CS0 CS0
tin2 AF41 AF41
tin3 CS7 CS7
While with diffserv8 you could not "sync" both CAKE and WMM.
Not really, by default LE, decimal 1 will map into AC_BE IIUC... CS1 would map into cake tin0 (bulk) and AC_BK.
But really, as far as I am concerned the WiFi WMM tiers are not gospel and should be used sparingly as all prioritization. If you have a small fraction of your traffic that is especially latency sensitive, by all means up prioritize it but try to keep prioritization to a minimum. The point is fq_codel's and cake's default mild boosting of sparse flows does away with quite a number of special rules that people used/recommended in the past. This is not always true, but please first try how far you get with no/minimal prioritization. The fewer special rules you have the fewer rules can annoy you with unexpected side-effects.
EDIT: recent OpenWrt will map LE to AC_BK just fine, I am just not sure whether that only means snapshots or whether OpenWrt 20 is doing this already as well.
Agree, seems like LE is only implemented on devices with kernel 5.9 or higher, so better to set CS1.
In a home environment you usually have a router and a AP, so it should be better if you can sync them.
i confirm than LE work on snapshot
config class bulk
option ingress LE
option egress LE
config class besteffort
option ingress CS0
option egress CS0
I just played with CS7 and the ports for the game and my game went really well, is it a placebo effect I can't say for the moment, but the tests seem good...
Im using pppoe with ipv6 enabled.
Do i need to setup anything else? or setting just interface 'wan' will work?
PPPOE dynamic create wan_6 interface when connected
It looks like, Qosify is crashing from time to time. Nothing in the logs but qosify status stops reporting any values and tc -s qdisc reporting changing... Iam using qosify on current stable.
Officially there is no qosify on the stable 21.02
So, if you have tried to implement it there, you are pretty much on your own.
Iam aware of that. And the only missing dep is a lib which is anyway compatible. I just wanna Point that out.
I do see some sort of âcrashâ with qosify on snapshot. And by âcrashâ I mean that ubus call qosify dump
returns an empty âentriesâ stanza, or sometimes it returns âCommand failed: Not foundâ. Also, the readable files under /sys/fs/bpf/qosify_data revert to zero values.
If I had to guess, itâs related to dns: entries in the conf files, therefore I assume itâs something with ubus between dnsmasq and qosify.
Restarting qosify brings the config back, but it seems after I visit a site that has dns: entries in my conf file, it can crash (or reset, whichever is a more fitting technical explanation).
My snapshot revision is r18615 on a RPi4B. I notice qosify hasnât been rebuilt by buildbot since December 22. Not sure if itâs relevant or not.
Can anyone corroborate my findings or suggest next steps? Pinging @nbd since he may not be watching the forums.
Thats exacly what i have under stable! Good Research.it feels like the project is dead
No, Felix just has his hands in many other OpenWrt targets and projects â as a hobby, no less.
good evening how do I know if there is a leak in qosify because my qosify is running very well but degrades over time I have the impression here are my settings based again on script elan ^^, I only use for livestreams on twitch and fps gaming
config defaults
list defaults /etc/qosify/*.conf
option dscp_prio video
option dscp_icmp +besteffort
option dscp_default_tcp besteffort
option dscp_default_udp besteffort
option prio_max_avg_pkt_len 500
config class bulk
option ingress CS1
option egress CS1
config class besteffort
option ingress CS0
option egress CS0
option dscp_prio video
option prio_max_avg_pkt_len 500
config class high_throughput_data
option ingress AF12
option egress AF12
option dscp_prio AF11
option prio_max_avg_pkt_len 1200
option dscp_bulk CS1
option bulk_trigger_pps 700
option bulk_trigger_timeout 60
config class network_services
option ingress CS2
option egress CS2
config class live_streaming
option ingress CS3
option egress CS3
config class video
option ingress AF41
option egress AF41
config class gaming
option ingress CS4
option egress CS4
config interface wan
option name wan
option disabled 0
option bandwidth_up 16mbit
option bandwidth_down 56mbit
option overhead_type bridged-ptm
# defaults:
option ingress 1
option egress 1
option mode diffserv4
option nat 1
option host_isolate 1
option autorate_ingress 0
option ingress_options ""
option egress_options "wash"
option options "ether-vlan"
and cofnig default now
# DNS
tcp:53 network_services
tcp:5353 network_services
udp:53 network_services
udp:5353 network_services
# NTP
udp:123 network_services
# SSH
tcp:22 network_services
# DNS over TLS (DoT)
tcp:853 video
udp:853 video
# HTTP (TCP)
tcp:80 +high_throughput_data
tcp:443 +high_throughput_data
# QUIC (UDP)
udp:80 +besteffort
udp:443 +besteffort
# BitTorrent (TCP)
tcp:6881-6889 bulk
tcp:6969 bulk
tcp:51413 bulk
# BitTorrent (UDP)
udp:6881-6889 bulk
udp:6969 bulk
udp:51413 bulk
# Usenet
tcp:119 bulk
tcp:563 bulk
# Bulk
dns:*.backblaze.com bulk
dns:*.backblazeb2.com bulk
dns:*.ms-acdc.office.com bulk
dns:*.windowsupdate.com bulk
dns:*.update.microsoft.com bulk
dns:*.onedrive.com bulk
dns:*.1drv.ms bulk
dns:*.1drv.com bulk
dns:*.sharepoint.com bulk
# Xbox (UDP)
udp:88 gaming
udp:500 gaming
udp:3544 gaming
udp:4500 gaming
# PlayStation (TCP)
tcp:1935 gaming
tcp:3074-3076 gaming
tcp:3478-3480 gaming
# PlayStation (UDP)
udp:3074-3079 gaming
udp:3478-3479 gaming
udp:3659 gaming
udp:30000-45000 gaming
# Zoom, Microsoft Teams and Skype - Them use the same ports.
udp:3478-3481 video
udp:8801-8810 video
# GoToMeeting
udp:1853 video
udp:8200 video
# Webex Meeting
tcp:5004 video
udp:9000 video
# Jitsi Meet
udp:10000 video
# Google Meet
udp:19302-19309 video
# FaceTime
udp:16384-16472 video
# TeamViewer
tcp:5938 video
udp:5938 video
# Live Streaming to YouTube Live, Twitch, Vimeo and LinkedIn Live.
tcp:1935-1936 live_streaming
tcp:2396 live_streaming
tcp:2935 live_streaming
would there also be a possibility to deactivate the down with a # or by putting 0 in mbits example -->
#option bandwidth_down 56mbit
option bandwidth_down 0mbit