yep they are more or less the same
1 Like
If you experience that latency in a constant running ping even during speed tests, then yes it should mostly be kept to that range. Of course, at different times of day it can be different. For example when everyone turns on their streaming devices after arriving at home.
i think that will work very well... I think their shaper has a per node bulk limit ~ 250Mb/s and if all traffic from that customer remains below the roof... nothing will be classed BE/subject to additional policing (except for cvc oversubsription aka more cable customers)
1 Like
Great, then I can script it before playing turn on SQM with download/upload option to 250/20Mb/s, and when I'm done turn the SQM off. this is actually the only thing (at least for my use case) where latency matters that much
1 Like
stupid question is it possible to enable SQM on a specific device(maybe by MAC address)?
yeah... automating it (properly) is a little tricky tho due to hysteresis (time since seen, traffic is active etc. etc.) there was a thread about it 6-12months ago... a web page or luci command where you click 'on' and 'off' is a tad better simpler... the iptables pps logger + watcher idea from dlakelan is a pretty decent solution for seamless automation...
1 Like
Hi, could you correct my handle for future reference and search results purposes? Thanks.
1 Like
Not really, for SQM to actually control latency under load it needs to see all traffic. You can use e.g. cake's diffserv keywords and prioritize specific packets if you think your gaming requires that, which if configured with restraint can work well (prioritization really is a zero sum game, for every packet you prioritize another packet will conceptually have to wait a bit longer, so if you try to prioritize too much, you essentially prioritize nothing). Have a look at the qosify module for OpenWrt as an easy entry into the world of priority games 
If you can you should increase the upload again, a download of 2650 is just fine, but for upload mini-slot scheduling depends partly on load, so you might get less variability under upload saturation if you set the upload shaper a bit higher. But by all means test this out to see which rates work well for you, and if 250/20 is already "perfect" for you, do not bother to change just because I believe 250/30 might be achievable.
1 Like
is there a way to install this without building the whole module? I think the package not available in the stable repos
@anon50098793 maybe something that can be added to your images?
its under 'current' (testing)... and being rapidly developed so you would be advised to use this flavour/version...
it appears to also be available in 'stable' (albeit using non recent version)
vert@peanut:/fs/sdd1/openwrt/RTNGext/cache/rpi4/misc/_oldbumplists$ grep qosify *
diff-r17900_r18086:> qosify - 2021-11-12-bfc2cafe
diff-r17900_r18161:> qosify - 2021-11-21-2743e587
diff-r18086_r18161:< qosify - 2021-11-12-bfc2cafe
diff-r18086_r18161:> qosify - 2021-11-21-2743e587
diff-r18086_r18270:< qosify - 2021-11-12-bfc2cafe
diff-r18086_r18270:> qosify - 2021-11-22-06872673
manifest.r18086:qosify - 2021-11-12-bfc2cafe
manifest.r18161:qosify - 2021-11-21-2743e587
manifest.r18270:qosify - 2021-11-22-06872673
1 Like
thank you, can you point me where to grab the package, opkg doesn't see it
opkg install qosify
Unknown package 'qosify'.
Collected errors:
* opkg_install_cmd: Cannot install package qosify.
grep BUILD_ID /etc/os-release
BUILD_ID="r16325-88151b8303"
that does not appear match any of the versions above
( it is the 'release' flavour and qosify is not available on 21.02.1 )
( 'stable' in relation to my builds means best currently available )
1 Like
my bad, then compiling it is
don't forget to disable the sqm service and enable the qosify service
or you could just type this in
rpi-sysup-online.sh -R current
(backup any special random files first tho - or add them to /etc/sysupgrade.conf)
(suggest reading/re-reading the top two posts in the thread specifically search for UPGRADEsFLAVOUR and ENABLEDSERVICES)
1 Like
hmmm never seen before... some suggestions;
- wait 2 mins and refresh OR dismiss OR
rm /etc/dark - switch to bootstrap
pretty much same version no error;
rm /etc/dark
rm: can't remove '/etc/dark': No such file or directory
with switching to bootstrap it works normally
1 Like
can you try Network and land on the "interfaces"?
1 Like