Hello, the xbox have a setting to DSCP tags read this link
Any cons or pros !!!
Great find!
Pros:
Your outbound game traffic will be prioritized by OpenWrt's default WiFi WMM settings (this is true for both toggles if enabled, EF maps to AC_VO anyways). The same is true for cake's diffserv3/4/8 modes they will treat EF marked packets to a higher priority.
Cons:
Over WiFi using AC_VO will result in a lower aggregate WiFi throughput, so concurrent bandwidth heavy use cases will suffer a bit/take a bit longer, but this might be accaptable.
If you do not use cake's wash keyword in the upload direction, you will (using the second option) send EF marked packets to your ISP; this rarely gains you a higher priority service at least not without negotiating better service with your ISP first, however there are reports of EF marked packets also seeing either higher delay or higher drop rates than DF/CS0 marked packets or both. But that should be easy to test.
1 Like
Hello, i use the @elan qosify example and i change ports in etc/qosify/00-defaults.confi.
And now the command "ubus call qosify dump dont work.
What i have to edit ?
The speeds i have to put in the qosify script are the full download / upload or i have so set 85-90 %
Any affect if set the dscp tag on xbox and use the qosify script?
Not owning a xbox nor using qosify the best I can do is speculate....
I would expect that these two methods will not interfere as long as your qosify rules for egresss are not configured to override non-zero dscps.
1 Like
@EXREYFOX
I have tested Qosify with an Xbox Series X using the DSCP tag however the Xbox overrides Qosify for voice chat/party to EF HB.
I have tried Crossout online but i can see this set bulk traffic by default (with qosify off) so really is up to the developer to tell Xbox OS that this game IP:Port is for Gaming, Something like CS0/CS1 for best effort.
Hi, I'm new to QoSify
Whats the difference between having multiple CS3 classifications?
@Kimcha has "video_broadcast", "video_network_sparse" and "video_network" are all CS3
Is there a difference between them?
Diffserv4 provides 4 tins, but is there a difference for any of the classifications within the same tin?
eg: CS3, CS4 and AF42 are all in the Video tin
Does one have higher priority over the other? or are they essentially the same priority?
thanks for info in advance
Inside each priority tin, cake will still do its "normal" mild boosting of flows that are sparse, but all DSCPs that map to the same tier will give the same priority all else being identical.
I would guess that having a finer classification mapping to fewer actual priority tins allows to fine-tune the QoS settings to adapt them to local preferences.
Personally I still believe the biggest trick in up-prioritisation is to use it as sparingly as necessary... for every packet that is treated better (lower queueing delay) other packet(s) need to be treated worse, so prioritization requires some "victim" traffic that can be delayed. This works pretty well when (under congestion) the bulk of packets are normal/low priority and only a few are of high(er) priority.
Keep in mind that cake does not actually hard limit the higher priority tiers, but once a high priority tier exceeds its guaranteed capacity it will be scheduled at equal priority to the lower priority tiers...
3 Likes
Hi, I am new to Qosify. I was trying to compile it for my router firmware but ran into lots of issues. I tried some of the suggestions in this thread using CONFIG_USE_LLVM_PREBUILT tool chain without success. I have also tried CONFIG_BPF_TOOLCHAIN_HOST and verified my LLVM has support for bpf and the required version.
% llc --version| grep bpf
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
% clang --version
Debian clang version 13.0.1-6~deb11u1
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /
I know it is possible to build the package since people here are using it, I just not sure if I am missing something or the platform I try to build it for is not supported. Anyone have any suggestions/instructions on how I can build Qosify myself?
See if this helps:
1 Like
Just install from upstream:
# CONFIG_BPF_TOOLCHAIN_BUILD_LLVM is not set
CONFIG_BPF_TOOLCHAIN_HOST_PATH="/usr/lib/llvm-16"
# CONFIG_HAS_PREBUILT_LLVM_TOOLCHAIN is not set
CONFIG_USE_LLVM_HOST=y
@dave14305 I tried that and I couldn't get it to compile. The llvm-bpf-13.0.0.tar.xz needs a x86_64/amd64 build system to run. I am running arm64 platform as my build system in a docker container on a M1. @anomeome I have the 2 config option defined, except I am ruing llvm-13 instead. I don't have issues building images for my R7800 and R4S router. I am trying to replace SQM with Qosify but having challenges trying to build it. The first error I ran into was with bpf-headers
grep CONFIG_HZ /home/openwrt/openwrt/build_dir/target-aarch64_generic_musl/linux-rockchip_armv8/linux-5.10.179/.config >> /home/openwrt/openwrt/build_dir/targ
et-aarch64_generic_musl/linux-rockchip_armv8/bpf-headers/linux-5.10.179/.config
grep: /home/openwrt/openwrt/build_dir/target-aarch64_generic_musl/linux-rockchip_armv8/linux-5.10.179/.config: No such file or directory
make[2]: *** [Makefile:122: /home/openwrt/openwrt/build_dir/target-aarch64_generic_musl/linux-rockchip_armv8/bpf-headers/linux-5.10.179/.configured_68b329da98
93e34099c7d8ad5cb9c940] Error 2
make[2]: Leaving directory '/home/openwrt/openwrt/package/kernel/bpf-headers'
time: package/kernel/bpf-headers/compile#8.00#6.19#9.07
ERROR: package/kernel/bpf-headers failed to build.
make[1]: *** [package/Makefile:120: package/kernel/bpf-headers/compile] Error 1
make[1]: Leaving directory '/home/openwrt/openwrt'
make: *** [/home/openwrt/openwrt/include/toplevel.mk:230: package/kernel/bpf-headers/compile] Error 2
I hacked the Makefile by doing
--- a/package/kernel/bpf-headers/Makefile
+++ b/package/kernel/bpf-headers/Makefile
@@ -76,10 +76,9 @@ define Build/Configure
grep -vE 'CONFIG_(CPU_.*ENDIAN|HZ)' $(PKG_BUILD_DIR)/arch/mips/configs/generic_defconfig > $(PKG_BUILD_DIR)/.config
echo 'CONFIG_CPU_$(if $(CONFIG_BIG_ENDIAN),BIG,LITTLE)_ENDIAN=y' >> $(PKG_BUILD_DIR)/.config
$(if $(CONFIG_ARCH_64BIT),$(Build/Configure/64))
- grep CONFIG_HZ $(REAL_LINUX_DIR)/.config >> $(PKG_BUILD_DIR)/.config
+ echo 'CONFIG_HZ=100' >> $(PKG_BUILD_DIR)/.config
yes '' | $(KERNEL_MAKE) oldconfig
- grep 'CONFIG_HZ=' $(REAL_LINUX_DIR)/.config | \
- cut -d= -f2 | \
+ echo '100' | \
bc -q $(LINUX_DIR)/kernel/time/timeconst.bc \
> $(LINUX_DIR)/include/generated/timeconst.h
$(BPF_DOC) --header \
and get this error shortly after...
/usr/lib/llvm-13/bin/clang --target=mips64el-linux --prefix=mips64el-linux- --gcc-toolchain=/ -fno-integrated-as -Werror=unknown-warning-option: unknown assembler invoked
scripts/Kconfig.include:47: Sorry, this assembler is not supported.
make[4]: *** [scripts/kconfig/Makefile:71: oldconfig] Error 1
make[3]: *** [Makefile:615: oldconfig] Error 2
make[3]: Leaving directory '/home/openwrt/openwrt/build_dir/target-aarch64_generic_musl/linux-rockchip_armv8/bpf-headers/linux-5.10.179'
make[2]: *** [Makefile:120: /home/openwrt/openwrt/build_dir/target-aarch64_generic_musl/linux-rockchip_armv8/bpf-headers/linux-5.10.179/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 2
make[2]: Leaving directory '/home/openwrt/openwrt/package/kernel/bpf-headers'
time: package/kernel/bpf-headers/compile#8.44#8.34#11.46
ERROR: package/kernel/bpf-headers failed to build.
make[1]: *** [package/Makefile:120: package/kernel/bpf-headers/compile] Error 1
make[1]: Leaving directory '/home/openwrt/openwrt'
make: *** [/home/openwrt/openwrt/include/toplevel.mk:230: package/kernel/bpf-headers/compile] Error 2
I am not a developer, I can read the error log and try hacking/trying stuff I found online. I am happy to try/test any suggestions to get Qosify to build on arm64 platform if it's not supported.
I am actually running into this same error with 22.03 while compiling from ipq806x/R7800.
(I even tried copying newer llvm toolchain from master, but it did not help.)
/Openwrt/r7800-2203/llvm-bpf/bin/clang --target=mipsel-linux --prefix=mipsel-linux- --gcc-toolchain=/ -fno-integrated-as -Werror=unknown-warning-option: unknown assembler invoked
scripts/Kconfig.include:47: Sorry, this assembler is not supported.
make[5]: *** [scripts/kconfig/Makefile:71: oldconfig] Error 1
make[4]: *** [Makefile:615: oldconfig] Error 2
make[4]: Leaving directory '/Openwrt/r7800-2203/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/bpf-headers/linux-5.10.179'
make[3]: *** [Makefile:122: /Openwrt/r7800-2203/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/bpf-headers/linux-5.10.179/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 2
make[3]: Leaving directory '/Openwrt/r7800-2203/package/kernel/bpf-headers'
time: package/kernel/bpf-headers/compile#0.71#0.27#1.25
ERROR: package/kernel/bpf-headers failed to build.
Compilation host Ubuntu 23.04 in Virtualbox (Windows 11 x86_64) .
Strange, as the same buildhost compiled 22.03 ok four week ago.
Master and 23.05 still compile ok, so this is something recent and only affecting 22.03
(Even stranger, as I do not spot any relevant commits in 22.03 in May. Except possibly those two fortify-headers time commits???)
As I noticed that also the 22.03 buildbot fails to compile bpf-headers, I filed a bug about this:
Looks like changes in the stable Linux kernel at 5.10.178 cause the build breakage in 22.03. Some changes were backported upstream to 5.10 in May, and the changes break bpf-headers compilation.
Likely cause is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=83f55e6f298e9e79a38b92d771179090ff0ac771
Curious part is that the original upstream commit has been in Linux since 2021 and is also in 5.15 which still seems to compile bpf-headers ok. There is apparently some other change in 5.15 that would fix the compilation.
EDIT:
Possible fix in
2 Likes
First of all, thank you to everyone posting in this thread. I previously had SQM set up and found it unsufficient to really handle my traffic. While it worked a million times better than anything before, I'd still have spikes in games.
Everything works a lot better being able to actually configure cake more precisely. However, I still have one pain point I can't quite seem to solve.
I run a homeserver with Jellyfin that's externally available, so sometimes is used for upload. This generally works well enough. The problem appears when my bittorrent clients are drawing a lot of bandwidth. I want them to be considered bulk.
However, they are all running through a container using OpenVPN, meaning, as far as I understand, all packets are just considered OpenVPN and not bittorrent. Port filtering will therefore do nothing, unless I crack down on all OpenVPN traffic and port 443 (obviously not good).
Is there any way around this?
I thought maybe giving said container its own IP so I can filter by IP?
I can't/don't want to mess with that container too much, but maybe using iptables I could modify the packages before sending them out? I'm not sure that would even work.
I use port forwarding with OpenVPN, so incoming packets to my torrent client should be a specific port. Since they get sent via OpenVPN though, I'm not sure that gets lost and I'm not sure how to confirm/disprove this.
Maybe someone with a similar setup can speak to what they are doing. If I can reliably classify bittorrent traffic, that's the last thing needed for a stable setup.
You could use a firewall4 rule to mark the traffic LE or CS1 before it reaches qosify, or play around with the qosify bulk_trigger* settings. Qosify won’t recognize internal IPs in the rules, only remote/external IPs.
This would allow you to use cake's per internal IP fairness configuratipn, so bittorrent would not hog all bandwidth unless bittorrent would be the only active application...
Or you woild need to have the router handle the VPN de/encryption and do some creative policy based routing to have cake work on the traffic before/after thw VPN. @Lynx has a project doing that for wireguard that might serve as reference....
Qosify seems popular but it's not as flexible as simply using nftables to classify the traffic and doesn't support fancy stuff like restoring DSCPs from conntrack on download based on what was set on upload by LAN clients or by the router.
I personally therefore favour the approach I put together in cake-qos-simple.
It strikes me that there are various ways you could proceed. Where is your VPN endpoint? Is it within your LAN? Could your LAN clients perhaps simply set the DSCPs on upload? Or if your VPN endpoint is OpenWrt then you could have OpenWrt set the DSCPs.
2 Likes
That's what I was thinking. Am I correct to assume the easiest way would be by assigning the VPN container its own IP still?
I'd like to avoid that. There's also not that much compute overhead for my router. My 250/40 VDSL2 connection is pretty much as much as my E8450 can handle with CAKE. Introducing encryption isn't an option.
It's in my LAN. Currently a container running Gluetun on its own Docker network. So to the router it currently looks like it's just traffic coming from my home server. I can bridge the container and give it its own IP in the LAN though. I think setting DSCPs on upload in the container itself OR on the router for all traffic coming through the container's internal IP seems to be the best course of action.
This should work with qosify, as it just marks the traffic before it reaches qosify's qualification, correct?
Presumably for upload only in that cake will just act on the DSCP markings? I'm not familiar with qosify.
The beauty of storing DSCPs to conntrack on upload and restoring from conntrack on download is that the DSCPs will end up getting consistently set in both directions (upload and download) for connections. That's why I strongly favour that approach.
To elaborate, LAN client marks packet on upload. Router stores DSCP to conntrack (connection track). Then corresponding download packets associated with that tracked connection will get marked with the DSCP that was stored in the conntrack. That way cake sees the correct DSCPs in both directions.