Qosify: new package for DSCP marking + cake

i will test in 30 min after my work and keep inform on result of my gaming thanks for your work :wink:

do you know how to do port mirroring on firewall4 I have the subject here on the belkin rt3200, I tried but in vain last night thank you it's to see if the traffic is correct on my console with qosify and dscp mark

re: i'm enter , i test cod now edit 18:15

1 Like

hello everyone after 1h30 of play, the results are very good in the feelings I have a great hitreg for the moment knowing that 5 devices are simultaneously connected to my house including the neighbor who asked me for my wifi I cannot copy on mac at the moment my tc -s qdisc so I attach the capture if you want to interpret the results;)

Capture d’écran 2022-02-09 à 20.20.18
Capture d’écran 2022-02-09 à 20.20.06

2 Likes

Well, all we can see is there is traffic in all 4 tins, but drops only in Bulk and BestEffort (let's ignore the 2 drops in wan's egress Video tin), indicating that the two high priority tins do not seem to contain too much traffic. peak delay (pk_delay_ in egress Best Effort sits at 9.42ms implying that your egress link was/is seeing quite some traffic around the time you sampled the statistics...

Personally I would not specify ptm, but simply make sure the shaper rate is at least 2% smaller than the sync rate.

Finally the overhead looks odd: overhead 26, but at the same time accounted max packet size is 1550 for 1500 payloads, which seems unexpected to me
But then this is probably the result from ptm:
(1500+26) * 65/64 = 1549.84375
-> which rounds to 1550...
ho hum, still think PTM's 64/65 coding is better dealt with statically by simply making sure the shaper rate is <= (64/65) * syncrate, but that is my personal preference.

2 Likes

ok thanks for clairification :wink: my config actual is like this

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"

iam behind modem router + router OpenWrt

maybe not configurate in "option option "ether-vlan "

the result witouth ethervlan is ptm overhead 22

like my new screen

Capture d’écran 2022-02-09 à 21.00.22

1 Like

Yeah, I dislike these compound keywords and instead would add the following to egress_options and ingress_options:
mpu 68 overhead 26
and for bandwidth_up and bandwidth_down (I am not sure that "bandwidth" is the best term here) I would simply plug in the results achievable in a decent reliable speedtest... (which automatically deals with ptm's 64/65 coding).

But that really will not change anything substantial, except fitting better t my personal taste (the mpu stanza might change things but you would need to have substantial ACK traffic under saturation before this is likely to become an issue).

1 Like
config interface wan
	option name wan
	option disabled 0
	option bandwidth_up 16mbit
	option bandwidth_down 56mbit
	option overhead_type none 
	# defaults:
	option ingress 1
	option egress 1
	option mode diffserv4
	option nat 1
	option host_isolate 1
	option autorate_ingress 0
	option ingress_options "mpu 68 overhead 26"
	option egress_options "mpu 68 overhead 26 wash"
	option options ""

??

Since I have no device with qosify installed I have no idea whether that is a valid configuration, but if you post the tc -s qdisc output after feeding that config to qosify we should be able to see how cake ends up being configured.

1 Like

yes he seems goods now thanks i will try :slight_smile:

@moeller0
@elan

it's hard to get an idea of ​​the game because unfortunately the game I'm playing is full of cheats some have modified controllers other so called whallack aim etc, but I know one thing it's the way of which my character moves if it's fluid or not, this evening I had good hitregs but two or three character movement problems the servers were updated today I will test tomorrow to see if they have stabilized because I think that the problem comes from them and not from the network at home because my line is good having watched everything;)

1 Like

It didn't work for me but I didn't notice any improvement

1 Like

I find it works best for me to prioritize just my game and everything else to the best effort class

2 Likes

hello if you prefer so, but the current settings are really very good on my side;)

1 Like

I think you misunderstand me I am not saying that it does not work it is that in my link it seems that it does not work

hello everyone, @moeller0

can you give me the command to perform for adsl

and for fiber optic please

for qosify option.. thanks in advance

1 Like

I can only guess:
atm mpu 96 overhead 48
on adsl quite a number of different encapsulations can be used (including ptm) so this is really guess work, alternatively if the link uses atm/aal5 you can follow https://github.com/moeller0/ATM_overhead_detector and try to heuristically deduce the actual per packet overhead on the link, 48 however is the largest per packet overhead I have personally encountered. mpu 96 the payload of 2 ATM cells is also mainly a guess.

That is not specific enough, as it depends on the exact link, e.g. most active optical ethernet will require something like mpu 84 overhead 38, but GPON/XGSPON will be different...

1 Like

Why? Isn't that the usual standar used by ISPs?

GPON is principaly a norme between orange sfr main isp french only free use XGSPON who has 10gbits dl and 700 upload with freebox delta

I also encounter a small problem with qosify, it's when my orange box restarts following maintenance or other or when it loses syncro,

qosify stops and I have this message, you just have to restart it or restart the router, both work for qosify to work

Capture d’écran 2022-02-10 à 14.06.22

1 Like

Because different technologies use different encapsulations... some like DOCSIS describe the traffic shaper pretty precisely and hence are easy to account for, some like ethernet have pretty decent standards documents and are well-known and described for a long time. and others like GPON simply leave a lot of leeway in the standards so that it is hard to deduce the applicable overhead purely from reading standard documents. At least I had little luck figuring out applicable GPON overhead precisely. ISPs might know or might not know* but they typically do not tell us...

*) They should, because to properly configure each users traffic shaper knowing the aplicable overhead really helps, so a competent ISP will tend to configure that correctly, but those in the ISP doing ang knowing that are often shielded from end-users :wink:

there is /etc/hotplug.d/iface/10-qosify which will run in case of any interface related event happens, e.g. connect/disconnect. at this moment the content is very simple:

#!/bin/sh
ubus call qosify check_devices

you may try this whether it helps:

#!/bin/sh
#ubus call qosify check_devices
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wan ] || exit 0
sleep 10 && /etc/init.d/qosify restart

this will check if iface event is "ifup" on interface "wan", i.e. when wan interface (re)connects only then will wait for 10 seconds for wan to settle and restart qosify. just an idea.

4 Likes

I actually have problems with hotplug on my mainrouter (running OpenWrt 19 based turris OS 5) and had to add the following to /etc/hotplug.d/net/40-iface-synthesizer

root@turris:~# cat /etc/hotplug.d/net/40-iface-synthesizer 
#! /bin/sh

# 20210803 since 0725 TOS fails to call the hotplug.d/iface scripts causing issues with among other's sqm, ddns and firewall
# so here we try to synthesize the relevant information and manually call those scripts as a stop-gap measure
# Here are examples of hotplug.g/net events and their information
#Aug  2 23:23:36 turris hotplug_net_logger: USER=root ACTION=remove SHLVL=1 HOME=/ SEQNUM=1477 IFINDEX=32 HOTPLUG_TYPE=net DEVPATH=/d
#evices/virtual/net/pppoe-wan mangled_fs=btrfs LOGNAME=root DEVICENAME=pppoe-wan TERM=linux SUBSYSTEM=net PATH=/usr/sbin:/usr/bin:/sb
#in:/bin INTERFACE=pppoe-wan PWD=/ DEVTYPE=ppp 
#
#Aug  2 23:23:46 turris hotplug_net_logger: USER=root ACTION=add SHLVL=1 HOME=/ SEQNUM=1478 IFINDEX=37 HOTPLUG_TYPE=net DEVPATH=/devi
#ces/virtual/net/ppp0 mangled_fs=btrfs LOGNAME=root DEVICENAME=ppp0 TERM=linux SUBSYSTEM=net PATH=/usr/sbin:/usr/bin:/sbin:/bin INTER
#FACE=ppp0 PWD=/ DEVTYPE=ppp  
#                                                                                                       
#Aug  2 23:23:46 turris hotplug_net_logger: USER=root ACTION=move SHLVL=1 HOME=/ SEQNUM=1481 IFINDEX=37 HOTPLUG_TYPE=net DEVPATH=/dev
#ices/virtual/net/pppoe-wan mangled_fs=btrfs LOGNAME=root DEVICENAME=pppoe-wan TERM=linux SUBSYSTEM=net DEVPATH_OLD=/devices/virtual/
#net/ppp0 PATH=/usr/sbin:/usr/bin:/sbin:/bin INTERFACE=pppoe-wan PWD=/ DEVTYPE=ppp        

# here are the variables passed to / expected by iface scripts
#ACTION	“ifup”, “ifdown”, “ifupdate”
#INTERFACE	Name of the logical interface which went up or down (e.g. “wan” or “ppp0”)
#DEVICE	Physical device name which interface went up or down (e.g. “eth0.1” or “br-lan”)
#IFUPDATE_ADDRESSES	“1” if address changed
#IFUPDATE_PREFIXES	“1” if prefix updated FIXME what constitutes an update?


VERBOSE=0


[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "Running 40-iface-synthesizer"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer $(env)

# 1) generate the required action name
NET_ACTION="$ACTION"
case "$NET_ACTION" in
    remove)
	IFACE_ACTION="ifdown"
    ;;
    add|move)
	IFACE_ACTION="ifup"
    ;;
    *)
	# log the environment variable to help figuring out what went wrong
	logger -t hotplug_synthesizer "ERROR: Unhandled ACTION ($ACTION) encoutered."
	logger -t hotplug_synthesizer $(env)
	exit 0
    ;;
esac
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_ACTION: $NET_ACTION; IFACE_ACTION: $IFACE_ACTION"




# 2) assign the INTERFACE
NET_INTERFACE="$INTERFACE"
IFACE_INTERFACE="$NET_INTERFACE"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_INTERFACE: $NET_INTERFACE; IFACE_INTERFACE: $IFACE_INTERFACE"


# 3) get the DEVICE
NET_DEVICE="$DEVICE"
case "$NET_INTERFACE" in
    TMP_IFB_4_SQM)
	# this gets created a lot during SQM scipts execution so silence this
	exit 0
    ;;
    eth*)
	NET_DEVICE=$NET_INTERFACE
    ;;
    pppoe-wan)
	# this needs to get automatically extracted
	NET_DEVICE="eth2"
    ;;
    *)
	logger -t hotplug_synthesizer "ERROR: Unhandled INTERFACE ($NET_INTERFACE) for DEVICE extraction encountered."
	logger -t hotplug_synthesizer $(env)
	exit 0
    ;;
esac
IFACE_DEVICE="$NET_DEVICE"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_DEVICE: $NET_DEVICE; IFACE_DEVICE: $IFACE_DEVICE"



# 4) deal with IFUPDATE_ADDRESSES
NET_IFUPDATE_ADDRESSES="1"
IFACE_IFUPDATE_ADDRESSES="$NET_IFUPDATE_ADDRESSES"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_IFUPDATE_ADDRESSES: $NET_IFUPDATE_ADDRESSES; IFACE_IFUPDATE_ADDRESSES: $IFACE_IFUPDATE_ADDRESSES"


# 5) deal with IFUPDATE_PREFIXES
NET_IFUPDATE_PREFIXES="1"
IFACE_IFUPDATE_PREFIXES="$NET_IFUPDATE_PREFIXES"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_IFUPDATE_PREFIXES: $NET_IFUPDATE_PREFIXES; IFACE_IFUPDATE_PREFIXES: $IFACE_IFUPDATE_PREFIXES"


[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "ACTION=$IFACE_ACTION INTERFACE=$IFACE_INTERFACE DEVICE=$IFACE_DEVICE IFUPDATE_ADDRESSES=$IFACE_IFUPDATE_ADDRESSES IFUPDATE_PREFIXES=$IFACE_IFUPDATE_PREFIXES $IFACE_SCRIPT"

# 6) find all scripts in /etc/hotplug.d/iface and call them with appropirate environment variables
for IFACE_SCRIPT in /etc/hotplug.d/iface/*; do
    logger -t hotplug_synthesizer "Calling $IFACE_SCRIPT"
    logger -t hotplug_synthesizer "ACTION=$IFACE_ACTION INTERFACE=$IFACE_INTERFACE DEVICE=$IFACE_DEVICE IFUPDATE_ADDRESSES=$IFACE_IFUPDATE_ADDRESSES IFUPDATE_PREFIXES=$IFACE_IFUPDATE_PREFIXES $IFACE_SCRIPT"
    ACTION=$IFACE_ACTION INTERFACE=$IFACE_INTERFACE DEVICE=$IFACE_DEVICE IFUPDATE_ADDRESSES=$IFACE_IFUPDATE_ADDRESSES IFUPDATE_PREFIXES=$IFACE_IFUPDATE_PREFIXES $IFACE_SCRIPT
done

which is a crude hack, but got hotplug to work again.... (I really need to spend some quality time finding the root-cause of the issue). It is not completely impossible that the same problem happens here and that the reconnect does not tickle hotplug correctly.

2 Likes

ifupdate i think is for example if interface ip address is updated.

hm, not sure what is your issue actually, why you not receive iface events, and why you need to hook to net just to fire iface scripts ... looks really strange.

1 Like