Belkin RT3200/Linksys E8450 WiFi AX discussion

Not at this point. Loading FIP into RAM is the first thing which is done after initializing the DDR RAM. Everything before happens inside the SoC's SRAM.

Maybe I have to clarify my thesis of what could have happened:

  1. User reboots the device, for what ever reason.
  2. Instead of actually rebooting the device gets stuck in DDR calibration due to too low core voltage (0.9V instead of 1.0V or 1.1V).
  3. User doesn't notice or decides to wait what happens and lets the device sit there in this state for a while.
  4. After a longer amount of time, the users tries to power cycle, then decides to wire up serial console and it shows what we are seeing now.

My hypothesis is that keeping the device at the 3rd step above for a longer time might break the RAM.

1 Like

So, setting the min frequency of 600MHz or more should be desirable right now?

I had to set it to 600 or otherwise, the router sometimes won't boot up. I also have it set up to reboot eveyday.

Cheers!

In that case I would just set userspace with max. frequency or performance governor.

1 Like

Not sure about tje CPU Frequency thing. I just flashed it fresh in like October, and I am pretty sure at that point that the fix for that was already in the mainline builds, so I never did it.

When my router bit the dust, it had been powered up for like 20 days, powered off a 12 volt POE power splitter. I just pulled the plug instead of flipping g the switch, didn’t really think anything of it to do that, since everything should have been in non volatile memory.

Clearly that was not the case.

I have not had a chance to get back to trying to fix it unfortunately.

Is this still the bees knees for a value AX router that supports Openwrt? I've been really pleased with the R6350/R6850 (same hardware) and wondered if this was some kind of upgrade. I do not have any AX devices; my clients top out at AC.

For $40-$50 shipped off ebay in the U.S.? I'd say emphatically: heck yes! If price in your local area is pushing toward double that, I think I would spend a little more on a quad core Filogic device with external antennas instead.

FWIW w.r.t. current discussion in this thread, I've been running an RT3200 as a dumb AP for many months with min frequency set to 600 MHz and not experienced any issues - granted I'm just one data point.

2 Likes

Yeah my other rt3200 has been running just fine I think the uptime is like 80 days which is basically since I got it. Works just fine!

1 Like

It depends what you would like to get from an upgrade.
R6850: https://openwrt.org/toh/netgear/r6350
MT7621: 880 MHz MIPS dual core, b/g/n 2.4 GHz wireless integrated
128 MB flash, 128 MB RAM
MT7615 a/n/ac 5 GHz interface

E8450/RT3200: https://openwrt.org/toh/linksys/e8450
MT7622: 1.35 GHz ARMv8 dual core, b/g/n 2.4 GHz wireless integrated
128 MB flash, 512 MB RAM
MT7915 a/n/ac/ax 5 GHz interface

If you only have AC wifi devices, you already get line speed and CPU power and RAM of your R6850 is enough for your use case I do not see a benefit in upgrading.

If your application benefits from more CPU power, more RAM or you need faster routing, firewalling or more power for SQM then maybe it could be a benefit.

AX will be a benefit with AX capable stations. I would not upgrade only to upgrade. You should get a benefit in your applications.

Lot of wisdom in that short sentence.

If I went back to 200/10 Mbps ISP service, a MT7621 based ER-X gateway stuffed in a telecom cabinet and struggling to shape much over 100 Mbps with CAKE, and EA8500 dumb AP's connected with wired back haul on each floor of the house...I think I'd barely notice the downgrade beyond rare occasions downloading large files and working with same on home NAS.

Now I'm stuck with a NanoPi R4S gateway easily shaping 500/20 ISP service with CAKE, a GS308T switch, AX dumb AP's (Reyee RG E5 and RT3200) and a less WiFi performant spare DL-WRX36 experiment stored in a closet. I'm down money and time, but on the up side I see a large benefit every time I run a speed test :wink: , I get close to half Gig WiFi (on the down link anyway; uplink is about half that) throughout the house and it's an amusing hobby.

1 Like

I agree, as a hobby to play with network hardware and software upgrading a OpenWrt router may be fun.

If router upgrades should produce an application benefit and a forum member asks whether a device is an upgrade for AC devices I can reply that it depends on the application and uplink connection speed.

Simple spec comparison as above:

E8450/RT3200: https://openwrt.org/toh/linksys/e8450
MT7622: 1.35 GHz ARMv8 dual core, b/g/n 2.4 GHz wireless integrated
MT7915 a/n/ac/ax 5 GHz interface
128 MB flash, 512 MB RAM
4 ports 1GbE, 1G WAN

Next gen GL-MT6000: https://openwrt.org/toh/hwdata/gl.inet/gl.inet_gl-mt6000
MT7986: 2.0 GHz ARMv8 quad core, b/g/n/ax 2.4 GHz and a/n/ac/ax 5 GHz wireless integrated
1 GB flash, 1 GB RAM
4 ports 1GbE, 2x 2.5 GbE LAN or WAN

It depends if the raw upgrade in SoC power, more RAM, flash and 2.5 Gbps interfaces are needed. For some use cases the benefit may be huge, other use cases will not see a benefit.

Or more simple: already got line speed from your router in your desired configuration with up to date OpenWrt stable version? Fine. No need to upgrade at this time.

2 Likes

I've been curious about thermals for the various governors for a couple years, finally remembered to try something out this morning.

With schedutil idling at 438 MHz, temps hover at 49.8-50.6 up and down, but somewhere inside that range.

With performance idling at 1350 MHz for about a half hour, temps are only marginally higher, I've seen 51.5 up to 52.4. I consider this to be approximately noise.

Test tools, add this to /etc/profile so it's always available:

stats() {
    echo -n "$(date -Is) "
    awk '{printf "%5.0f MHz ", $1/1000}' /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
    awk '{printf "%5.1f C ", $1/1000}' /sys/class/thermal/thermal_zone*/temp
    echo ''
}

Then run it occasionally

$ stats
2023-12-19T14:23:27-07:00  1350 MHz  1350 MHz  51.4 C

Edit:
Just logged into my sister's RT3200 one time zone east, it's running schedutil:

2023-12-19T15:34:55 MST   438 MHz   438 MHz  50.7 C

Ambient in my SoCal "lab" is 25 C, not sure what her's is (probably colder, as it's real winter up in the Colorado Rockies).

5 Likes

Mine's at 57 C, but my ambient temp is like 30 C.

Here's my output:

2023-12-20T21:36:30-04:00   600 MHz   600 MHz  57.5 C

I'm using ondemand (default) with 600MHz min frequency.

Do you think schedutil achieves lower temps?

It sure seems like temps are almost independent of the scheduler. If I load things up (run an iperf through it, say), then the temps go up, but it looks like high idle clocks don't cause appreciable increase in temps.

Someone with a good setup for bufferbloat testing should try some experiments with ondemand or schedutil vs performance and see if there's any detectable latency difference.

1 Like

If anyone would like to try this then rather than constant load I’d recommend triggering a sawtooth - something like two seconds of saturation followed by two or more seconds of nothing. And for over sixty seconds. Or something like that. I’m thinking that we don’t want just full and constant load because we don’t want to allow the scheduler to just ramp up and stay ramped up; we want to test the impulse response.

Nevertheless my gut is that it will be hard to show any significant difference even on a connection like @hnyman’s with less than 5ms idle latency. I might be wrong and, in any case, it’d be nice to have some concrete data showing the impact of scheduler on cake on the forum though.

@moeller0 may have better or further ideas for testing the impact of the scheduler on cake.

3 Likes

Hmm, rethinking this, bufferbloat and/or throughput tests are probably completely wrong for this. How about invoking a router-based workload, do an nslookup/dig every few second so that we can induce the sawtooth CPU requirement. Do this on a quiescent line (so maybe isolate the router on a subnet -- hey, just like I already have!).

(Yo, mods! This is not particularly RT3200-specific, should this be a new thread "Latency testing with different kernel schedulers"? If so, please split it out maybe at @lynx's post above...)

1 Like

Had the same experience twice recently, except that it took a lot more time and power cycles to see LED activity and boot up the RT3200 again. This after about 1½ months without any issues, similar to what happened to this user that couldn't/can't boot.

I added echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor to local startup for now after reading some of this thread. Haven't rebooted since, but may test later. Is there anything else that could be done to prevent this issue?

1 Like

My router bit the dust today after 4 weeks. I flashed in late November. It worked fine until a couple days ago when the wan port apparently dropped, but wifi and ethernet were fine. I thought little of it and wasn't using this as my primary router. Today I issued a reboot command via ssh and it didn't come back up. Power cycling hasn't worked so far.

2 Likes

Which version of OpenWrt did you run on the RT3200?

1 Like

Update: rebooted a couple of times and still had to do 2-4 power cycles for it to boot.

It's an e8450. I downloaded the ubi layout converter v1.0.3 (openwrt-23.05.0-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb) on December 1. The router had 1.0.x factory firmware out of the box, and I didn't upgrade it, so I was able to flash without any trouble.

Firmware was downloaded from: https://downloads.openwrt.org/releases/23.05.0/targets/mediatek/mt7622/openwrt-23.05.0-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb

1 Like