CAKE won't fix the latency issues pn IPQ platform, it is present on openwrt as well. Until I fix the issue on a newer kernel 3.18 is the way to go, unless you do not care for latency and qos. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
i give up ddwrt to openwrt
tested QOS in both using C7V4
atm my bufferbloat way way better with openwrt - SQM QOS
Queve discipline = Cake
Queve setup = Piece of Cake
Link Layer adaption ADSL-ATM
Packetoverhead 44 bytes
i tried all configs option in DDWRT and never work
even stock firmware handle better that ddwrt
Its one thing to i can consider back to ddwrt since openwrt sometimes configs shits is hard(like usb and printer)
Joined: 03 Jan 2010 Posts: 7568 Location: YWG, Canada
Posted: Sat Aug 25, 2018 0:50 Post subject:
vadio wrote:
i give up ddwrt to openwrt
tested QOS in both using C7V4
atm my bufferbloat way way better with openwrt - SQM QOS
Queve discipline = Cake
Queve setup = Piece of Cake
Link Layer adaption ADSL-ATM
Packetoverhead 44 bytes
i tried all configs option in DDWRT and never work
even stock firmware handle better that ddwrt
Its one thing to i can consider back to ddwrt since openwrt sometimes configs shits is hard(like usb and printer)
ipq806x k4.x latency issues aside, they care about qos, here for ddwrt brainslayer doesnt, the only times he touches qos is for "code formatting", which usually breaks it for many builds till thats reverted.. only kong is trying to patch up our qos. with openwrt's poorly named qos options aside, they simply offer more (and modern) options. overhead calculations etc. ive tried for years, brainslayer just doesnt care about qos, look at wireguard, he CERTAINLY cares about that part of the firmware..constant commits to it. _________________ LATEST FIRMWARE(S)
BrainSlayer wrote:
we just do it since we do not like any restrictions enforced by stupid cocaine snorting managers
i tried all configs option in DDWRT and never work
even stock firmware handle better that ddwrt
After only 5 posts here you're announcing this. Good. DD-WRT is definitively not for you. 3.18 builds might be better, but even BS builds give decent QOS on WAN links over 100Mb/s. That QOS is horrendous on BS build is just over exaggerate and inflammatory.
i give up ddwrt to openwrt
tested QOS in both using C7V4
atm my bufferbloat way way better with openwrt - SQM QOS
Queve discipline = Cake
Queve setup = Piece of Cake
Link Layer adaption ADSL-ATM
Packetoverhead 44 bytes
i tried all configs option in DDWRT and never work
even stock firmware handle better that ddwrt
Its one thing to i can consider back to ddwrt since openwrt sometimes configs shits is hard(like usb and printer)
QOS in openwrt is as much broken on the IPQ platform as with BrainSlayer builds, this is simply caused by a kernel bug that hits ipq in 4.x kernels. Only 3.18 is currently not affected. Of course it may be a little bit better depending on settings, but it is in no way close to the qos performance with 3.18, where you get A+ across the board with only 10ms on top. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
QOS in openwrt is as much broken on the IPQ platform as with BrainSlayer builds, this is simply caused by a kernel bug that hits ipq in 4.x kernels. Only 3.18 is currently not affected.
Has anyone reported the problem to upstream or bisected this regression? Just curious.
@<KONG> What chance would there be to develop cake on K4.9 for DD-WRT on more powerful QCA routers?
Or is the latency issue in 4.9 still a mystery and so CAKE not worth an attempt to implement?
I'm hoping we can get an honest explanation.
Thank you in advance!
There is only a latency issue in the wifi code for ath10k and it does not affect all clients, it depends on the client features.
Cake won't fix this and cake is only worth it if you want qos to impair things, as cake is not working with imq thus comes with a reduced feature set.
Besides that all comparison between cake and fq_codel on other platforms is bullshit as fq_codel implementation in non dd-wrt has been broken for years no one except me fixed rate calculation for fq_codel. Thus if you see benchmarks on openwrt comparing fq_codel with cake it is misleading as their fq_codel is broken. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
Joined: 30 Jan 2015 Posts: 676 Location: Texas, USA
Posted: Sat Jan 26, 2019 17:24 Post subject:
@Kong,
Can we have Cake implemented in R9000, Please?
Thanks. _________________ ASUS GT-BE98 PRO Main: Fiber 5gbps up/down
ASUS AXE16000: AI Mesh node
2 X ASUS RT-AX89X: AI Mesh nodes
QNAP QSW-1208-8C 12-Port 10GbE Switch
XS712T ProSafe 12-Port 10GbE Switch
3 X R9000 DD-WRT Mesh
@<Kong> I saw that other WRT firmwares made a switch away from IMQ to IFB; to be honest, I am no guru on this, but it seems that IMQ is not "future" proof? I do recall reading elsewhere that our iptables config/drivers are way old too... what would it take to help out on this front? I know your time is limited too, just curious if there is a way to convince BS to make some necessary updates....perhaps an influx of donations to specific features/updates?
I suck at coding and this would take me a long time to learn...TBH, I don't know where to begin... But I do want to help. _________________ FORUM RULES
