4776

Do we know the shaping limit when using CAKE for this router?

4777

I have thank the developers! I had a bricked OKD Belkin RT3200 since last December in the state of "ERROR: BL2: Failed to load image id 5 (-2)". I did the process of post #4550 and the router was revived just using serial port. After, I flashed the 23.05.3.

1 Like
4778

The RT3200 is reported to handle around half a Gig SQM on CAKE and approaching full Gig line rate on fq_codel here. I've never used mine as a gateway, so I can't speak from personal experience, but if memory serves I've seen more than one report putting the MT7622 in this ball park.

Another 500 Mbps CAKE data point on an A53 ARM CPU core running at 1.2-1.3 GHz is the R2S. Granted, the R2S has four cores, but CAKE runs on just one of them.

1 Like
4779

I’m a bit suspicious of these reports. If I set the governor to performance and run a stress test I can easily see sirq move above 80%. My stress test is downloading a Debian torrent from a Wifi machine while running a concurrent speedtest from a wired machine.

If I drop to besteffort flowblind no-split-gso I still see in excess of 50% sirq running the same stress test.

I guess it depends on what and how you determine “proof”. A sequential speedtest isn’t enough IMO.

Here are my settings that currently push above 80% with a stress test:

qdisc cake 802d: dev wan root refcnt 2 bandwidth 25Mbit diffserv3 dual-srchost nat wash no-ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64

qdisc cake 802e: dev ifb4wan root refcnt 2 bandwidth 174Mbit besteffort dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 18 mpu 64

2 Likes
4780

There are very good reasons to use software QoS, such as fairness in bandwidth distribution among many users (with SFQ) and avoidance of buffer-bloat which neither hw nor sw flow offloading will give you. The bigger the difference between LAN and WAN bandwidth, the more you will suffer from buffer bloat when using offloading paths (and buffer bloat may happen even in the modem or upstream router, not in the OpenWrt device we have control over).

1 Like
4781

I'm on latest installer v 1.1.1 but i want to roll back to v 1.0.3 and 5.x kernel
Should i boot to recovery and flash installer 1.0.3 and in new installer, flash version 23.05.3?
Is it right procedure to follow?

4782

without serial - best bet is to restore oem firmware if you can, then use V1.0.3 installer

4783

Rolling back to pre-v1.1.x is non-trivial. First of all, you will need your backups of all MTD partitions and the serial console connected. Then use mtk_uartboot and recovery image of 23.05.x release to write each MTD partition of your backup to get back to stock firmware. Then run v1.0.3 installer and subsequently install 23.05.x sysupgrade.

4 Likes
4784

I would like to run a current snapshot on my RT3200 that I built with the 6.6 kernel.
According to this, I need to:

  1. Change the scaling_governor to performance to prevent a bl2 error
  2. Force flash the wrt-ubi-installer version 1.1.1

Is that all and what image from that tagged version should be force flashed? The *-installer.itb or the *-installer_signed.itb? Also, can all these steps be done from luci? I do not have access to the serial port.

1 Like
4785

@quarky I realize this is a slightly older post, but I agree with @jkdf2. Several weeks back when I was doing a lot of heavy troubleshooting of this issue, I suspected the same about residual charges. While I certainly don't recommend this to anyone who isn't electronically savvy, I did safely discharge all the caps I could identify. I checked the voltage at several points on the PCB and confirmed residual charge was zero.

Plugged it back in, hit the power switch, and no boot. :neutral_face:

2 Likes
4786

try this:

4787

Thanks for the link, that's a good data point.

I reread my post and realized I posted confusing test results. This should be clearer:

200M internet
No SQM:   205 down, 108ms latency
Cake:     201 down, 3ms latency

300M internet upgrade
No SQM:   306 down, 85ms latency
Cake:     270 down, 4ms latency    Most bandwidth with low latency
Cake:     289 down, 30ms latency   Most bandwidth
fq_codel: 296 down, 2ms latency

At 200M Cake took only 2% bandwidth to achieve low latency, while at 300M it ate 10% bandwidth. That link showing the RT3200 doing 500Mbps on a 1G internet link means Cake sacrificed 50% bandwidth!

I don't think it's as simple as saying this router can shape 500Mbps using Cake. If I can find the time for more detailed tests I'll start a new thread. Thanks all.

4788

I have not, thanks for the tip. I'll dig into this in the coming week and probably start a new thread.

4789

I’ve learned a lot just by searching this forum. Most if not all of your questions have been asked and answered many times I’m guessing. I also sought out the man pages when looking for additional info/clarification. man tc-cake and man tc-fq_codel are the two most relevent.

Edit:
And don't forget the docs:
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details

4790

I guess it is a matter of perspective. I wouldn't say CAKE sacrificed 50% bandwidth. The RT3200 just ran out of CPU to process throughput with CAKE at around 500 Mbps. A faster CPU can process full Gigabit with CAKE, for example an A72 core at ~2 GHz on a NanoPi R4s or Raspberry Pi 4B, or a fast x86 target.

1 Like
4791

It helps to keep in mind wrt a dual core all-in-one router that the results of a sequential speedtest over a wired connection will produce vastly different numbers than a concurrent speedtest over Wi-Fi.

500Mbps one way via a wired connection is likely. 300Mbps up and down over Wi-Fi with WPA3 is unlikely.

1 Like
4792

Good point. If it were even possible, it would take some clever irqbalance assignments to reserve an entire core on a dual core all-in-one for CAKE, and it may not possible at all, or not without hurting performance elsewhere (e.g., WiFi).

dan3 looks like he may be running out of CPU ~270 Mbps if the CPU has more to handle (e.g., WiFi) than just CAKE and routing. Sounds like a justification to upgrade to a quad A53 core all-in-one clocking closer to 2 GHz, or abandon the all-in-one concept for separate router and AP's.

1 Like
4793

In my case I have an asymetric connection with RX being under the most stress wrt Cake.

I don’t use irqbalance (I don’t want the added overhead) but have moved eth0 rx to CPU1 with the following in rc.local

# Move eth rx to second cpu

irq1=$(grep "1b100000\.ethernet" /proc/interrupts | cut -d: -f1 | tail -1 | xargs)

echo 2 > "/proc/irq/$irq1/smp_affinity"
4794

The refrigerator technique seems to have lost its ability to help. Can't get a blue LED.

Ordered "waveshare Industrial USB to TTL Converter with Original FT232RNL Onboard and Multi Protection Circuits"

Some details about my RT3200:

  • Running snapshot build kernel 6.6
  • Running v1.1.1 ubi installer
  • Performance governor set
  • Router is in 802.11s, nothing connected to it but the barrel adapter.
4795

There must be some explanation as to why the increased number of OKD-caused bricks with the more recent installers. We have a fair number of smart individuals here and quite a lot of data.

How about as a step forward, we create a comprehensive list of the possible causes of OKD?

I can only think of:

  • moving FIP to UBI; and

  • update to ARM Trusted Firmware A v2.9(release) from v2.4.

Can others please help expand this to a full set?

How likely is it that this is simply a bug introduced by ARM Trusted Firmware A v2.9(release)?

Does anything jump out at anyone from the following changelog:

https://trustedfirmware-a.readthedocs.io/en/v2.9/change-log.html

I see:

  • Enabled Cortex-A53 erratum 1530924
  • Enable workaround for Cortex-A53 erratum 1530924
  • Remove Cortex-A53 compilation
  • Arm Cortex-A53
  • Removed support for Arm’s Cortex-A53
  • cortex-a53: Workaround for erratum 819472
  • cortex-a53: Workaround for erratum 824069
  • cortex-a53: Workaround for erratum 827319
  • Check presence of fix for errata 843419 in Cortex-A53
  • Check presence of fix for errata 835769 in Cortex-A53
  • Added support for Arm Cortex-A53/57/72 MPCore processors
  • Applied errata workaround for Arm Cortex-A53: 855873

Might one of these be relevant like this one:

image
image989×758 106 KB

They can be looked up here:

https://documentation-service.arm.com/static/5fa29fddb209f547eebd361d?token=

2 Likes