HTOP,
After testing, seems like CPU-1 is only being used. Around 80% during iperf. CPU2-4 are 0%.
Is it a limitation or did I setup wrongly.
1 Like
What about non sqm?
- date script were refreshed?
- ini settings or related dmesg(as previously requested)?
- overview of testing conditions?
- the htop screenshot shows otherwise (as does any benchmark i've done)
not enough info to help or even acquire feedback i'm afraid...
either way... i'm sure functionally you are better off than how the build used to be... so perhaps wait for more feedback or until you re-upgrade to the latest script...
if you do decide to enable irqbalance as suggested above... please be sure to disable / comment out;
#PERFTWEAKS #and
#PACKETSTEERING
and reboot... otherwise any further tests or results without proper information will likely be setting soup...
1 Like
Any chance you have a baseline of how it should perform? e.g. cpu usage on 4 cores without sqm 1gbps full tilt.
that's a good question...
but it's relative to the many things listed above... and as we don't have that information...
we'd be comparing apples with oranges...
verbage
but as a rough guide i've listed already above...;
- htop tests, top tests...
iperf tests need to be carried out under controlled conditions... but realworld links over ~600Mb are similar if not more preferrable... in this case... ( due to the discussed per connection steering quirk )
simply running a few speed tests in a row ( using various providers ) and print screening luci_statistics > processor > ( 1 hour - update every 30secs ) is good enough to show how things are generally performing... ( change it to a week to see a the broader results of whatever has been applied over that time )
( under whatever apple or orange we are currently talking about )...
here is mine for the whole week of testing... ( again i'm only on 50/15 so the higher columns are when I tested over the isolated 'fake-wan' )...
- the monday section with the high pink peaks at the end are under irqbalance(only)...
- the peaks following around tuesday are under the build default settings... ( which have been slightly changed since then )...
both peaks are indicative of iperf ( single client ) ~+/-931Mb mean throughput in both directions...
note: sqm IS running during these tests... as it best suits the realworld conditions which would be present amongst the userbase ... in both cases sqm values were set to;
option download '965700'
option upload '932000'
testing without SQM merely isolates raw interface interrupt demand better... (and lessens the validity of realworld efficacy)
(and peak throughput is achievable with sqm on... under these simulated conditions so turning it off would have no effect unless you have 2.5G interfaces...)
#111 MBytes 931 Mbits/sec
... and some graphs showing just how minimal usb3 overheads are on this device/nic
download them and open them locally in a browser to click around...
My installation has been saying "update-unavailable" for a while. Everything is rock solid, no complaints at all.
I'm wondering if it would be wise to update to the latest snapshot so that I don't get too far behind. Or, maybe, updating would be a Bad Idea & I should wait for a release announcement?
Currently running: SNAPSHOT r15599-37752336bd / LuCI Master git-21.020.56896-af422b1
1 Like
yup... would be worth a sysupgrade... as a rough guide...
- 2months for master is 'getting old'
- 4months for master is probably too old...
so in your case your probably right in the money in terms of smallest hassle biggest reward...
still sussing/ironing out the best way to handle the notifications... most of this stuff all comes down to user feedback/needs so the more feedback I get the better it'll be...
...glad you asked tho' because;
verbage
i've just added ( within the last build ) an experimental option... to the built in update check command for when this occurs ( as of now its helpful as you don't have to go to github and it downloads and validates[sha256sum+certificate] the file quickly )...
when you upgrade to the latest build you'll be able to manually do...
rpi-sysup-online.sh gitnewest check
#or
rpi-sysup-online.sh gitnewest dlonly
-
did not enable the actual 'sysupgrade -R /tmp/FILE' part yet... but it prints it for you...
-
probably will add this a little less noisily in the future in brackets after the update-unavailable message or something once I get my head around the broader use-cases / logistics...
Cool, thank you!
Personally, I really like the update-notification. I try very hard to update All Of The Things weekly but sometimes life gets busy and I appreciate a "Hey dummy, you're getting behind" reminder.
Edit: Updating to rpi4.64-snapshot-26019-2.9.17-116-r16357-ext4-sys.img.gz too no time at all and was seamless.
1 Like
- i'll generally leave any critical/noteworthy update/bug notices at the top of the readme at github/builds download folder
verbage
this way if there are bugs within updates or known issues with older builds so people can make local judgement calls on how worthwhile the update is... often even when the message is active it's a minor non broadly critical bug... and found myself posting heaps about general release notices in this thread so started to just update the top of that readme to reduce the chatter here for all but really important notices.
- seems like I need to change the notification to only warn on major changes
verbage
( ignore the '-Number' in the localversion )... this would make it less annoying for those who updated yesterday yet I pushed a 'minor change' yet allow the message to keep showing for those on lower major versions ( and i've recommended the version update )...
thanks... i'll see how that goes when I get around to it...
edit:
- added 'minor not green'
- added ini UPDATECHECKPERIOD="daily" (weekly/monthly) and print it
a (likely buggy for a release or two... please pm me any odd looking stuff in the next build or two)
brilliant... that makes it all worthwhile...
whats the name of this theme? and how to install it?
bootstrap is installed...: goto system > system > language and style > design
for persistence... set;
LUCIDEFAULTHEME="bootstrap"
(for darkness install the 'darkreader' browser plugin)
I get this after speed test full tilt, look at CPU0. Albeit, not always so I can't replicate it every time. But it happens quite a lot which is enough. rtl8152 usb chipset.
Restarting interface and replug USB doesn't work. ONLY works after hard reboot, everything is fine and detected. Seems like a software lock out for the USB.
1 Like
Hi,
I recently updated from 2.7.105-5 to the latest stable (3.0.17-23).
First of all the upgrade went through without any major issues. Very good job!!
However i noticed some serious performance degradation in terms of bandwidth speed.
It went down from 500+ to ~50Mbps.
Server: myLoc managed IT AG - Dusseldorf (id = 17392)
ISP: Vodafone Germany Business
Latency: 15.95 ms (3.86 ms jitter)
Download: 52.67 Mbps (data used: 87.9 MB)
Upload: 50.29 Mbps (data used: 41.8 MB)
Packet Loss: 0.0%
First thing i had to do was to disable SQM entirely. Not needed in my case.
Second step was to modify wrt.ini
commented out:
#PERFTWEAKS="default"
followed by a reboot.
Bandwidth performance is now back to "normal".
Server: myLoc managed IT AG - Dusseldorf (id = 17392)
ISP: Vodafone Germany Business
Latency: 11.37 ms (5.08 ms jitter)
Download: 533.94 Mbps (data used: 722.7 MB)
Upload: 49.43 Mbps (data used: 38.7 MB)
Packet Loss: 0.0%
It might not work for everyone, but its a good start.
1 Like
Since last summer I am running an official snapshot which was rockstable for months.
LAN is on ethernet WAN is connected via r8152 to a fibre modem (DHCP).
3 Days ago I tried this build. The ipv6 connectivity is very unstable, dies every couple of hours. I got the case the connection looks proper, my smartphone albeit has no ipv6 connectivity (anymore).
Then I got a couple of times the WAN6 interface has no IP addresses attached anymore.
Mon Apr 19 06:24:28 2021 daemon.notice netifd: WAN (5157): udhcpc: sending renew to 100.124.1.45
Mon Apr 19 06:24:28 2021 daemon.notice netifd: WAN (5157): udhcpc: lease of 100.116.248.208 obtained, lease time 3600
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /etc/hosts - 4 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/odhcpd - 1 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq-dhcp[22920]: read /etc/ethers - 0 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /etc/hosts - 4 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/odhcpd - 1 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq[22920]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Mon Apr 19 06:50:30 2021 daemon.info dnsmasq-dhcp[22920]: read /etc/ethers - 0 addresses
Mon Apr 19 06:50:30 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:30 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:31 2021 daemon.debug dnsmasq[22920]: stopped listening on eth1(#12): 2a00:6020:1000:1f::37b8 port 53
Mon Apr 19 06:50:31 2021 daemon.debug dnsmasq[22920]: stopped listening on br-lan(#14): 2a00:6020:b2b7:a800::1 port 53
Mon Apr 19 06:50:32 2021 daemon.warn odhcpd[2713]: A default route is present but there is no public prefix on lan thus we don't announce a default route!
Mon Apr 19 06:50:34 2021 daemon.notice netifd: Interface 'WAN6' has lost the connection
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain test
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain onion
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain localhost
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain local
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain invalid
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain bind
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain lan
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.44.50#53
Mon Apr 19 06:50:34 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.45.50#53
Mon Apr 19 06:50:49 2021 daemon.notice netifd: Interface 'WAN6' is now up
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain test
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain onion
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain localhost
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain local
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain invalid
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain bind
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using only locally-known addresses for domain lan
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.44.50#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 185.22.45.50#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 2a00:6020:100::1#53
Mon Apr 19 06:50:49 2021 daemon.info dnsmasq[22920]: using nameserver 2a00:6020:200::1#53
Mon Apr 19 06:50:49 2021 user.notice firewall: Reloading firewall due to ifup of WAN6 (eth1)
Mon Apr 19 06:50:50 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup of WAN6 (eth1)
Mon Apr 19 06:53:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 1/0 in 60 seconds
Mon Apr 19 06:54:28 2021 daemon.notice netifd: WAN (5157): udhcpc: sending renew to 100.124.1.45
Mon Apr 19 06:54:28 2021 daemon.notice netifd: WAN (5157): udhcpc: lease of 100.116.248.208 obtained, lease time 3600
Mon Apr 19 06:54:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 2/0 in 60 seconds
Mon Apr 19 06:55:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 3/0 in 60 seconds
Mon Apr 19 06:56:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 4/0 in 60 seconds
Mon Apr 19 06:57:57 2021 user.warn ddns-scripts[10851]: ServerService: Get local IP via 'interface' failed - retry 5/0 in 60 seconds
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc4:432c:9b11::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '10.83.66.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ip6weight '1'
config interface 'WAN'
option proto 'dhcp'
option ifname 'eth1'
config interface 'WAN6'
option proto 'dhcpv6'
option ifname 'eth1'
option reqprefix 'auto'
1 Like
Holy... I discovered something. After testing wireguard, I disabled it and did a speedtest.
Maybe you could explain to me what magic happened here. From using cpu0 exclusively to all cores just by adding a wireguard instance. That's the only thing I did, add a wireguard instance. Wow.
Before: CPU0
thanks... i've now removed most of the perftweaks.sh and 20-smp due to limited input...
( but is is good to see that you read the relavent notices and took the appropriate action of turning them off )
as for the 50Mb/s... some setup scripts setup sqm with this as a default if they detect sqm config is blank... they may have misdetected your setup and 'unconfigured'...
next time this occurs... double check 'uci show sqm'...
thanks for the report... i'm pretty stumped by the log... you could start removing any opkg packages that are called '6' something one by one...
the other thing we can do if you are really interested in getting to the bottom of it... is
-
test your config on a par for par ( current ) master... to eliminate anything mainline quickly... then
-
I can build you the smaller 'std' variant with less packages... and you can then start uninstalling stuff if needed...
if you did not mention official was rock solid I would say it's probably not build specfic or at least... its very config/(isp connection) specific...
but I really have no idea what to say on that one... sorry...
never seen this before... ( maybe my ipv6 skills need some miyagi-san action ) what does it do? turn some sysctl knobs to prefer ipv6 or something?