size is also very different i think smaller one is the top one.
1 Like
yes... in the top one... I exclude quite alot of build specific metadata...
(the one goal is to also make it compatible with a typical official install if someone wants to migrate to an official image)
during an upgrade... I actually use the typical (luci) one... but during upgrade I fixup the PARTUUID if needed...
unlike official builds... to support usbboot
- my factory images have PARTUUIDs from the date of creation
- this PARTUUID is retained over sysupgrade
blkid $(findmnt /)
/dev/mmcblk0p2: LABEL="rootfs" ... PARTUUID="02070430-02"
my current system was originally installed in feb: 0207
1 Like
I went and tried all of these - running the perftweaks script made my performance more stable(thanks!) but the top speed is still limited to 38mbps. I've gone back to the old version of the firmware for now(r16707), and my speed has doubled back to the old one of around 75mbps...
1 Like
thats very interesting ( thanks for getting back )...
well... my immediate next assumption is that 'openvpn' itself may be an issue... but given few commits... and absence of any/many forum posts regarding this we can pretty much rule that out...
r16707 may have older dts/bootcode... but that probably only starts to become relevant in the context of additional connected hardware? (there were/is a few rpi kernel related patches over this time... which might also have an influence? particularly if mismatched eeprom is present?)
in this case... it seems the immediate course of action is;
- what you have done (openvpn users revert)
- wait for any/more kernel patches to filter through
- wait for other users to debug/dig into the lower levels...
out of interest... what is your current eeprom version? (and usb dongle brand/driver)
vcgencmd returns:
Sep 3 2020 13:11:43
version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
timestamp 1599135103
update-time 0
capabilities 0x00000000
I do have a USB ethernet adapter connected, but I assume it's pretty standard to be able to use the pi as a router.
I'm using this adapter. I'll try and see which drivers it has.
1 Like
rpi-support.sh | grep 'eth'
Thanks:
############### eth0 [ok] bcmgenet yes 1000Mb/s
############### eth1 [ok] r8152 yes 1000Mb/s
Update- that was the output from the old firmware. The new one seems to have an extra entry:
############### eth0 [ok] bcmgenet yes 1000Mb/s
############### eth1 [ok] r8152 yes 1000Mb/s
############### ifb4eth0 [ok]
1 Like
this suggests sqm is enabling itself on the newer firmware (or there is just difference between when the commands were run and such)
all this really means is you would be best to test with sqm off on the newer firmware minimum... (as an easy way to exclude it causing issues)...
general-outloud-thoughts-before-I-found-the-bug
if you have not enabled it... or it is not in your ENABLEDSERVICES... it should not really have started itself... but there are a quite a few variables to factor in... (will likely need to try to reproduce your upgrade method to see whats going on if this is the case)
i did consider sqm for a while... but as it wasn't mentioned didn't see too much relevance... I believe there is at least one other post in the thread about someone who turned on sqm which has defaults of around 50Mb/s and it choked their connection...
edit: looks like I just found a bug (thankyou! 
)... it would not have been noticable for users who use sqm (most)...
pretty curious when it was introduced as don't remember touching that area for more than 6 months...
thankfully it's a simple isolated 'sqm enable' if/or logic stuff up... (and not related to the larger service enable logic)...
sorry for the hassle and thanks for helping me to find it...
thinking back this makes alot of sense... why there have not been 20 posts to date "i upgraded but sqm is not running anymore" ( i believe @neil1 did bring this up ages ago... but it did not click fully )
NOTE: as a result of a quick fix for this... new users will no longer get sqm in luci statistics (auto-setup for you)
2 Likes
testing release build uploaded... it is possible to change your tracking flavour to test (although not really super beneficial to most at this stage);
UPGRADEsFLAVOUR="release"
then click refresh in the top (updatecheck) bar...
initial testing is solid... performance is comparable to master...
Using the RC3 image still, built around early June and my interrupts after 3 weeks uptime is only 445. So the disparity here is strange to say the least. Using USB3 adapter with RTL8192 driver, 8193 (?) chipset. Some generic one that I've not seen need to replace.
CPU0 CPU1 CPU2 CPU3
3: 611964753 163852935 110980261 136198880 GICv2 30 Level arch_timer
11: 445 0 0 0 GICv2 65 Level fe00b880.mailbox
14: 2 0 0 0 GICv2 153 Level uart-pl011
15: 1 0 0 0 GICv2 105 Level fe980000.usb, fe980000.usb, dwc2_hsotg:usb3
19: 7349927 0 0 0 GICv2 114 Level DMA IRQ
26: 1 0 0 0 GICv2 66 Level VCHIQ doorbell
27: 340663198 0 0 0 GICv2 158 Level mmc1, mmc0
33: 692420586 0 0 0 GICv2 189 Level eth0
34: 360470277 0 0 0 GICv2 190 Level eth0
40: 0 0 0 0 GICv2 175 Level PCIe PME, aerdrv
41: 1143757457 0 0 0 BRCM STB PCIe MSI 524288 Edge xhci_hcd
IPI0: 27170194 373014866 835535997 371701380 Rescheduling interrupts
IPI1: 693 1782 1140 1500 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 58 21 107 19 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0
1 Like
ok... could be something with my led.dtbo or i2c or other custom overlays... may need to check with someone running fairly stock (forgot to check while testing rc4)... ( dont think there is a performance hit... so looking like a result of some feature being enabled )
1 Like
My config.txt changes are as follows, for reference:
force_turbo=1
arm_freq=1600
dtoverlay=dwc2
dtoverlay=act-led
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off
dtparam=eth_led0=4
dtparam=eth_led1=4
dtoverlay=disable-bt
dtparam=miniuart-bt=off
dtparam=audio=off
dtparam=eee=off
dtparam=sd_poll_once=on
There are other software level changes but I'm not sure as to the degree to which they'd influence this mailbox interrupt feature. Moreover, I'm not even aware what it actually pertains to in terms of functionality.
1 Like
me neither really... my laymans guess is "driver(brcm) low level messaging"... which probably fingers...
dtoverlay=disable-wifi
which results in no mmc1 in proc/interrupts
(or blob/fw vs kernel mailbox process feature mismatch or something)
1 Like
Is there a way to check pi4 power usage? in OpenWrt
Actually, I am thinking to get a UPS for my modem, switch, pi4 and wifi AP
1 Like
you mean like gross mA / watts per interval or something right?...
need to think about that... there are alot of things you can check... but gross watts i'm not so sure about...
thankfully for these it's pretty predictable... 1.5A(idle-ish) <3.5A(peak-ish)>
over longer time you are better off with a kilowatt or a usbc power meter or something...
o'ok... a UPS with a gross 10A (normal PC) rating would be ok... anything over short intervals 10-20mins will get large or costly tho'...
1 Like
Been toying with the Rpi4 4GB more lately and trying this build experimentally, thanks for doing this. I also plan on doing my own and comparing Master / 21.02 branches. Just have a couple questions -
Is there is a clear preference to Master vs. 21.02 right now? Also, is there a preference on 32-bit vs. 64-bit options on Pi4? I see both are available on the official OpenWrt firmware selector too.
1 Like
cant comment on 32bit as i've never tried it... hopefully someone else might chime in on that... i think the main benefit there might be binary / sdcard interoperability with rpi3 et. al. if you have a bit of an ecosystem going...
for master/21.02 my answer would probably vary...
- for a brand new user definitely 21.02
- for anyone on this build or happy with their own imagebuilder etc. etc. i'm favoring master a little more... but it can get volatile from week to week if you are building your own... there is not really that much in it...
(master buildbot sync and dependency issues plaging imagebuilder have most been a thing of the past for three weeks)
edit: that said... now is not the optimum time to be using imagebuilder on master as the phase separation is out to 3 days again with rc4 building
stg1:20210804-0056 stg2:20210801-0607 r17249-4baf47b9a8 phaseout
1 Like
If you haven't tried 32-bit then sounds like 64-bit is stable and the way to go, so that's where I'll start with trying the official builds too. Thanks again that's really helpful. Got your build and just downloaded 64-bit 21.02-rc4 to test out too.
1 Like
glad you are doing that... technically should do the same once in a while... don't really have time...
(mostly just to pickup in some minor config file changes... as I build from imagebuilder performance wise you wont/should not see much difference... perhaps slighly lower latency)
2 Likes
so... as part of wanting to test wireguard... i've been able to fire up openvpn today... its probably been written elsewhere... but...
for a general (oversimplified) baseline... what im seeing is...
-bursty single cpu bounding
-max throughput of around 270-325Mb/s based on single core capacity...
(random calculation vpn is pulling 25ish Mb/s from the states... @ 10% cpu0 bursts...) if I were pushing it to those upper limits i'd probably try pinning it to CPU2(3)...
1 Like