nice.. thanks for the answer I will try 
GET SOME AP INFO (2.9.17-71+)
As it's been recommended to use an external ap... whipped up an extremely-dodgy/semi-functional method to show some stuff on the bootstrap login footer...
/bin/wirelessinfo.sh.sample
#!/bin/sh
#EDIT: probably needs this in /root/wrt.ini LUCIQRCODES=1 #should already be there?
################################### setup for bootstrap only 'login' page get AP clients(and add dhcp4)
#scp /bin/www_cgi-bin_getinfo.sh root@<AP-IP>:/www/cgi-bin/getinfo.sh
#change AP_ip variable below and save
#cp /bin/wirelessinfo.sh.sample /bin/wirelessinfo.sh
######################################################################################################
######################################################################################################
###NOTE: you can also put the ssid:passwd into /etc/luciqrcodes.txt; i.e.: WIFINAME PASSWORD
### to show the off router qrcode
AP_ip="10.2.3.17"
curl http://${AP_ip}/cgi-bin/getinfo.sh?apinfo=brief | while read THIS; do
if grep -q "$THIS" /tmp/dhcp.leases; then
echo "$(grep "$THIS" /tmp/dhcp.leases)"
else
echo "$THIS"
fi
done
you can just create /bin/wirelessinfo.sh with whatever you want to run or if the AP is openwrt... there is a restfull-ish sample included in...
enough for my needs... but would be great to see someone pimp it out...
1 Like
2 questions
-
Can we use multiple ethernet dongles on a hub and not have to manually intervene to mount the correct physical port?
-
has anyone gotten APC USB monitor working? The USB Serial interface is not where it's expected to be and when I found it, doesn't seem to work. I've followed the USB debug instructions in other forums and I am wondering if it is a PI issue.
-
read post 642
-
not enough info... maybe try on an official build or remove/add modeswitch / kmods ( kernel modules ) ... exotic hardware typically involves low(er) level interactions...
@anon50098793 I find packet steering to actually result in slightly lower performance on FiOS 1G/1G. It shouldn't help, as with an USB-based WAN there's only one queue, so there isn't really anything to steer. irqbalance (or manual redistribution of interrupts), however, is absolutely critical.
2 Likes
thankyou... comments have been noted. ( usb bit is especially interesting... )
ini-recipe
PERFTWEAKS=1
IRQMANAGEMENT="irqbalance"
#PACKETSTEERING= #OFF
edit: just benched your settings and indeed they are working well... seems I must have forgot to run the '-R' iperf3 benchs on the initial dummy values...
i've updated the defaults... and will probably switch to what you have in a month or so if nothing else comes to light...
(anyone with wan over 390Mb/s should use the above recipe or curl the updates 20-smp and rpi-perftweaks.sh from github )
or you can set;
PERFTWEAKS=1
PFAFFINITY="32:1 33:2 26:f"
which was the key change...
cheers!
1 Like
A couple followup points:
-
Packet steering might make sense in one particular case - using only the onboard gigabit port and VLANning it into WAN and LAN. Having 5 transmit queues available to the Broadcom driver would likely make steering make sense there (but I have not tested such a configuration). Note to testers: You won't see any payoff with iperf. Queue hashing is done by IP/port modulo queue slot, so unless you have at least 5 separate network streams going, you won't see any potential benefit...this is a real-world test scenario, not lab-based.
-
I genuinely believe the business of Realtek (RTL8152/UE300) vs. Asix (AX88179) is apocryphal with no real benefit of one over the other. I never did any heavy testing, but all of my early testing/dev work was on Asix (Amazon's variant, specifically), and I never noted any unusual performance characteristics or issues. My production setup is on UE300, but I may go back and run a week or two on Asix just to get a better real-world feel for this.
-
I was stunned at how easily GPIO-throttled cooling works. See this post for details:
4 Likes
@anon50098793 I read post 642. In the utilities folder there are 2 nicmove scripts, 000-nicmove and 000-nicmove-w-macaddr.
Which one should I use? Do I have to do anything more than adding macmatch and downloading to /etc/hotplug.d/net/?
On the performance side, had no issues getting 350mb through the base setup with a USB dongle to WAN and ETH0 to the test machine.
1 Like
you could try either... the key is that you'll need to move BOTH interfaces to something free...
this may be tricky... as applying these settings may lock you out... best to copy/backup the /etc/config/network original... ( preferrably on a pc that can mount ext4 )
then switch the ifnames for wan and lan to whatever the new names are... ( eth0 > nic0, eth1 > nic1 )... then reboot and cross your fingers...
any other references in your config will need to be altered too... ( /etc/config/luci_statistics?, /etc/config/sqm? etc. etc.)
nope... that's pretty much correct...
just macmatch and ifname (new ifname)@/etc/config/network>interface/s
ACME POSSIBLE INADVERTENT and NONFUNCTIONAL(when disabled) CRONTAB ENTRY
verbage
Just noticed a fairly benign bug... albeit 'of-note' re: acme... in that it seems to have inserted itself within my crontab even though it has never been enabled ( does not actually do anything... but i'd prefer to it didn't add itself to cron if it's not enabled )
Steps to mitigate this (workaround) have been implemented for releases over 2.9.17-109+ ...
Users of acme (service) may wish to ensure that 'acme' is in the list of your ENABLEDSERVICES at/root/wrt.ini before the next upgrade (then double check your cron if needed after upgrade &&|| dmesg | grep acme)
Users who don't use acme can comment out the offending line (if present) in /etc/crontabs/root or luci > scheduled-tasks;
#0 0 * * * /etc/init.d/acme start
then restart the cron service... (or just ignore it as it seems to do nothing and will be taken care of in the next update)
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...