Did you try to turn it off?
Yes; no noticeable difference (I also tried hardware offloading, but I didn't expect that to change anything, and it didn't)
Taking a look at CPU use by core with htop (turn on the clock speed display option also) during a speed test might provide some clues?
I just have irqbalance, packet steering and software offload enabled on my R4S - nothing fancy setting IRQ's manually. I only have 400/20 ISP service, but no issues getting all 20 on upload with CAKE.
Hardware offloading isn't supported on this hardware, and Software offloading doesn't work with SQM or any QoS so just leave them both unchecked.
I would get rid of all those settings and start simple with only enabling SQM, cake, poc, 550000, 58000 and see if it works. Maybe also try fq_codel. Then after testing a simple setup add the options to see if it changes.
1 Like
htop was a good idea... but it didn't seem to show me anything useful. CPUs 2 and 4 were much more heavily loaded during download (aka 500Mbps) and relatively lightly (but still the most of all of them) during upload. I didn't see anything that looked like a bottleneck or anything maxing out :-/
I've turned off software offloading, and went back to the most basic parameters. Still can't seem to get above 11Mbps.
With fq_codel + simple, I can hit 510/50, interestingly.
Edit: I'm not sure fq_codel actually worked. I saw this in the logs when selecting fq_codel:
Wed Aug 3 16:27:07 2022 daemon.err modprobe: failed to find a module named act_ipt
Wed Aug 3 16:27:07 2022 daemon.err modprobe: failed to find a module named sch_fq_codel
Wed Aug 3 16:27:07 2022 daemon.err modprobe: failed to find a module named act_ipt
Wed Aug 3 16:27:07 2022 daemon.err modprobe: failed to find a module named sch_fq_codel
Yea fq_codel looks broken, not sure why, I use Cake on my main router (WRT32X, 500 / 35 Mbit cable, SQM works perfect on rc6). Maybe do a clean install of the new rc6 and start fresh something seems wrong.
[OpenWrt 22.03.0-rc6 sixth release candidate]
Another option if you have time is to try a FriendlyWrt build (in their testing folder, it's based off OpenWrt 22.03-rc) they post every few weeks here, not sure what tweaks they might add for this hardware:
https://www.friendlyelec.com/index.php?route=information/information&information_id=7
For that I was saying to disable it. But if he says there’s no difference…I have no idea. On my 200/20 SQM works perfectly and waay better that the R7800. I have no lag.
@mikeage try to paste here the output of cat /etc/config/sqm
fq_codel is generally compiled in in openwrt. sqm-script's I thought didn't check for ipt anymore either (@tohojo) ? your problem is elsewhere... 
Perhaps in the ppoe decoding?
Responding to everyone:
The pppd process doesn't seem to be using any significant amount of CPU.
I feel like fact that it's only on the upload and not download is significant. If I set upload to 0, it looks fine. If I set it to something like 100000 (well above my theoretical maximum of 60000ish), it still stays at around 10Mb.
Here's my current config:
config queue 'eth0'
option download '550000'
option interface 'pppoe-wan'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option upload '58000'
option linklayer 'none'
option enabled '1'
If fq_codel is compiled in, that's good to know; truth is, I know it works, because it throttles the download as well. I was using cake / piece_of_cake before and I'd like to continue, but I suppose fq_codel + simple is probably better than nothing, right?
rc6 is probably a good idea, although as this is my main router, I need to wait until I have time to redo everything in case it goes south, so it's not going to happen today 
tc -s qdisc show during your upload or download might be revealing.
1 Like
I figured out the difference, between the two setups; the SD cards should be identical, but they are not. The older SD card has a slightly green circuit board, ~20MB/s slower sequential write speed and ~30MB/s sequential read speed. I tested if they are legitimate, via f3, and they both passed. Evidently, SanDisk released a new "version" and didn't change any of the specs or model details. I found a truly identical, older, SD card and have not encountered the reboot problem. It looks like you just have to play the SD card lottery, until you find one that works.
I'm not terribly familiar with what I'm looking at; this is during the upload part of the test. Can you tell me if you see anything interesting here?
qdisc noqueue 0: dev lo root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth0 root
Sent 83739557 bytes 303082 pkt (dropped 0, overlimits 0 requeues 5)
backlog 0b 0p requeues 5
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 83739557 bytes 303082 pkt (dropped 0, overlimits 0 requeues 5)
backlog 0b 0p requeues 5
maxpacket 1514 drop_overlimit 0 new_flow_count 13 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 2692895 bytes 7945 pkt (dropped 0, overlimits 0 requeues 3)
backlog 0b 0p requeues 3
maxpacket 1514 drop_overlimit 0 new_flow_count 48 ecn_mark 0
new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8005: dev pppoe-wan root refcnt 2 bandwidth 58Mbit besteffort triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0
Sent 25216644 bytes 208435 pkt (dropped 0, overlimits 10343 requeues 0)
backlog 0b 0p requeues 0
memory used: 100096b of 4Mb
capacity estimate: 58Mbit
min/max network layer size: 40 / 1492
min/max overhead-adjusted size: 40 / 1492
average network hdr offset: 0
Tin 0
thresh 58Mbit
target 5ms
interval 100ms
pk_delay 693us
av_delay 195us
sp_delay 5us
backlog 0b
pkts 208435
bytes 25216644
way_inds 49997
way_miss 226
way_cols 0
drops 0
marks 0
ack_drop 0
sp_flows 3
bk_flows 1
un_flows 0
max_len 8952
quantum 1514
qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ----------------
Sent 587680693 bytes 399921 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc cake 8006: dev ifb4pppoe-wan root refcnt 2 bandwidth 550Mbit besteffort triple-isolate nonat wash no-ack-filter split-gso rtt 100ms raw overhead 0
Sent 587631457 bytes 399888 pkt (dropped 33, overlimits 751749 requeues 0)
backlog 0b 0p requeues 0
memory used: 691968b of 15140Kb
capacity estimate: 550Mbit
min/max network layer size: 40 / 1492
min/max overhead-adjusted size: 40 / 1492
average network hdr offset: 0
Tin 0
thresh 550Mbit
target 5ms
interval 100ms
pk_delay 48us
av_delay 13us
sp_delay 2us
backlog 0b
pkts 399921
bytes 587680693
way_inds 2
way_miss 192
way_cols 0
drops 33
marks 0
ack_drop 0
sp_flows 2
bk_flows 1
un_flows 0
max_len 1492
quantum 1514
Hi all
I'd love to get the R4S but prefer to have a stable version, not using "snapshot"
Does anyone know if R4S is due to get v22.03 firmware ?
Or it's still unknown?
Hi @wjwj I saw you tested R4S 22.03 RC - from what you know, is R4S likely to get 22.03 ?
Thanks!
I would try to to set 44 for the overhead and test it.
Yes since it's been coming with all the other release candidate build targets the 4GB model will have an OpenWrt 22.03 release. For example with rc6:
1 Like
Thanks! This means R4S is a safe purchase then, for those like me wanting more 'stable' release, not the bleeding edge snapshot
Do you use R4S? How does it compare to RPi4 in your experience ?
I recently had a power loss event corrupt files on my rootfs (ext4). The 'firewall' config file was overwritten with a copy of my DHCP.leases file (which usually is in tmp, but I moved to /etc/config so that it would survive a power loss since most of my clients have their own batteries or battery back up--phones, laptops, desktop and NAS on UPS, etc). Besides a UPS on the R4S, is there a way to harden the microSD card filesystem to minimize the opportunity for corruption on power loss?
That was my original config; ethernet + 44 bytes. It didn't help. I removed it for simplicity, but I agree that it belongs there.
What is the PPOE device actually bound to? eth0? What happens if you put cake on that?
I don't actually, but recently got the R5S to test for a future 2.5Gbit setup. Since there is no forum for that I lurk here since it's very similar. Another new option is the R4SE which adds eMMC to the R4S.
(My main router is the WRT32X which is fast/stable and handles SQM on my 500/35 Mbit cable along with samba, adblock, etc. works very well. My Rpi4 is a toy too, to mess with and benchmark OpenWrt, Pi-hole, and RetroPie builds with it.)
1 Like