i will test in 30 min after my work and keep inform on result of my gaming thanks for your work
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
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;)
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.
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).
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.
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;)
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...
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
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
# 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" = "1" ] && logger -t hotplug_synthesizer "Running 40-iface-synthesizer"
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer $(env)
# 1) generate the required action name
case "$NET_ACTION" in
# 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)
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_ACTION: $NET_ACTION; IFACE_ACTION: $IFACE_ACTION"
# 2) assign the INTERFACE
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_INTERFACE: $NET_INTERFACE; IFACE_INTERFACE: $IFACE_INTERFACE"
# 3) get the DEVICE
case "$NET_INTERFACE" in
# this gets created a lot during SQM scipts execution so silence this
# this needs to get automatically extracted
logger -t hotplug_synthesizer "ERROR: Unhandled INTERFACE ($NET_INTERFACE) for DEVICE extraction encountered."
logger -t hotplug_synthesizer $(env)
[ "$VERBOSE" = "1" ] && logger -t hotplug_synthesizer "NET_DEVICE: $NET_DEVICE; IFACE_DEVICE: $IFACE_DEVICE"
# 4) deal with 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
[ "$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
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.