Yes, but think about a "good queue" as sort of a shock absorber that is beneficial:
Say 5 full sized packets are sent at 1Gbps without any gap and hit a cake instance with 12 Mbps egress limit (so each packet takes roughly 1ms to transmit), the first is passed on to the next stage, while the other 4 are now entering a queue waiting for their transmission-slot. If we would allow no queue we would need to drop those immediately, as this sort of transient queueing is to be expected at places where the capacity decreases... now we need to strike a deal, so we prefer lowest latency for those packets that win the lottery and hit cake when the queue is empty at the cost that other packets encounter extreme latency (being dropped and having to be retransmitted takes quite a while) and that the throughput tanks (all the dropped packets likely will be retransmitted), or do we accept some transient queueing to smooth things out a bit? Say in our example if after the five packets there would be no more packet for the next second, should we really drop 4 of those or accept that the last of these will encounter ~4ms queueing delay? I think you get where I am going with this
That is something that I think is named strict rate policing, and it is quite unpopular, as it has severe effects on throughput and introduces unpleasantly high packet loss rates, and loss recovery than introduces delay into the flows again (not by queuing in the bottleneck, but unacknowledged packets stay queued in the senders network stack, assuming something like TCP). The idea behind AQMs is to not wait for a queue to overflow before dropping, but to selectively use drops to signal flows to reduce their sending rate... to do that gently one better waits for a flow to actually react, and a flow can at best respond to a signal in a single roundtrip time (the drop/ECN signal needs to travel from the AQM to the remote end point, and the remote endpoint needs to send that back to the other side, that needs to change its sending rate, and this changed rate needs to arrive at the AQM location), but that means that one should be able to queue up the excess rate of a flow for a full RTT of that flow.
Ah, so in my experience with codel based droppers the average delay often ends up in the range of ~2 times target or ~10ms for the default target of 5ms... this has reasons, like codel (all of codel, fq_codel, cake use the same logic here) will only engage when the minimal sojourn time encountered says above "target" magnitude for a duration of "interval"*, but that likely means that the actual sojourn times exceed target considerably, and these longer sojourn time samples are averaged with the short sojourn time samples from flows below their capacity share...
So, at least av_delay and peak_delay under load likely will show higher values than target...
*) If codel engages that way it will then change the value of interval reducing it, so if that flow stays above threshold it will get the next signal quicker...
@Lynx
I have tired your script today on a FRITZBox 7530 with a internal DSL modem with a fibre PPPoE connection, However it seems that my upload speed is.my download speed on the script.
I did select the pppoe-wan interface.
How could i fix this to make it work with a DSL/PPPoE?
If there a way i can force a my google pixel to use VoWiFI on port 500/4500 with my devices IP (have set a static DHCP on mobile devices) as my google pixel 8 dos not make any DSCP requests for EF, I did see a MAC address but this would mean all my traffic is bulked, right?
heres is the log if i kept wan.
Setting up nftables rules for cake-qos-simple using: /root/cake-qos-simple/nft.rules.
Setting up ingress handle for interface: 'wan'.
Cannot find device "wan"
No dl_if specified, so setting up appropriate IFB.
Creating IFB device: 'ifb-wan'.
Setting interface: 'ifb-wan' up.
Setting up tc filter to restore DSCPs from conntrack on ingress packets on interface: 'wan' and redirecting to IFB interface: 'ifb-wan'.
Cannot find device "wan"
Setting up CAKE on interface: 'wan' with bandwidth: '20Mbit/s' and options: 'diffserv4 dual-srchost nonat wash no-ack-filter split-gso rtt 100ms pppoe-ptm ether-vlan noatm'.
Cannot find device "wan"
Setting up tc filter to restore DSCPs from conntrack on egress packets on interface 'wan'.
Cannot find device "wan"
Setting up CAKE on interface: 'ifb-wan' with bandwidth: '20Mbit/s' and options: 'diffserv4 dual-dsthost nonat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34'.
Started cake-qos-simple.
root@DSL:~# /etc/init.d/cake-qos-simple stop
Removing ingress handle for interface: 'wan'.
Cannot find device "wan"
Removing CAKE on interface: 'wan'.
Cannot find device "wan"
Removing CAKE on interface: 'ifb-wan'.
Setting IFB interface: 'ifb-wan' down.
Removing IFB interface: 'ifb-wan'.
Removing nftables rules for cake-qos-simple
Stopped cake-qos-simple.
Yes.
I dont know this this is any help but qosify and sqm seems to working the right way, @elan 's script what can be found here https://github.com/Last-times/CAKE-QoS-Script-OpenWrt/blob/main/cake.sh and based on nftables however seems to crash out my router where i would get internet but if went on the openwrt forums it just crashes but dosnt reboot? strange eh? - Now if i did eth0 what is my LAN, i get reversed like cake-qos-simple
Might be something to do with is? I seen something like this in SQM, Would this work do you think as this worked for me in SQM?
I'd just stick with the defaults but make sure the upload/download are appropriate for the true state. So you might need to swap these around if your interface is reversed for some reason.
I hope @moeller0 can offer more insight here since I'm not feeling so sure about it.
logs, i used pppoe-wan, There is dsl0 but it might work also. Have submitted a pull request but ill leave it upto your if you wont to help others?
root@DSL:~# /etc/init.d/cake-qos-simple start
Checking validity of nft.rules file.
Validity check of nft.rules file passed.
Setting up nftables rules for cake-qos-simple using: /root/cake-qos-simple/nft.rules.
Setting up ingress handle for interface: 'pppoe-wan'.
No dl_if specified, so setting up appropriate IFB.
Creating IFB device: 'ifb-pppoe-wan'.
Setting interface: 'ifb-pppoe-wan' up.
Setting up tc filter to restore DSCPs from conntrack on ingress packets on interface: 'pppoe-wan' and redirecting to IFB interface: 'ifb-pppoe-wan'.
Setting up CAKE on interface: 'pppoe-wan' with bandwidth: '10Mbit/s' and options: 'diffserv4 dual-srchost nonat wash no-ack-filter split-gso rtt 100ms pppoe-ptm ether-vlan noatm'.
Setting up tc filter to restore DSCPs from conntrack on egress packets on interface 'pppoe-wan'.
Setting up CAKE on interface: 'ifb-pppoe-wan' with bandwidth: '20Mbit/s' and options: 'diffserv4 dual-dsthost nonat nowash ingress no-ack-filter split-gso rtt 100ms noatm overhead 34'.
Seems about right... after all this is not rocket science...
According to this things should work (you might want to add the ack-filter keyword to the upload) and both qdiscs actually see traffic.
So please run the following capacity-test and post a screenshot off the full page after it finished (ATTENTION, by default this contains your IP address which you might want to redact before posting, or not):
Mmmh, there is something quite off here, with a shaper setting on 20/10 Mbps you should not be able to get a 60/16 Mbps result... Could you hypothesise what is going on?
@francisuk1989 I appreciate the pull request. Iād like to explore different possible ways of addressing this issue you helpfully raised.
@moeller0 is there an elegant or generic way to address that which this pull request seeks to address:
Why are the download and upload directions reversed when using an integrated modem?
Are situations like this sufficiently irregular that the complexity associated with dispensing with the terms download and upload and replacing them with ingress and egress is not warranted?
Fudging it with just telling user to swap download and upload is also not especiallly intellectually satisfactory.
Since I really do not know/understand what the PR aims at I am not in a position assess elegance here. Maybe @francisuk1989 could clue me in what he considers the the improvement here? (I would not go nonat, as that will not work all that well with dual-dsthost and dual-srchost, but since I do not know the rationale behind switching from nat to nonat this is a rather undirected comment).
What I took as the aim is guiding the user to swap around the download and upload calls. Iām trying to work out if having to flip those is something that could be a regular occurrence and should be addressed in a generic way?
