Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Cake or Pie?
Cake was added as a QoS discipline a few builds ago. Pie has been there for quite some time.
I get better results using Cake too which has been in OpenWrt for a long time.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Aug 27, 2019 16:22 Post subject:
NBA Jam wrote:
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Help the ignorant here, so that we can give Cake a try (as opposed to a pie). What should Port, Packet Scheduler, and Queuing Discipline on the QoS page be set to? I've seen the wiki page and a few other discussions of unknown vintage, but I have no idea what current thinking is. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
97% mostly solves my bufferbloat too but it completely stops working as far as prioritization goes. For QoS to really work as intended 97% limit wont be enough even with Cake.
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Help the ignorant here, so that we can give Cake a try (as opposed to a pie). What should Port, Packet Scheduler, and Queuing Discipline on the QoS page be set to? I've seen the wiki page and a few other discussions of unknown vintage, but I have no idea what current thinking is.
Port is WAN. Packet scheduler should be irrelevant with Cake since it does it's own scheduling AFAIK.
Saw that this build has CAKE in it. Really impressed with its performance compared to fq_codel. I can get about 97% of my download and upload speeds with no bufferbloat.
Help the ignorant here, so that we can give Cake a try (as opposed to a pie). What should Port, Packet Scheduler, and Queuing Discipline on the QoS page be set to? I've seen the wiki page and a few other discussions of unknown vintage, but I have no idea what current thinking is.
I use WAN port. Most people recommend HTB for packet scheduler nowadays then choose cake from the queuing discipline. I set my upload and download speed to 90-95% of what I get without QoS based on running speed tests.
Cake is native to openwrt and worked better for me than fq_codel or Pie. That is I can set the up/down links higher and still mitigate bufferbloat. It was added to dd-wrt a few builds ago.
I pay for 400/20 but get about 480/21 without QoS I set my up/downlinks to 460000/19000
Upgraded from 40459 to partition-1 via GUI without any problems. 40784 uptime is almost 2 days. Performance is excellent and feels very snappy. Switched to CAKE for QOS queuing discipline. Very stable in my environment. 40134, 40459 and now 40784 have all been rock solid.
Upgraded from 40459 to partition-1 via GUI without any problems. 40784 uptime is almost 2 days. Performance is excellent and feels very snappy. Switched to CAKE for QOS queuing discipline. Very stable in my environment. 40134, 40459 and now 40784 have all been rock solid.
I upgraded to this version (from the smaller partition via GUI) hoping for great things, but my WiFi broke after about 2hrs up time.
Back to r40134 on my WRT1900ACS V2. Absolutely no issues experienced with 40134 build. I have had random drop outs on later builds, but not complete WiFi incontinence like r40784. Might require a complete reset to work properly?
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Fri Aug 30, 2019 21:47 Post subject:
Upgraded my client-mode travel router, a WRT1900ACSv2, from 40009 (partition 2) to 40784 (partition 1) over wifi during ordinary operation by copying the ddwrt-linksys-wrt1900acsv2-webflash.bin file into /tmp/root on the router with scp then doing, in /tmp/root on the router using the CLI via ssh, write ddwrt-linksys-wrt1900acsv2-webflash.bin linux and reboot. The process went smoothly.
[Edit] One issue is samba. I had to add ( sleep 30; stopservice samba3; startservice samba3 ) & in the startup commands, as was reported for several other recent builds, to be able to use shares on my USB/NAS drive. Apparently dd-wrt is starting samba3 too soon, before critical things are ready. File under "race condition".
[Second edit, days later] I use the OpenVPN client. On this release (didn't happen on 40009), Apply on the OpenVPN GUI page stops openvpn and shuts down the openvpn process:
I don't use QoS on this router, so I am trying SFE. My ISP service at home where I'm testing is only 200 Mbps down and 10 Mbps up, but even so there is a modest but clear increase in non-vpn download speed at https://www.dslreports.com/speedtest. Outside factors were limiting speed anyway, so the test was not definitive.
Had a couple of freeze ups - no internet - early on, but that may have been when I enabled SFE and applied without rebooting. Guilty: poor notekeeping. Rumor has it (now that I've bothered to read) that a reboot is often needed for SFE to get its act together. [Edited] I had to reboot to test the samba fix above, but before going there I was up 23 hours without a hitch, though admittedly with a very light load.
Will try this release on the main home router within a few days. It carries much more traffic and so will make for a more meaningful test. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
I was on pie, switched to cake and now when I try to switch back to pie, or any other method, the router hangs on the apply screen and the GUI wont update. I have to physically restart the router in order to log back into the GUI. Once the router restarts and I log back in the QOS is still set to cake. _________________ -Tim
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Sun Sep 01, 2019 14:29 Post subject:
CantRepeat wrote:
Has anyone tried to switch off of Cake?
I was on pie, switched to cake and now when I try to switch back to pie, or any other method, the router hangs on the apply screen and the GUI wont update. I have to physically restart the router in order to log back into the GUI. Once the router restarts and I log back in the QOS is still set to cake.
Edit: The router I used below is still on 40009, so there's an assumption wired into trying this that 40009 and 40784 use the same nvram variable for Queueing Discipline. Seems like a reasonable assumption, but you never know.
With my QoS Queuing Discipline set to FQ_CODEL I can do nvram show | grep -i fq_codel in the CLI and get the one-line response svqos_aqd=fq_codel, which suggests to me that one could perhaps do nvram set svqos_aqd=fq_codel and nvram commit to get back to fq_codel. Not sure what precise value to set to get to Pie in particular, but you could try first getting to fq_codel this way and then doing a reboot. If it boots up OK with fq_codel active, then select pie, save, and (to be safe) reboot again (rather than apply, which it seems may have issues for QoS). Of course this whole strategy is a bit of a gamble, as we don't really know what else in nvram is changed when the Queuing Discipline is changed in the GUI... _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Sep 02, 2019 0:43 Post subject:
I reported on my travel router above.
Now I have upgraded my main (home) router also, another WRT1900ACSv2, from 40009 (partition 2) to 40784 (partition 1) over wifi during ordinary operation, again by copying the ddwrt-linksys-wrt1900acsv2-webflash.bin file into /tmp/root on the router with scp then doing, in /tmp/root on the router using the CLI via ssh, write ddwrt-linksys-wrt1900acsv2-webflash.bin linux and reboot. The process went smoothly.
Again I had to add ( sleep 30; stopservice samba3; startservice samba3 ) & to the startup commands, as was reported for several other recent builds, to be able to use shares on my USB/NAS drive. Without adding this, attempts to mount a share from linux return "mount error(2): No such file or directory".
I enabled SFE with QoS off, saw that lsmod reported a new module, fast_classifier, right at the top of the list, and that when I subsequently enabled QoS, that module disappeared. That clears up for sure which takes priority, SFE or QoS. It's QoS. Turn QoS on and SFE is disabled behind the scenes.
I did go ahead and set up QoS with LAN&WLAN/HTB/Cake and interface priorities Bulk/Standard/Express/Premium for five interfaces including two bridges, with all the numbers in that table set to "none". Maybe it works? I have no idea how to test it or verify that it's doing anything, since /proc/net/nf_conntrack output doesn't have mark=... entries like the apparently hopelessly obsolete wiki page https://wiki.dd-wrt.com/wiki/index.php/Quality_of_Service claims. Speedtests were not revealing.
One small bit of weirdness is that while setting up QoS with various Apply steps along the way, one of my vlans disappeared from bridge br1 in the Current Bridging table. Bizarre. But a reboot brought it back.
Somewhat more alarming is that the vpn log -- I use only the OpenVPN client -- now consistently ends every connection sequence in this way, which I have not seen in earlier releases (36698 37736 38159 39144 40009). My config is nothing radical and has not changed lately.
Quote:
Sun Sep 1 19:27:22 2019 TUN/TAP device tun1 opened
Sun Sep 1 19:27:22 2019 TUN/TAP TX queue length set to 100
Sun Sep 1 19:27:22 2019 /sbin/ifconfig tun1 10.8.1.33 netmask 255.255.255.0 mtu 1500 broadcast 10.8.1.255
cat: can't open '/proc/net/ip_conntrack_flush': No such file or directory
0
cannot open /proc/sys/net/ipv4/conf/br0/loop
cat: can't open '/proc/net/ip_conntrack_flush': No such file or directory
0
cannot open /proc/sys/net/ipv4/conf/br0/loop
Sun Sep 1 19:27:30 2019 Initialization Sequence Completed
This router has a /proc/net/nf_conntrack but nothing called ip_conntrack that I know of, and its /proc/net directory contains no ip_conntract* files. And its /proc/sys/net/ipv4/conf/br0/ directory indeed contains nothing called loop. OpenVPN was doing this before I changed any settings in the new release. So it appears that something needs a bit of customization for particular routers or router families. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
