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.
Yes correct, you are right, I’ve done a small research and I found that they have a controller inside (SD card surely, I hope the same for microSD), see Wikipedia pictures. I’ve always thought the SD/micro haven’t any controller, my fault
So this make me less anxious about the wear even with the small FS.
I think, an ext4 filesystem with journal would be a great help.
Yes sorry, I meant that you can do some debugging by enable the log at high verbosity of the SQM, then try to take a look and post here, I have no other ideas. I'm not an expert, I just want to give a small help 
What's the reason for the (potential) switch from R4S to RPi4?
What's wrong with your R4S experience?
I'am using pppoe on eth0. But I dont have any issues with cake on interface pppoe-wan.
My connection is 100/37
Do you use stable/rc release or snapshot/own build ?
Like I mentioned, I encountered the reboot issue and don't like how they handled it. Prior to that, I was very happy with the devices. I'm confident that, once I figure out this SquashFS issue, the RPi4 will be a more mature and well supported option.
1 Like
I’m using 4 RaspberryPI in my LAN but no one is a router, and I would never use it to routing my WAN connection for different reasons: now WAN port, no good OpenWrt support, too much ports/things to be a router (hdmi, audio, etc..), the GPU, and a bit less powerful than the R4S. It’s also more expensive now. So I don’t understand why your choice.
At the moment I haven’t any trouble with the R4S, despite is a quite new device. When it will become more supported by OpenWrt, I’ll switch to the R5S, not to a RaspberryPI, because I think it’s not the right device to act as a router. but this is only my personal preference/idea.
I don’t have encountered the issues you reporter. My only issue is the microSD cars, I would have preferred a built-in storage.
rc5 and rc6.
no worries
I tried enabling trace debug; there's nothing printed during the test, but the enabling of SQM showed this:
Fri Aug 5 16:03:26 2022 user.notice SQM:
Fri Aug 5 16:03:26 2022 user.notice SQM: Fri Aug 5 16:03:26 IDT 2022: Starting.
Fri Aug 5 16:03:26 2022 user.notice SQM: Starting SQM script: piece_of_cake.qos on pppoe-wan, in: 550000 Kbps, out: 58000 Kbps
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: function candidate name: sqm_start
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: sqm_start: not found
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: return value: 1
Fri Aug 5 16:03:26 2022 user.notice SQM: Using generic sqm_start_default function.
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: function candidate name: sqm_prepare_script
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: sqm_prepare_script is a function
Fri Aug 5 16:03:26 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug 5 16:03:26 2022 user.notice SQM: sqm_start_default: starting sqm_prepare_script
Fri Aug 5 16:03:26 2022 daemon.err modprobe: failed to find a module named act_ipt
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_c5f07 type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_c5f07 type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_c5f07 root cake
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_c5f07 root cake
Fri Aug 5 16:03:26 2022 user.notice SQM: QDISC cake is useable.
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_c5f07 down
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_c5f07 down
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_c5f07 type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_c5f07 type ifb
Fri Aug 5 16:03:26 2022 daemon.err modprobe: failed to find a module named act_ipt
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_0effa type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_0effa type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_0effa root cake
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_0effa root cake
Fri Aug 5 16:03:26 2022 user.notice SQM: QDISC cake is useable.
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_0effa down
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_0effa down
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_0effa type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_0effa type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: sqm_start_default: Starting piece_of_cake.qos
Fri Aug 5 16:03:26 2022 user.notice SQM: ifb associated with interface pppoe-wan:
Fri Aug 5 16:03:26 2022 user.notice SQM: Currently no ifb is associated with pppoe-wan, this is normal during starting of the sqm system.
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name ifb4pppoe-wan type ifb
Fri Aug 5 16:03:26 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name ifb4pppoe-wan type ifb
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: function candidate name: egress
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: egress is a function
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug 5 16:03:27 2022 user.notice SQM: egress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev pppoe-wan root
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev pppoe-wan root
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
Fri Aug 5 16:03:27 2022 user.notice SQM: LLA: default link layer adjustment method for cake is cake
Fri Aug 5 16:03:27 2022 user.notice SQM: cake link layer adjustments: overhead 44 mpu 0
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev pppoe-wan root cake bandwidth 58000kbit overhead 44 mpu 0 besteffort
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev pppoe-wan root cake bandwidth 58000kbit overhead 44 mpu 0 besteffort
Fri Aug 5 16:03:27 2022 user.notice SQM: sqm_start_default: egress shaping activated
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link add name SQM_IFB_f6872 type ifb
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link add name SQM_IFB_f6872 type ifb
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc replace dev SQM_IFB_f6872 ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc replace dev SQM_IFB_f6872 ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: QDISC ingress is useable.
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev SQM_IFB_f6872 down
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev SQM_IFB_f6872 down
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link delete SQM_IFB_f6872 type ifb
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link delete SQM_IFB_f6872 type ifb
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: function candidate name: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: TYPE_OUTPUT: ingress is a function
Fri Aug 5 16:03:27 2022 user.notice SQM: fn_exists: return value: 0
Fri Aug 5 16:03:27 2022 user.notice SQM: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev pppoe-wan handle ffff: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev pppoe-wan handle ffff: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Invalid handle.
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev pppoe-wan handle ffff: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev pppoe-wan handle ffff: ingress
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: invocation silenced by request, FAILURE either expected or acceptable.
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc del dev ifb4pppoe-wan root
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: FAILURE (2): /sbin/tc qdisc del dev ifb4pppoe-wan root
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: LAST ERROR: Error: Cannot delete qdisc with handle of zero.
Fri Aug 5 16:03:27 2022 user.notice SQM: LLA: default link layer adjustment method for cake is cake
Fri Aug 5 16:03:27 2022 user.notice SQM: cake link layer adjustments: overhead 44 mpu 0
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc qdisc add dev ifb4pppoe-wan root cake bandwidth 550000kbit overhead 44 mpu 0 besteffort wash
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc qdisc add dev ifb4pppoe-wan root cake bandwidth 550000kbit overhead 44 mpu 0 besteffort wash
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/ip link set dev ifb4pppoe-wan up
Fri Aug 5 16:03:27 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::2a6f:7fff:fe2a:ee00%pppoe-wan: Address not available
Fri Aug 5 16:03:27 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::2a6f:7fff:fe2a:ee00%pppoe-wan: Address not available
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: ip: SUCCESS: /sbin/ip link set dev ifb4pppoe-wan up
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: COMMAND: /sbin/tc filter add dev pppoe-wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4pppoe-wan
Fri Aug 5 16:03:27 2022 user.notice SQM: cmd_wrapper: tc: SUCCESS: /sbin/tc filter add dev pppoe-wan parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb4pppoe-wan
Fri Aug 5 16:03:27 2022 user.notice SQM: sqm_start_default: ingress shaping activated
Fri Aug 5 16:03:27 2022 user.notice SQM: piece_of_cake.qos was started on pppoe-wan successfully
There are a lot more problematic-looking prints than I'd like to see, but it doesn't seem like there's anything actually wrong, just a bunch of deletes that don't check first if the thing to be deleted exists (plus the ip tables modprobe)
I... I just realized I'm an idiot.
Because all of my devices are on Wi-Fi (or wired to an access point acting like a client), I've always run the speedtests on my router itself. This lets me max out both my download and my upload (my wifi speeds are normally limited to about 200Mbps). However, the speedtest CLI on the arm chip is apparently what's lying to me about the upload. It was telling me 560 (no SQM) and 510 (SQM) for download, and 50 (no SQM) and 10 (SQM) for upload. However, if I run from my laptop, I get a consistent 200 down (limited by Wi-Fi) and 55 or 50 up, which is what I was expecting.
I don't see it being CPU limited on any of the cores via htop, but maybe there's something else in the client that's being limited. In any case, it's clearly the executable that's lying, and not the line itself (I am using the native version from ookla, not the python version).
Thanks for all your help. Sorry for wasting your time on this!
(I'm using SQM even though I have the wifi limits because (a) I can saturate the upload and (b) the 200Mbps is per client, but I can do several at 200 at the same time)
2 Likes
So the trouble was Speedtest (ookla), I had a similar trouble, I’ve also opened a new post some months ago, IIRC from the app (running on the iPad) I was also having low speed. From the website instead, all was fine.
I don’t use anymore Ookla app, and I run the Speedtest on different services, dslreport, waveform, etc.. Speedtest is okay just for a quick test but I wouldn’t trust it alone.
Anyway you solved this weird issue 
1 Like