hello everyone i ordered a belkin rt3200 for my friend if i understand correctly, ubi flash method has changed, i have putty and winscp software, has it become difficult or not i followed the thread about blocks but do not understand the interest in general I flash via belkin software ubi recovery then Snapshot upgrade ubi thank you
Not quite.
You flash the "recovery-installer". Not the "recovery".
openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb
Then, when it boots up the recovery instance of OpenWrt, you use that OpenWrt to sysupgrade to the normal image.
openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb
See advice at
Note also the advice about newer Linksys firmwares rejecting the images...
1 Like
I tried again with Irqbalance enabled but made no difference I think. I also enabled Packet Steering, still quite slow OpenVPN speed on 5Ghz.
Tried with WireGuard 291Mbps down (out of 300Mbps) on ethernet and 273Mbps over WiFi (5Ghz). 
2 Likes
The 5ghz radio being a little weak is really the only downside to these routers, maybe it's being affected by distance?
Would be surprised if it's the distance. Tested at 2 meter (also at 40cm). Same distance as the ASUS RT-AC86U. I kept the distance constant, then turned OpenVPN on and off to observe the difference in speedtest. Of course it's not 100% reliable to test this way, since VPN server load can fluctuate. But was surprised to see OpenVPN speed over 5Ghz would be so much worse... Now that I've seen WireGuard speeds I feel I should stick to that XD
1 Like
I'm having an issue where the router goes into initramfs recovery mode and I can't get out of it. I tried power cycling, pressing the reset button, and re-flashing but it boots back to recovery mode. I managed to get out of recovery mode by pressing the reset button until the light turned orange and flashing the latest images from github. This has happened 2 times now.
Is there a way to get out of recovery mode without resetting my configurations?
Probably the kernel has crashed and the device now boots into recovery to gain your attention:
1 Like
Thanks for this answer. That is reassuring that log writes will not contribute to wear by default.
But what about regularly updating to the latest snapshot? Presumably that will contribute to wear? Should we be concerned and try to reduce update frequency?
1 Like
Well, I am not sure how that concern applies specifically to this thread's E8450 that has the UBI build that already mitigates wear-leveling. Any reason why you are asking this in the router-specific thread? The flash-wear problematics is generic, but this UBI scheme from Daniel makes E8450 as one of the least risky routers in that sense.
It is upto you how often you sysupgrade, but a few sysupgrades every now and then are not a serious risk.
Just as a side note, I have so far sysupgraded my R7800 a total of 1137 times since November 2016. No problems so far.
And 78 sysupgrades so far with my E8450/RT3200 since June 2021. No problems so far.
1 Like
Thanks. I only thought it might be helpful to have a sense of how many flashes vs expected max no. flash writes for this hardware to help users know whether flashing every other day is a bad idea for their use case.
1 Like
You can't answer that without reading the data sheet of the used flash chips for each individual model/ hardware revision. Once you have that data, you'd need to do a statistic evaluation of medium firmware sizes, other writes, amount of sudden power losses and read accesses relative to caching effectiveness (NAND also ages by reading, not just writing), taking the expected operating temperatures into account...
Or you could apply common sense.
Logging to flash (constant writes), bad. Pulling the power cord daily (e.g. via a classic timer), bad.
'Normal' operations should work for reasonably long - and if your device fails, there's no telling why (not that it makes much of a difference either). Just avoid active abuse if your device.
--
...and statistics don't mean anything for quantities if one (or two, three).
4 Likes
Hello friends, I took advantage of the relative quiet first day of the new year to do some performance tests with my RT3200 on a symmetrical 1Gbps best-effort FTTB connection. The client is a desktop computer connected via WLAN (Intel AX210) on channel 100 (160Mhz width) and I used a relatively close performance testing web site powered by nperf (11 hops within ~ 4ms response time). I also have other IoT devices currently connected including a Google Nest Hub streaming a radio station which manifested no interruption during tests and various settings changes 
For SQM I used fq_codel with simple (cake with piece_of_cake gave poorer results) and I have packet steering enabled.
Here are the results for download (maximum observed values over a series of attempts):
- no offloading, no SQM -> 810 Mbps with 90% CPU utilization.
- sw offloading, no SQM -> 850 Mbps with 70% CPU utilization (this likely seems the provider limit).
- hw offloading, no SQM -> 830 Mbps with 80% CPU utilization. Yeap, this is what it is, speed approx. the same but worse CPU. I think this hw path is only partial implemented, maybe Daniel or Felix can give us the current status and plans.
- no offloading, SQM -> 520 Mbps with 60% CPU utilization.
- sw offloading, SQM -> 800 Mbps with 70% CPU utilization.
- hw offloading, SQM -> 800 Mbps with 80% CPU utilization.
For uploading I did not observe much difference, results showed max 700 Mbps with 60% CPU utilization.
So I noticed that SQM decrease the speed a little while keeping the CPU at the same rate but the small difference with offloading is most likely caused by the actual internet speed fluctuation as SQM is not functioning when offloading is used.
LE: I made some modifications: disabled sqm from startup and changed governor to ondemand with min freq = 437.5 as instructed by Daniel (used schedutil before). And... I can now reach 870Mbps with only 60% CPU (and sw offloading)...
2 Likes
thanks for test with line gigabit
it's very good result
i suggere if you want (can) install script of my mate elan better than sqm
best script for example gaming ... 
i will flash a new belkin router with this version
I have never done this step is it compulsory?
1 Like
The complete backup is only needed to be extra safe when it comes to reverting to stock firmware. If you are planning to just use OpenWrt, it is not needed.
The installer also makes a minimal backup containing only the bootchain and device-specific data which ends up in boot_backup UBI volume. This is enough to revert if you add serial console access and download the firmware file from the vendor's website.
2 Likes
First of all, in the moment that you switch on either software fast path or hardware flow offloading, SQM won't have any effect any more. This is simply because packets are then handled by offloading and no longer go all the way through the packet scheduler. Hence there is no need to test offloading+SQM as what you are effectively testing is then just the performance of the offloading path and SQM not being involved.
Generally flow offloading will improve performance if the router performs firewall and/or NAT operations and currently only work well when routing only IPv4 traffic (for IPv6 see https://github.com/openwrt/openwrt/pull/4849).
Regarding wifi access point (or WDS client) operation there are other offloading paths on layer 2 which will be used independently (Ethernet Decapsulation offloading which is already supported and Wireless Ethernet Dispatch, see mt76 wed tree and recent commit ).
Probably they are both needed to reduce CPU load for WiFi to a level that full Gigabit speed can be handled when operating as a router at the same time.
Regarding QoS: Did you try qosify instead of sqm-scripts?
2 Likes
Regarding the usage of SQM with offloading, I just tested it because of contradictory informations found on this forum, myself I am not too much into low-latency internet games. But it seems the differences could come from the usage of IPv4 or IPv6, because it seems even if the site is the same, it used sometimes one or another. I will make soon some new tests keeping eye on these aspects. Thanks.
I'm not sure how to tell exactly if the test is using IPv4 or IPv6, the only difference is that one time is showing only the public IPv4 router address and another time is showing that and the client computer IPv6 public address. But results are the same (so I think it tests only IPv4) and also shows that SQM is not affecting the results, but the cause is the effective internet speed. I will test qosify next.
BTW, if you want me to make some "unprofessional" real-case tests with these improvements (of course if they are ready for usage), I can contribute because I am already building my own firmware for the router. I suppose I only need just a little help with correct procedure or git commands on how to replace (and revert) the mt76 openwrt master branch with the "wed" mt76 branch.
I was planning to turn off the router every night, to save power. But don't want to break the router... Would that really wear out the router that much quicker?
Also I tried the luci-app-advanced-reboot package, which "provides Web UI to shut down (power off) your device." But instead of shut down, the router reboots...
One goal of creating UBI layout was to have the router boot up in a way that does not involve any write operation on the flash. Ie. other than the stock layout which uses a block on flash to indicate if the previous boot has succeeded (and naturally this block has a limited number of writes, supposedly somewhere in the thousands, but that's statistics...), the UBI layout uses PSTORE/ramoops for it's dual-boot decision.
Hence, when using the UBI layout, a daily reboot should not reduce the lifetime of the device in any significant way.
PS: Looking at the board wearing my expected-life-time lenses, I suspect the electrolyte capacitors surrounded by the heatsink (and hence always nicely heated) would be the first components to fail. And like for every electronic device, keeping it in a dry and well-ventilated place with constant moderate temperature around 15-18 deg Celsius is ideal. To reduce heat even more at the cost of some (hardly noticeable) performance losses it's advisable to enable CPU frequency scaling which reportedly reduced the temperature by a few degrees. I have added these lines to my /etc/rc.local to setup the ondemand scaling governor by default:
echo 437500 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo "ondemand" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Setting the minimum frequency is needed as when running on the lowest otherwise (wrongly) defined operating point the device fails to reboot (stuck in memory calibartion in bl2, the only remaining closed-source part...).
According to one MediaTek developer, the MT7622 is actually not specified to run at any other frequency than the maxium of 1.35GHz. However, as other MediaTek employees have added the more power-saving lower operating points and all of the apart from the (obviously wrong) lowest one work, I'm using 437.5MHz@1.0V as lowest operating point.
10 Likes
Cool! Thanks for the tips 
Does that include turning it off daily by 'pulling the plug'?
1 Like