yes it looks very simple. strange... what if you run tcpdump -i eth1 -v -n 'host 8.8.8.8' to verify:
a) if you really send traffic via eth1 (you don't use VPN, right? so it is unlikely but to be sure)
b) what is the actual TOS
and if you opkg install procps-ng-watch could run watch -n 0.5 -d -x qosify-status' to see what tin is used while you dig @8.8.8.8 ?
root@OpenWrt:~# tcpdump -i wan -v -n 'host 8.8.8.8'
tcpdump: listening on wan, link-type EN10MB (Ethernet), capture size 262144 bytes
20:39:47.261926 IP (tos 0x0, ttl 63, id 24688, offset 0, flags [none], proto UDP (17), length 67)
.62988 > 8.8.8.8.53: 8593+ [1au] ANY? amazon.com. (39)
20:39:47.276033 IP (tos 0x0, ttl 63, id 34970, offset 0, flags [none], proto ICMP (1), length 84)
> 8.8.8.8: ICMP echo request, id 62082, seq 0, length 64
20:39:47.280928 IP (tos 0x0, ttl 121, id 20758, offset 0, flags [none], proto UDP (17), length 88)
8.8.8.8.53 > .62988: 8593 1/0/1 amazon.com. HINFO (60)
20:39:47.287555 IP (tos 0x0, ttl 115, id 0, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > : ICMP echo reply, id 62082, seq 0, length 64
maybe can help
call of duty has been broken for a few weeks I didn't have this problem before, I don't know why as soon as they update the netcode of the game must modify something
I also see that call of duty has three types of packets in wireshark, what do they correspond to? 212 166 and 174
this would mean that the game only sends these packets on a regular basis depending on the result
example of qos in gargoyle max packet 128 packets
Download Direction:
Enabled with one rule for packets less than 128 bytes to the 'Fast' class.
Default to the "Default' class
Fast Class 50%, Min 0, No Max, No Min RTT
Default Class 50%, Min 0, No Max, No Min RTT
ACC enabled with default settings.
Upload Direction:
Enabled with one rule for packets less than 128 bytes to the 'Fast' class.
Default to the "Default' class
Fast Class 90%, Min 0, No Max
Default Class 10%, Min 0, No Max
I'm just trying to figure out the ideal of packet transmission for gaming and since I'm a bit too stubborn I've been leaning on it for too long 
Quick note, on my pppoe link your test fails for
tcpdump -i eth2 -vv -n 'host 8.8.8.8'
tcpdump -i eth2.7 -vv -n 'host 8.8.8.8'
but works for:
root@turris:/srv/persistent/captures# tcpdump -i pppoe-wan -vv -n 'host 8.8.8.8'
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
22:52:34.288526 IP (tos 0x0, ttl 63, id 15049, offset 0, flags [DF], proto ICMP (1), length 84)
95.116.30.84 > 8.8.8.8: ICMP echo request, id 3, seq 1, length 64
22:52:34.297888 IP (tos 0x0, ttl 60, id 0, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 95.116.30.84: ICMP echo reply, id 3, seq 1, length 64
22:52:35.700033 IP (tos 0x0, ttl 63, id 28249, offset 0, flags [none], proto UDP (17), length 94)
95.116.30.84.42557 > 8.8.8.8.53: [udp sum ok] 7229+ [1au] A? www.elhorrindeclaudia.com. ar: . OPT UDPsize=4096 (66)
22:52:35.714657 IP (tos 0x0, ttl 60, id 35443, offset 0, flags [none], proto UDP (17), length 130)
8.8.8.8.53 > 95.116.30.84.42557: [udp sum ok] 7229$ q: A? www.elhorrindeclaudia.com. 3/0/1 www.elhorrindeclaudia.com. A 104.26.4.54, www.elhorrindeclaudia.com. A 104.26.5.54, www.elhorrindeclaudia.com. A 172.67.71.33 ar: . OPT UDPsize=512 (102)
22:52:36.506891 IP (tos 0x0, ttl 127, id 22564, offset 0, flags [DF], proto ICMP (1), length 84)
95.116.30.84 > 8.8.8.8: ICMP echo request, id 13701, seq 15021, length 64
22:52:36.516516 IP (tos 0x0, ttl 60, id 0, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 95.116.30.84: ICMP echo reply, id 13701, seq 15021, length 64
22:52:46.506728 IP (tos 0x0, ttl 127, id 22776, offset 0, flags [DF], proto ICMP (1), length 84)
95.116.30.84 > 8.8.8.8: ICMP echo request, id 13701, seq 15022, length 64
22:52:46.516281 IP (tos 0x0, ttl 60, id 0, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 95.116.30.84: ICMP echo reply, id 13701, seq 15022, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
so it seems the tcpdump filters are not prepared to drill though arbitrary encapsulations.
Here you go after executing dig @8.8.8.8 www.elhorrindeclaudia.com:
; <<>> DiG 9.18.1 <<>> @8.8.8.8 www.elhorrindeclaudia.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38366
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.elhorrindeclaudia.com. IN A
;; ANSWER SECTION:
www.elhorrindeclaudia.com. 300 IN A 172.67.71.33
www.elhorrindeclaudia.com. 300 IN A 104.26.4.54
www.elhorrindeclaudia.com. 300 IN A 104.26.5.54
;; Query time: 109 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed May 04 07:11:10 AEST 2022
;; MSG SIZE rcvd: 102
And results from tcpdump -i eth1 -v -n 'host 8.8.8.8' obtained in parallel:
07:11:10.515128 IP (tos 0x88, ttl 64, id 10889, offset 0, flags [none], proto UDP (17), length 94)
180.150.52.147.45199 > 8.8.8.8.53: 38366+ [1au] A? www.elhorrindeclaudia.com. (66)
07:11:10.626747 IP (tos 0x0, ttl 59, id 26586, offset 0, flags [none], proto UDP (17), length 130)
8.8.8.8.53 > 180.150.52.147.45199: 38366$ 3/0/1 www.elhorrindeclaudia.com. A 172.67.71.33, www.elhorrindeclaudia.com. A 104.26.4.54, www.elhorrindeclaudia.com. A 104.26.5.54 (102)
Please, ignore TOS, this is just to show you that tcpdump works fine, we can't discard it as the problem.
To answer your questions, a) no VPNs, and b) packets sent to port 53 had TOS 0x0 (CS0). And, when running watch -n 1 -t -d -exec tc -s qdisc show dev eth1 packets were classified into the "Best Effort" tin.
Sorry, gotta nip out for the rest of the day, I'll be back, for sure. I would like to solve this mystery.
1 Like
this is your outgoing traffic to 8.8.8.8:53 with TOS 0x88 = af41 DSCP so this is the expected result, is not it?
according to tcpdump above it is not the case, or do i miss something?
if it is confirmed that the right path is in use (i.e. outgoing DNS traffic is indeed using the WAN direction over interface wan) then we can filter down obviously to tcpdump -v -n -i <wan> 'host 8.8.8.8 and port 53 to filter out e.g. ICMP traffic which has different class. but according to your report traffic to 8.8.8.8:53 is using TOS=0 ... so assuming you should see not TOS=0 maybe tcpdump is not hooked to the right place and only see pre-marked traffic probably? otherwise it is strange
1 Like
Which is fine, I do not use qosify* nor do I set specific DSCPs for my DNS traffic, my point was more about tcpdump's unwillingness to look into encapsulations which can result in no reports in spite of the desired traffic traversing the link...
) For two reasons:
a) I am fine with how my network behaves* under load without explicitly setting/enforcing DSCPs on the router (I think I use DSCPs for ssh/mosh on the clients)
b) I use an turris omnia as main router, and since I want to use their automatic update feature*** I am still far away of being able to test qosify since their stable OS is still based on OpenWrt19...
**) I have sufficient capacity that "mice" traffic like DNS is always below its fair capacity share and hence will not experience much queueing, in fact most of the time it will profit from the mild new/sparse flow boosting that cake/fq_codel perform which makes DNS snappy enough for my use... While I use layer_cake.qos to be able to prioritize packets if need be, I consider prioritization as a "great power/great responsibility" kind of problem and aim at using it as sparingly as possible; which has the added advantage that I have only little high-prio packets and always plenty of normal-prio packets to move out of the way so the high-prio packets actually get transmitted earlier...
***) I personally trust them and think it safer to have automatic updates than having to remember when to re-flash my families main router.
ok, this makes sense. I was under the impression you have too the same problem as @amteza .
/off
i think this is a very good description what prioritization is about. probably in this thread saying that prioritization using qosify or sqm or whatever is not going to solve automatically all networking problems, and the less using these tools (i.e. the simplest config instead of the over complicated tens of different classes for very specific traffic kind of approcah) is the better, maybe is blasphemy. but there are so many components out of my control so at some point i had to realize it is too much waste of my time with very little to none improvement dealing with very fine tuned, very detailed, very "sophisticated" configs.
2 Likes
I think COD isn't the "best" game to troubleshoot our connection for one reason...it has SBMM (Skill Based Matchmaking)....so if game connects your with etc. players that AREN'T as good as you...based on statistics the game has ..etc accuracy and so on.....when you start playing game ADD to you artificial latency to play with them..to be "fair" for them....this is the thought!!!In real time gaming it nevers work as should....so artificial lag it is much more than it needed.....
And thats why in one game it plays smooth...and after some time is tottaly crap....you meter your speed and bufferbloat is A+...and ping in game is under etc 30ms.
And you have a big ! above your haed why is this happening....it isn't your connection..it is SBMM.
Try other games and will see that they play ok.
1 Like
+1; I guess in the past such bespoke QoS assemblies paid off reasonably, but IMHO cake/fq_codel's flow-queueing and sparse-boost solve a lot of the problems that differential prioritization by explicit rules aim at. And if the default behaviour is sort of sane, a lot of complication can be avoided (but I happily admit that this is a subjective/policy issue, just because that works acceptably for me does not mean it works better than detailed prioritization for everybody else).
1 Like
This is my bad, this last test before I left for the day was done with my usual configuration in place, so no Qosify. I posted it as a proof and confirmation that the right path was eth1 (WAN) and traffic can be captured normally.
I'm going to test again in a moment Qosify in my router to see if I can tackle down this bloody issue. However, I would like to say 1) I'm just trying to help @xato_coslada, his system is behaving similar to what is happening to me with Qosify, 2) I don't use Qosify in my normal daily use, and 3) totally agree with keeping things simple and in my household only VoIP/VoWiFi, GeForce Now traffic and Parsec get some kind of high priority, it's easier and works.
1 Like
Thank you for this, good to know. However, we are an step before that and what I/we have above our heads is a huge question mark (?) "why is this not tagging packets?".
To clarify, I think qosify is a great tool, and once my router is modern enough to allow installing it I will also test it. (I will however not aim for an all encompassing QoS strategy, but will use it as a convenient tool for using sparingly )
1 Like
don't worry, we all just want to help. my mumbling was just about that sometimes less is more.
anyhow, this is what i see on my device:
# nslookup www.elhorrindeclaudia.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Name: www.elhorrindeclaudia.com
Address 1: 172.67.71.33
Address 2: 104.26.4.54
Address 3: 104.26.5.54
Address 4: 2606:4700:20::ac43:4721
Address 5: 2606:4700:20::681a:536
Address 6: 2606:4700:20::681a:436
and
# tcpdump -i eth1 -n -v 'host 8.8.8.8 and port 53'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:30:52.017370 IP (tos 0xb8, ttl 64, id 24059, offset 0, flags [DF], proto UDP (17), length 71)
x.x.x.x.53333 > 8.8.8.8.53: 13116+ A? www.elhorrindeclaudia.com. (43)
21:30:52.017427 IP (tos 0xb8, ttl 64, id 24060, offset 0, flags [DF], proto UDP (17), length 71)
x.x.x.x.53333 > 8.8.8.8.53: 16104+ AAAA? www.elhorrindeclaudia.com. (43)
21:30:52.064501 IP (tos 0x0, ttl 122, id 10850, offset 0, flags [none], proto UDP (17), length 119)
8.8.8.8.53 > x.x.x.x.53333: 13116 3/0/0 www.elhorrindeclaudia.com. A 172.67.71.33, www.elhorrindeclaudia.com. A 104.26.4.54, www.elhorrindeclaudia.com. A 104.26.5.54 (91)
21:30:52.083051 IP (tos 0x0, ttl 122, id 23645, offset 0, flags [none], proto UDP (17), length 155)
8.8.8.8.53 > x.x.x.x.53333: 16104 3/0/0 www.elhorrindeclaudia.com. AAAA 2606:4700:20::ac43:4721, www.elhorrindeclaudia.com. AAAA 2606:4700:20::681a:536, www.elhorrindeclaudia.com. AAAA 2606:4700:20::681a:436 (127)
and my config is
qosify - 2022-03-22-57c7817f-1
/etc/qosify/00-defaults.conf:
# DNS
tcp:53 voice
tcp:5353 voice
udp:53 voice
udp:5353 voice
/etc/config/qosify:
config class voice
option ingress EF
option egress EF
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_down 1000mbit
option bandwidth_up 35mbit
option overhead_type docsis
option ingress 0
option egress 1
option mode diffserv4
option nat 1
option host_isolate 1
option autorate_ingress 0
option ingress_options ""
option egress_options "ack-filter"
option options ""
which looks ok as TOS=0xb8 -> DSCP 0x2e = EF. so without washing I can see marking does work. why you have different result, i am lost
I don't know, mate. Here goes another set of data:
tc queues:
qdisc cake 8013: dev eth1 root refcnt 2 bandwidth 47Mbit diffserv4 dual-srchost nat nowash ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
qdisc cake 8014: dev ifb-eth1 root refcnt 2 bandwidth 312Mbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64
They look good to me, same configuration in Qosify. And here you go again:
@openwrt# ➜ ~ tcpdump -vv -i eth1 host "8.8.8.8" and port 53
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
06:47:35.297026 IP (tos 0x0, ttl 64, id 13545, offset 0, flags [none], proto UDP (17), length 94)
180-150-52-147.b49634.mel.static.aussiebb.net.53613 > dns.google.53: [bad udp cksum 0xf994 -> 0xec60!] 29349+ [1au] A? www.elhorrindeclaudia.com. ar: . OPT UDPsize=1232 (66)
06:47:35.305560 IP (tos 0x0, ttl 59, id 57954, offset 0, flags [none], proto UDP (17), length 130)
dns.google.53 > 180-150-52-147.b49634.mel.static.aussiebb.net.53613: [udp sum ok] 29349$ q: A? www.elhorrindeclaudia.com. 3/0/1 www.elhorrindeclaudia.com. A 172.67.71.33, www.elhorrindeclaudia.com. A 104.26.4.54, www.elhorrindeclaudia.com. A 104.26.5.54 ar: . OPT UDPsize=512 (102)
No marking done, TOS is 0x00 as you can see. Do you know what? I'm recompiling the whole SNAPSHOT to try later. 
Can you elaborate on the sparse boost? If a Windows update runs and I visit a website will that get boosted? What about Zoom call?
What makes a flow sparse? Thresholds hard coded?
So fq_codel operates two lists, a new_flows and an old_flows list, on every "round" it will first service the new_flows list before working on the old_flows list, so new_flows have some priority over old flows (it makes sure to also process the old_flows). If a flow stays below its quantum value it will considered to still be new otherwise if it exceeds that quantum it will be moved to the end of the old flows list... So whether an ongoing flow is considered new or not depend on it not actually building up a queue... and that depends a bit on the total traffic and number of flows, but the strongest driver is a flows own behavior.
probably yes, at least at the beginning of the flows involved in accessing that web page...
Again, if the amount of queue the zoom call creates stays small enough it will be considered sparse...
Its behaviour , essentially whether ingress rate - egress rate is well balanced and whether the ingress is nicely paced... bursty flows can loose the sparse bonus even if over longer timeframes ingress and egress are well matched...
So no real hard coded thresholds (except the quantum value which for fq_codel can be manually configured, not sure about cake).
1 Like
All right, time for another update. I've worked in @xato_coslada's router this morning, we created a new configuration without Qosify, with iptables, with tc-cake and with ctinfo to DSCP mark packets (connections) on top of diffserv4 linked to his wan.VLAN (wan.1074).
It bloody works! No hassle at all, at first try! 
I'm still shocked, what's going on with my Qosify configuration? The hilarious thing is that I'm trying in a RPi4 (bcm2711) and he's using a WRT3200AC (mvebu), cleary, this difference does not matter.
Can it be we run latest SNAPSHOT? Is anyone else running one of the latests snapshots and has it working with Qosify? @grrr2?
Does CAKE fix that to a set value? Or maybe autoadjust it? Does that correspond to proportion of bandwidth?