also... it is not 'top priority'... giving any one PC 'top priority' implies you have total control of all traffic on that device ( and your highest tier free of all other traffic to assign )... not a wise move for most networks... surely you value your VOIP? DNS? traffic higher than gaming chat or windows updates on your gaming pc?
there is no capability within the script as things can go downhill very quickly... fwiw... if you really want to do that... the closest equivalent would probably be to remove it from gaming macs...
make your ipsets persistent;
RPI4QOS_IPSETPERSIST=1
add the PC ipv4 address to the latsens ipv4(6) ipset and restart sqm;
the collectd sqm collector script has been observed re-spawning itself many times... has been going on for probably around a month+... and I've been hoping for a general fix / more info to surface...
two weeks ago... once again via 'ps w', saw there were around 10 of them running... so I implemented a respawn limit to two... this had the effect of breaking sqm logging once that limit was reached...
i'm not sure which is the lesser of two evils... heaps of background processes or sqm logging stopping... perhaps a cron workaround restarting luci_statistics every 24 hours might be a better... ( which should help regardless whether my fix is implemented or not in the interim ) or something a teency bit fancier that finds all the zombies and ends those...
the message below I don't think is related... ( but it could be? ) pretty sure this message has been occuring for around 3 months... ( and i'm not sure what it relates to )
can you post the error for the dns plugin? + 'uci show luci_statistics | grep dns'
cheers
dns-plugin inclusion was marginal... kinda useful when the dnsmasq bugfixes were going on... but enabling for all builds was probably beyond what i'd personally / guess majority of users would enable...
i'll disable the 'beta' autosetup for that I think ( leave it up to the user to manually enable )... unless anyone else has input...
wireguard users are advised that for the 101(r16076) build, I needed to remove 'wireguard' as the package did not exist... ( kmod and related packages are all included... I think the above was just a previous wrapper package? )
remember reading something somewhere about it being 'in kernel' in the future but thought that may have been from 5.10 onwards... which we are not on yet...
could be a wrapper rejig and wireguard is perfectly fine... could be an interim state...
Just have to ask and here is probably the right place to do so. In the upcoming OpenWRT 21.02 release is there a official Rpi support? And if so does it make building and maintaining easier?
Here's the output of logread -e collectd > collectd.log
Looks like there have been multiple respawns of collectd (I count 13) - it seems the last respawn before the more than 2 logs didn't exit normally, and is missing the following:
freikfunk feed has been removed from master I believe... this probably wont be present in newer (factory) distfeeds.conf files...
as these are carried across within sysupgrade data... users of existing builds are advised to disable the feed in '/etc/opkg/distfeeds.conf' preferrably prior to any upgrades (or if you restore a backup) as it will likely bork autorestore functionality;
Hi.
I've been pushing my rpi 4 a little too much with multiple jobs all over the day and I would like to overclock it.
However, when I try to do it, it appears the frequency does not change.
Isn't it enough to set in /boot/config.txt the lines:
over_voltage=3
arm_freq=1600
due to the various risks and complexities involved with overclocking...
on this build... the preferred method to 'overclock'(and 'underclock') is by tweaking the governor ( runtime within OS )...
/root/wrt.ini
POWERPROFILE="quickest"
try the above... ( check there is not a value already assigned i.e. a line that is uncommented... I may have set 'quick' as the default recently... cannot remember )
( in which case change that or duplicate and comment it out )
after changing this setting to apply without rebooting run;
fyi, as your sending your collectd stuff to a server... technically you could/should do without the 'persistentlucistatistics' feature...
alas... I haven't cleanly checked/implemented a clean way to do this currently... i'd assume adding SERVICESDISABLED="persistentlucistatistics" to wrt.ini and commenting out the existing line in /etc/crontabs/root
would be the logical way to do this... but probably better to not bother for a few builds (or at all if the workaround is ok)... I may get the chance to test/tidy over the next few builds...
basically... what these do is
copy /tmp/rrd to persistent storage in case of power loss ( @neil1 made me aware of this condition ) prior to that... there was no constant 'build-related' restarting of collectd...
some other stuff that tries to transparently retain luci_statistics and nlbwmon data over reboots and upgrades (messy as carp but I'm a little scared to touch it...)
hoping the 'end-existing' workaround largely resolves the fundamental issue for now ...
you can disable that cron script... although the firstboot logic may put it back each upgrade...
