thank you ... that was it ... the init boot wasn't up to date ! thx again
1 Like
Which can still fall down to low speeds, but more importantly, your Video/Voice tin markings can exercise AC_VI and AC_VO on the wifi side and that can be problematic (if your speedtest is stuck in AC_BE and there is competing traffic in either AC_VI or AC_VO these will get priority access to airtime, which can severely suppress "normal" AC_BE traffic).
Good, but since WiFi using the same channel to send and receive your own internal WiFi traffic might still suppress the speedtest/bufferbloat test traffic.
But, if you see the same for wired machines that is not the likely root cause (it might still be wifi related, if your router does not have enough CPU cycles for WiFi and cake, but I have no evidence to think that to be likely)
Maybe, maybe not. Cake is not really CPU throughput intensive, but it requires CPU with short delay when it does, any CPU meter needs to have sufficiently fine temporal resolution to show even short periods of high load. But as I said, I have no evidence that this is your problem.
Very good work @nbd
Qosify. Make my game so fluide
but normally qosify doesn't work after each reboot
i'm use this script now and he start
#!/bin/sh
[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] && {
echo y | /etc/init.d/qosify reload | start
logger -t qosify "Reloading qosify due to $ACTION of $INTERFACE ($DEVICE)"
}
Looking at your screenshot @Dopam-IT_1987
Do you know how i would give more thresh to say i wont;
Voice 14mbit to 1mbit and give Video the extra 13Mbit since VoIP only using 96kbps for Mumble (VoIP like Teamspeak) and WiFI Calling 4G uses the AMR-WB (HD-Voice) codec to 23.85kbps - 24kbps so 1Mbit would be plenty since is very low kbps.
# VoIP / WiFi Calling / 4G - Mobile DHCP 192.168.9.96-103
udp --src:192.168.9.103/29 --dport 4500 CS6
udp --src:192.168.9.103/29 --dport 5060 CS6
# Mumble
udp --src:192.168.9.10 --dport 64738 CS6
# Apple FaceTime iPads/iPhones - Mobile DHCP 192.168.9.96-103
udp --src:192.168.9.103/29 --dport 16384-16402 AF41
@nbd i have tagged you also just incase Dopam-IT_1987 don't know. If this is not a feature yet, Please add it to your to do list as Voice @ 14Mbits is way more then it needs, I know also the bandwidth is allocated based on the following "minimum to maximum" percentages of downlink and uplink values for each class
Maximum: 75% - 100% - Gaming Traffic (Xbox/PSN)
Premium: 50% - 100% - VoIP
Express: 25% - 100% - Streaming services like Netflix, D+
Standard: 15% - 100% - Heavy Downloads over 100Mb in file size
Bulk: 5% - 100% - Torrents P2P
1 Like
hi no i have no idea how to do it but for the moment i use like this
config defaults
list defaults /etc/qosify/*.conf
option dscp_prio CS5
option dscp_icmp +CS0
option dscp_bulk bulk
option dscp_default_udp CS4
option bulk_trigger_timeout 5
option bulk_trigger_pps 100
option prio_max_avg_pkt_len 500
config class bulk
option ingress LE
option egress LE
config class video
option ingress AF41
option egress AF41
config class voice
option ingress CS6
option egress CS6
option bulk_trigger_pps 100
option bulk_trigger_timeout 5
option dscp_bulk CS0
config interface wan
option name wan
option disabled 0
option bandwidth_up 16mbit
option bandwidth_down 56mbit
option overhead_type ethernet
# defaults:
option ingress 1
option egress 1
option mode diffserv4
option nat 1
option host_isolate 1
option autorate_ingress 1
option ingress_options ""
option egress_options ""
option options "overhead 44"
config device wandev
option disabled 1
option name wan
option bandwidth 100mbit
and my rules in firewall.user
if I understand correctly you would like to give more mb to the voice, that is not possible it seems to me
it will do according to base bandwidth you have
Cake has fixed ratios for each tier as I understand it.
1 Like
No. lower this to 1Mbit since yours is saying Voice is @ 14Mbits for Download and 4Mbits for upload, This is way more then enough for this class as the maxium for VoIP/Voice is 96 kbps even HD voice for WIFi calling on Mobile/Cell phone - So 1Mbit Up/Down should be say enough, Why not give the extra 13Mbits to Video class? so again leaving 1Mbit for Voice
1 Like
Cake doesn't reserve that bandwidth so that others can't use it, it just guarantees that bandwidth if voice needs it. If it never needs more than 1Mbps then other tiers will use the bandwidth. So I don't think it's a problem.
1 Like
Yeah that's a good point but would be nice to have a class that can be manually added in this case. 14Mbit is to much for a minimum class for VoIP/Voice why not give the extra 13Mbit either shared cross over classes or give it to Video?
Well, it's called "VOIP/Voice" but it's really just "high priority". You can do what you want with it. Maybe put a video stream for drone pilot through that tin or something.
1 Like
In the new classes with split ingress/egress, does this apply to defaults too? I'm trying to tinker with only overriding default tcp on ingress, but not seeing the desired results yet.
I'm trying to take incoming traffic which is generally CS1 (from Comcast) and only force it to CS0 on ingress. I still see traffic showing up in Bulk tin on ifb-eth1 (wan). Is this new feature implemented for dscp_default_tcp?
config defaults
option dscp_default_tcp in_be
config class in_be
option ingress CS0
option egress +CS0
in_be works if I assign it to tcp:443 in a conf file, but I want to cover all the ports, just to prove it works now.
I also see that /sys/fs/bpf/qosify_data/tcp_ports contains 144 assigned to each port. Not sure what 144 maps to yet, if that helps.
BTW competing traffic should not affect (good) bufferbloat. That is kind of definition of it.
Anyway for some time result were unstable even straight after router reboot. now I am on 2021-11-21-2743e587 and it looks more stable.
I was talking about WiFi here, slightly different issue. The higher ACs AC_VO and AC_VI get considerably more throughput and that can lead to Best Effort speedtest traffic seeing its true bottleneck on your WiFi link, and in that case cake/qosify on the WAN interface is not going to fix potential over-buffering in the WiFi station/AP (not all WiFi chipsets in OpenWrt offer 802.11 fq_codel and airtime fairness). But again, I have no evidence at all that this is the case for you, so speaking purely theoretically here.
I would naively assume that this must be a decimal 8bit TOS value, and to get from decimal 8bit TOS to decimal 6bit DSCP one needs to simply divide by 4 (shifting by two bits to evade the ECN bitmap).
So decimal TOS 144 = 144/4 = 36 decimal DSCP
Which according to Cisco means AF42 (in the CS4 range) and maps into diffserv4's second highest "Video" priority tin (and into diffserv3's best effort tin).
Side-note: diffserv4's tin names are inspired by WiFi WMM's access class names.
EDIT: This truly was naive, and wrong, see below....
The values in the maps are not raw DSCP values. They are set based on these masks:
#define QOSIFY_DSCP_VALUE_MASK ((1 << 6) - 1)
#define QOSIFY_DSCP_FALLBACK_FLAG (1 << 6)
#define QOSIFY_DSCP_CLASS_FLAG (1 << 7)
If QOSIFY_DSCP_CLASS_FLAG is set, bits 0-5 refer to a configured class (stored in a separate map).
Otherwise, they contain the DSCP value (not shifted).
Up to 16 classes can be configured normally (index 0-15), values 16 and 17 are reserved for default tcp/udp settings configured in the defaults section.
1 Like
with the last snapshot now it works, thanks 1000
Ok so that info leads me to this entry in class_map:
16: {{40,130,5,100,500,},{0,64,},0,}
which I’m pretty sure the 64 tells me it’s the egress +CS0 entry with the fallback bit set?
But wan ingress traffic still hits the bulk tin in cake.
I just pushed a commit to qosify.git that fixes referencing a class directly from the default entries.
1 Like