No idea, maybe post the complete config files? And are you sure that all rules from @dlakelan's shaper set-up are deactivated/deleted?
1 Like
ok i post my all configuration
there is no script and sqm is disabled
this is the /etc/config/qosify
config defaults
list defaults /etc/qosify/*.conf
option dscp_prio CS5
option dscp_icmp CS6
option dscp_bulk CS1
option dscp_default_udp CS4
option bulk_trigger_timeout 5
option bulk_trigger_pps 100
option prio_max_avg_pkt_len 500
config alias bulk
option ingress CS1
option egress CS1
config alias video
option ingress AF41
option egress AF41
config alias voice
option ingress CS6
option egress CS6
config interface wan
option name wan
option disabled 0
option bandwidth_up 4mbit
option bandwidth_down 56mbit
# 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 now this is /etc/qosify/00-defaut.conf
# DNS
tcp:53 CS0
tcp:5353 CS0
udp:53 CS0
udp:5353 CS0
# NTP
udp:123 CS0
# SSH
tcp:22 CS0
# HTTP/QUIC
tcp:80 CS0
tcp:443 CS0
udp:80 CS0
udp:443 CS0
#cod
udp:3074 CS6
#BF2042
udp:3659 CS6
nbd
123
You can use those aliases in the *.conf files and for the default values. That way it's easy to change the tags (and even make them different for ingress vs egress) without having to update the files.
Eventually, I'd like to have a good set of alias names with preconfigured tags in the default config, and all default rules should refer to those aliases instead of raw DSCP values.
1 Like
ah ok if i understand
i has possibility to make like this
config alias bulk
option ingress CS1
option egress CS1
config alias video
option ingress AF41
option egress AF41
config alias voice
option ingress CS6
option egress CS6

so what is the difference between
option dscp_prio CS5
option dscp_icmp CS6
option dscp_bulk CS1
option dscp_default_udp CS4
and other alias ??
sorry if i don't understand ...
edit if i modified
option dscp_prio CS6
at this time i has CS6

is very complexe to understand i found 
nbd
125
The dscp_* options in the defaults section are for dynamic detection of bulk/priority flows.
The aliases simply define something you can use in .conf files and the defaults dscp_* options instead of the raw DSCP classes
2 Likes
phew it finally works by updating the sqm snapshot it was reset by default so here is my final config
i come back tomorow for your explain if my game is fluide or not 

thanks for all
config defaults
list defaults /etc/qosify/*.conf
option dscp_prio CS5
option dscp_icmp CS6
option dscp_bulk CS1
option dscp_default_udp CS4
option bulk_trigger_timeout 5
option bulk_trigger_pps 100
option prio_max_avg_pkt_len 500
config alias bulk
option ingress CS1
option egress CS1
config alias video
option ingress AF41
option egress AF41
config alias voice
option ingress CS6
option egress CS6
config interface wan
option name wan
option disabled 0
option bandwidth_up 4mbit
option bandwidth_down 56mbit
# 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
# DNS
#tcp:53 CS5
#tcp:5353 CS5
#udp:53 CS5
#udp:5353 CS5
# NTP
#udp:123 CS6
# SSH
#tcp:22 +CS4
# HTTP/QUIC
#tcp:80 +CS3
#tcp:443 +CS3
#udp:80 +CS3
#udp:443 +CS3
#cod
udp:3074 +CS6
#BF2042
udp:3659 +CS6
root@OpenWrt:~# tc -s qdisc
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 1518 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 6570760556 bytes 9967563 pkt (dropped 0, overlimits 0 requeues 3)
backlog 0b 0p requeues 3
maxpacket 13662 drop_overlimit 0 new_flow_count 392 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev lan1 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan2 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan3 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc noqueue 0: dev lan4 root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 1: dev wan root refcnt 2 bandwidth 4Mbit diffserv4 dual-srchost nat nowash no-ack-filter split-gso rtt 100ms noatm overhead 44
Sent 23419346 bytes 122351 pkt (dropped 446, overlimits 164999 requeues 0)
backlog 0b 0p requeues 0
memory used: 2387072b of 4Mb
capacity estimate: 4Mbit
min/max network layer size: 28 / 1500
min/max overhead-adjusted size: 72 / 1544
average network hdr offset: 14
Bulk Best Effort Video Voice
thresh 250Kbit 4Mbit 2Mbit 1Mbit
target 72.7ms 5ms 9.08ms 18.2ms
interval 168ms 100ms 104ms 113ms
pk_delay 10.7ms 7.13ms 0us 2.18ms
av_delay 4.92ms 2.59ms 0us 252us
sp_delay 3.6ms 58us 0us 11us
backlog 0b 0b 0b 0b
pkts 71226 6934 0 44637
bytes 8526167 9224275 0 6200400
way_inds 0 21 0 2
way_miss 45 97 0 996
way_cols 0 0 0 0
drops 183 263 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 0 0 2
bk_flows 0 0 0 1
un_flows 0 0 0 0
max_len 7570 16654 0 1758
quantum 300 300 300 300
qdisc ingress ffff: dev wan parent ffff:fff1 ----------------
Sent 118081601 bytes 112018 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 cake 1: dev ifb-wan root refcnt 2 bandwidth 56Mbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 44
Sent 119975429 bytes 111989 pkt (dropped 29, overlimits 129586 requeues 0)
backlog 0b 0p requeues 0
memory used: 354688b of 4Mb
capacity estimate: 56Mbit
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 3500Kbit 56Mbit 28Mbit 14Mbit
target 5.19ms 5ms 5ms 5ms
interval 100ms 100ms 100ms 100ms
pk_delay 3.51ms 4.81ms 0us 116us
av_delay 3.07ms 1.18ms 0us 24us
sp_delay 273us 31us 0us 5us
backlog 0b 0b 0b 0b
pkts 75698 4539 0 31781
bytes 102550206 5753365 0 11711546
way_inds 0 0 0 9
way_miss 68 150 0 777
way_cols 0 0 0 0
drops 25 4 0 0
marks 0 0 0 0
ack_drop 0 0 0 0
sp_flows 0 0 0 4
bk_flows 0 0 0 0
un_flows 0 0 0 0
max_len 6056 6056 0 1514
quantum 300 1514 854 427
root@OpenWrt:~#
good evening everybody
dtaht
127
I said applications, not users, and "except for abuse".
OF COURSE the bofh knows best:
1 Like
dtaht
128
As a note, stadia traffic comes in as AF21 over my cell connection. I no longer know what bits that maps to.
Actually you can configure it.
Just add the overhead keyword like this:
option options "overhead 34"
I know, but overhead accounting is an integral part in competent traffic shaping and hence deserves a properly named specific option/keyword. It is hard enough to make people care for this (evidenced by the number of times people recommend to not configure ovehead for sqm in this forum*).
*) Which indicates that the wiki pages are not reader-friendly enough.
1 Like
Question: Do you actually see these CS7 marked packets on your ingress? That is does CS7 survive the passage from USC via AT&T? to your router?
nbd
132
How about this:
option overhead <type>
Where type can be one of: none, manual, conservative, pppoe-ptm, ...
If it is set to manual, you can also add:
option overhead_mode atm|ptm|noatm
option overhead_bytes <val>
option overhead_mpu <val>
Also, what would you suggest as a default value?
3 Likes
Nice work, i think having the option to specify an ip and port together would be appreciate. Some times i only want one device to get prioritized and only from/to a specific port, but i know that this type of cases are not tipical.
1 Like
Thanks a lot! This qosify thing is shaping up quite excellently!
Mmmh, first off let me admit I am no big fan of cake's overhead/link layer keywords, but I also accept that most other people will likely prefer "short and concise" over "too much detail".
If I understand correctly you want to allow to use the cake keywords here directly, as well as two new additional ones "none" and "manual"? That should work, just make "overhead" a synonym for "manual" as "overhead 44" is already valid cake configuration.
A default number that should work reasonably for most is 44 Bytes (-> overhead 44) most relevant encapsulations actually stay below that value (e.g. ethernet has effective overhead of 38 bytes, if you add a single VLAN tag you are at 42 bytes; the common ADSL encapsulation in Germany has 44 bytes; GPON/LTE/5G/VDSL2/DOCSIS all sit well below 44 Bytes, but for buffer debloating purposes too high an overhead is not an issue (it will sacrifice slightly more throughput than strictly necessary, but it will make the shaper not any worse)).
How about calling that "link-layer" instead of "mode"? Too confusing, then mode is also fine? Default should be "noatm", given that ATM/AAL5 is legacy technology that sooner or later is going to be replaced with something better (alas, probably much later than one would like). And ATM carries a ~9% throughput cost (48 bytes payload per 53 ATM-cell)) so defaulting to the worst-case ATM seems not advised. Also the method behind the "ptm" keyword while concise is less precise than simply never taking raw sync rates as shaper rates but at least derate them by 64/65 (100-100*64/65 = 1.54 %)... saving one division per packet 
Yes, as above "overhead_bytes 44" sounds okay, and "overhead_mpu 88" (which applies to true ethernet). sqm itself started when ADSL was more prominent, and ADSL allows encapsulations without ethernet FCS and hence shorter frames than 88 bytes (including overhead) and on ADSL link every byte counts, so sqm defaulted to mpu 0, but I think "mpu 88" is a saner default nowadays (and into the future). If I would set sqm defaults today, I would just go with "mpu 88" as the cost of getting this too high are less problematic than getting this too low.
For all of these, overestimating these parameters (slightly) has only a mild throughput cost, but underestimating them slightly can have a noticeable latency-under-load-increase. As an anecdote, back when I was still on a 16/2.5 AnnexJ ADSL link, I noticed that my ISP had added a VLAN tag on the DSL link from bufferbloat measurements, accounting for these added 4 bytes removed that additional bufferbloat again. For ATM/AAL5 links we have a heuristic that actually allows to get really good estimates for the per-packet overhead and these confirmed the change by 4 bytes. In either case I did not notice the change in throughput between the correct or too small an overhead specification (Which will only really show with saturating loads with small packets anyway, which are rare during throughput measurements).
1 Like
nbd
135
The reason why I put none and manual in the list of supported values for the overhead option is to make it easier to have consistent validation for a UI.
I guess it could cause some confusion to reuse the name that is already used for the cake manual overhead value.
How about this instead:
option overhead_type none|manual|pppoe-ptm|...
option overhead_vlan 1 # range: 0..2
# for manual:
option overhead 44
option overhead_mpu 0
option overhead_encap atm|ptm|noatm
I think with that, most people won't need to set overhead_type to manual.
2 Likes
Fair enough, ;).
True, on the other hand it would be confusing if a single of cake's overhead related keywords was not operable, no? But this is nit-picking, you have way more experience with successful UI/UX design than I so, I am confident you will make a good choice one way or the other.
True, but I bet that figuring out whether Q-in-Q double VLAN tags are required will also be quite a challenge ;). As will for normal users figuring out which of cake's 13 overhead keywords is applicable to them. Maybe we can comment them a bit, e.g. "docsis (use for cable internet)" , " pppoe-llcsnap (best guess for ADSL", and the like?
Anyway, this is already looking quite good and I would not complain if your proposal would be the final design.
nbd
137
Thanks for the review!
Maybe overhead_type should just default to conservative and all the options and their meanings should be documented in a separate wiki page describing the entire config syntax.
If the overhead option is not present in the default config (but clearly explained in the wiki) then I guess it shouldn't be confusing to users that add it.
I can also change the init script in a way that the result of parsing the overhead* options is placed before any user defined options. That way users that want to specify the overhead explicitly in raw tc-cake syntax via options can still do so, regardless of what's set in overhead_type
3 Likes
conservative is equivalent to "overhead 48 atm" and hence will carry an additional 10% throughput cost. And this still misses a sensible mpu....
Yes, that is also how we implemented the "dangerous option field" in the sqm GUI, it is added last to the generated tc all and hence overrides earlier definitions. Since this was introduced we actually added error reporting for tc calls (visible in log read), this started as a quick way to test cake while it was still growing keywords (and after cake had settled down I never could convince myself to come up with a GUI to set/select each one of them, partly because sqm is not cake-exclusive and so these would introduce loads of duplicate functionality, this is also why the 13 overhead keywords never made it into the GUI).
1 Like
Hello please add the priority option by device for example if possible
high priority: game console making (an idea)
iphigh: 192.168.2.140
medium priority: tv etc
ipmedium:
then a second suggestion the possibility of being able to integrate by dscp for example no matter what I put in the .conf file
my console's dscp is still CS5
impossible to modify
iphighudp: 3074 + CS6
a chance may be in the future to see integrated a luci-app-qosify?
thank you for your work
install clang-12 in your distro, it should appear again (for build system).
Edit: @nbd, this wiki https://openwrt.org/docs/guide-developer/toolchain/install-buildsystem may be updated to insert clang (minimal version: 12) in prerequisites for compile qosify package:
Ubuntu LTS/Debian 10: apt install clang-12
Arch Linux: pacman -S clang
`
1 Like