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
It's eth0, the default. It's still stuck at ~10Mb, whether I use pppoe-wan or eth0.
Thanks! This looks really interesting but at the link you showed, it doesn't appear to be getting 22.03 stable release ?
No R5S is brand new it won't be included with 22.03 release, nor will R4SE. There is however a good FriendlyWrt build (based off of 22.03-rc) that works well in my early testing but just got it so haven't posted much yet.
I prefer official OpenWrt builds whenever possible, but the FriendlyWrt builds are here if you're interested:
https://www.friendlyelec.com/index.php?route=information/information&information_id=7
1 Like
I'm considering switching from R4S to RPi4. The only thing blocking me is that I can't get any SquashFS image working, on my RPi4. See below.
FriendlyElec make some great hardware, but their lack of engagement with the OpenWrt community is disappointing. I don't like that they make their own OS, but don't upstream any of their patches. I was happy with their product, until I encountered the reboot problem and was told to just run FriendlyWrt. They didn't ask for logs or anything.
RPi4 should be a much more mature platform. However, the fact that none of the SquashFS images work is troubling.
If you do end up going down the RPi path, you will need a high quality passively cooled case or actively cooled case; they run hot. The R4S is much better, in that regard.
1 Like
If that were the case, they would have vastly more pins and be unable to comply with the MMC/SD standard.
The last time removable media exposed bare NAND without a controller was the now long-dead SmartMedia standard.
The MMC/SD standards even include ERASE/TRIM commands - these aren't possible without a controller.
Uuhhmm that’s weird, did you tried to watch the log of SQM? Because you had also a issue with fql_codel (that’s hard coded into the kernel), so maybe is something broken in your config. I would try to do some debugging.
The error was that it was trying to modprobe something that was in the kernel. From looking at the sources, I suspect anyone who tries fq_codel will see the same thing.
As far as "trying to do some debugging", well, that's why I'm here. I'm out of ideas and was hoping either someone else had a solution or a similar problem at least. I pasted the output of a tc command above, but I'm not terribly familiar with what it should look like. Nothing else I've seen looks problematic; CPU, IRQs, processes in iowait, etc.