Is it possible to prioritise web browsing with cake so it always feels fast, regardless of other tasks?
In general, the basic settings for cake (and fq_codel) in OpenWrt's SQM do exactly this, without the need to worry about prioritization. (The basic settings work great on my home router, even at crummy 7 mbps DSL rates.)
We recommend you configure SQM as described in the Howto and let it run for a week or so. If it's working well and you are happy, you can spend time on other projects.
If those settings don't work well enough, you'll have specific information you can bring back to the forum to ask for help. Good luck!
I've been running SQM with cake for many months now but I've only just got around to commenting.
I have found when torrenting especially, web browsing slows down and feels less responsive. This seems to be when the torrent client is taking most of the bandwidth. To me, it seems like browsing isn't being given enough bandwidth in this scenario.
I have setup cake and SQM as per the wiki, including using all the advanced options to ensure per host fairness.
Question, are you trying to run the torrent client and the web browser on the same computer?
If no, the per-internal-IP fairness modes that cake offers might help your use case. Other than that you can always try to use the torrent clients build in rate limiting as well. Torrenting tends to use many parallel flows and hence will be happy with cake's default flow-fair queueing, but that is one of the reasons why cake grew the IP fairness modes as well. And just to explicitly state this, in IP fairness mode, cake will first share equitably between all concurrently active internal IP addresses but then for all traffic to/from each internal IP it will also implement per-flow-fairness, which typically works pretty well. The one common use-case where per-flow fairness is sub-optimal is really torrenting, since it naturally uses many flows and is typically considered to be low priority, but strict per-flow fairness gets the low-priority bandwidth scavenger aspect wrong...
As a final comment, you could also just try to to use one of cake's dscp modes and "simply" dscp mark torrent packets as low priority, but that is harder than it seems and typically harder than simply run the torrents on a different machine (given e.G. the low price of a raspberry pi that can easily serve as torrent endpoint).
I am trying to torrent and use the web browser on the same client, indeed. I've already set up per-internal-IP fairness which works in most cases, except this one.
How might I mark torrent packets as low priority?
So there is no way with cake to ensure that the browsing is always given priority, or more bandwidth than other users of the connection, even if it's just a megabit or two dedicated to browsing?
If torrenting is already given low priority, I am bemused why browsing then slows down?
Is it possible to see how different applications and IPs are sorted into the queue, in real time? How does cake determine which applications are low and high priority?
Should I also be using the additional diffserv4? I am using diffserv3 at present which I believe is the default, would this help?
As I tried to explain, then all the torrent flows compete directly with your browsing flows, and fair queuing will on average give more bandwidth to the total of all torrent flows. That is the expected behavior.
There are possible solutions to this issue, from using bandwidth throttling in the torrent client over trying to use network namespaces to let the torrents run with a different IP address to using DSCP marking for the torrent traffic. So here is a question, what operating system are you using, and are your torrents mainly downloading or uploading?
Yes and no, cake can not really understand your intent or priorities, the best it can do is to honor DSCP markings in the packets to sort them into a handfull of different priority tiers, but yu are left with the challenge of applying these marks before cake actually handles the packets.
Becase all that cake sees are differet flows, and it tries to treat all of the equally, torrents win over brosing not because torrent flows get more bandwidth that browsing flows, but simply because you most likely will have a shipload of torrents compete against a few handful of browsing related flows.
Thinking this over, you could also try to limit the number of concurrent torrent flows to something sane, then cake should do the right thing out of the box.
It just maps different DSCPs into its different iers and services these tiers with different priorities. Your task is to make sure packets carry the correct dscp marks to be sorted into the desired priority tier.
Unlikely, in your case I would recommend to simply mark the torrent packets such that they end up in the low priority tier, and keep browsing in the normal priority tier. The difference between diffserv3 and diffserv4 is that the latter has an additional "even higher priority" tier...
But to use these, you would need to switch to layer_cake.qos, as piece_of_cake.qos should default to no diffserve tiering.
I dont want to steal the OPs thread but, i have been wondering just about this.
If you use diffserv4 for example, traffic goes into different tins by default. Why and how?
Thanks
/* List of known Diffserv codepoints:
*
* Least Effort (CS1)
* Best Effort (CS0)
* Max Reliability & LLT "Lo" (TOS1)
* Max Throughput (TOS2)
* Min Delay (TOS4)
* LLT "La" (TOS5)
* Assured Forwarding 1 (AF1x) - x3
* Assured Forwarding 2 (AF2x) - x3
* Assured Forwarding 3 (AF3x) - x3
* Assured Forwarding 4 (AF4x) - x3
* Precedence Class 2 (CS2)
* Precedence Class 3 (CS3)
* Precedence Class 4 (CS4)
* Precedence Class 5 (CS5)
* Precedence Class 6 (CS6)
* Precedence Class 7 (CS7)
* Voice Admit (VA)
* Expedited Forwarding (EF)
* Total 25 codepoints.
*/
/* List of traffic classes in RFC 4594:
* (roughly descending order of contended priority)
* (roughly ascending order of uncontended throughput)
*
* Network Control (CS6,CS7) - routing traffic
* Telephony (EF,VA) - aka. VoIP streams
* Signalling (CS5) - VoIP setup
* Multimedia Conferencing (AF4x) - aka. video calls
* Realtime Interactive (CS4) - eg. games
* Multimedia Streaming (AF3x) - eg. YouTube, NetFlix, Twitch
* Broadcast Video (CS3)
* Low Latency Data (AF2x,TOS4) - eg. database
* Ops, Admin, Management (CS2,TOS1) - eg. ssh
* Standard Service (CS0 & unrecognised codepoints)
* High Throughput Data (AF1x,TOS2) - eg. web traffic
* Low Priority Data (CS1) - eg. BitTorrent
* Total 12 traffic classes.
*/
DIFFSERV4:
tatic int cake_config_diffserv4(struct Qdisc *sch)
{
/* Further pruned list of traffic classes for four-class system:
*
* Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
* Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
* Best Effort (CS0, AF1x, TOS2, and those not specified)
* Background Traffic (CS1)
*
* Total 4 traffic classes.
*/
```
DIFFSERV3:
static int cake_config_diffserv3(struct Qdisc sch)
{
/ Simplified Diffserv structure with 3 tins.
Low Priority (CS1)
Best Effort
Latency Sensitive (TOS4, VA, EF, CS6, CS7)
*/
Some applications set DSCPs by default and hence map into cake's different priority tiers. For ingress/download things get trickier as many ISPs actually change DSCP on route (as they are entitled to, DSCPs are unfortunately not considered to be end-to-end stable), so the mix of ingress DCSPs most likely will not tell you much about the sender's intent.... Also as I tried to indicate, changng the DSCPs of incoming packets is hard, as cake sees the packets before iptables does and hence any marking requires tc and lots od swearing.
Or ask @ldir nicely as he has an immensely clever method to sort of copy the DSCPs from a flows outgoing packts to its incoming packets, before cake processes them, which reduces the problem to how to set egress/upload DSCPs, and there iptables can be your friend.
Thank you, i knew about the different classes but not how it assigns tins without any manual intervention, i guess its tagged on the way, and im not using "wash" on ingress
Again, if you don't add the DSCP tags to your packets, then cake has no knowledge on the priority of said packets and will thus throw them into the best effort queue. So yes, this is supposed to happen with your current settings.
As already mentioned, tagging outgoing packets is easy. This can be done with the torrent client itself if it supports it, or with some iptables rules on the router. This should allow you to shape your uploads very easily. However, incoming packets are a pain. You cannot force the torrent client at the other side of the connection to tag them properly, and even if you do, ISPs can change these tags while in transit.
Normally it isn't possible to use iptables to tag incoming packets for SQM, since the packets will hit SQM before they hit iptables. However, there are some complex workarounds for this, but it's quite difficult to set up (properly).
Okay but then why have the queues at all if most people can't use them without a lot of extra setup?
I would have thought it wouldn't be difficult to distinguish between browsing and downloading and stick them in different queues, I've obviously not understood the point in having the diffserv configuration.
sqm / qos has always been notoriously complex from a configuration standpoint...
having openwrt handle the complexities within cake and leave you to simply dcsp-tag is about as simple as it gets...
as with all things openwrt... to maintain flexibility across all environments... 'tag-this' needs to be done at a command line / lower level than common setup options... this is due to the various ways sqm can be instantiated, the various underlying network topology / interface setup and tc/queue directionality / dcsp honouring behaviour...
that said, a few iptables mark rules and some possible ip/vlan/route specifities on a client are not exactly complex...
something else to keep in mind is;
many mid/high level switches can also set your dcsp tags for you before reaching openwrt...
many clients allow additional logical ips/ranges or vlan tagging of certain traffic, so you dont necessarily need another client
as mentioned above... many host-os's/applications allow you to assign the correct dcsp tags on your client
in summary, the variety at the network level coupled with the constraints at the sqm/router/protocol level make automating / 'simplifying' such things much further than they currently are, mean one would have to dictate to the user how their network should be setup... and this is not the openwrt philisophy...
Wash I believe will first use the DSCP to select the appropriate priority tier and then remap that dscp to zero. The idea is to be able to not leak DSCPs, if you do not want to interpret DSCPs at all, just use the besteffort keyword...
DSCP 0 ist the default marling and that will map into cake's Best Effort priority tin, so unless you take special care to mark relevant packets differently, all/most packets in Best Effort is the expected outcome.
Well, the egress cake stats look fine (peak delay 465µs), but ion ingress things look less rosy (peak delay 87.8ms, which probably is noticeable (no not all packets will be delayed by that amount but that indicates delay varuations up to 84ms on top of the base RTT and that can be noticeable.).
I wonder why the per-internal-IP address isolation did not work though, as if the torrents are on another computer with a different IP address they should interfere much less.
But what is your true internet access link speed?
To make such things possible. If we knew a way to make them easy as well, we would have, but ATM possible is all we can offer.
Well, cake uses two ideas that typically help a lot, it prioritizes sparse flows (flows that do not actually accumulate packets in the queue) which is typical for interactive flows like gamin/web browsing. And it allows to separate the traffic of different machines so that one can isolate offending traffic easier. BUT for ingress traffic, and I assume you use torrents to download stuff, cake sits on the wrong end of the bottleneck, if the flows are not responsive enough packets will accumulate in the typically over-sized and under-managed upstream buffers and you will encounter latency under load.
You could try to further reduce the shaping rate for ingress traffic, which sometimes helps to reduce the issue a bit, or simply try to reign in the offending application, by either setting bandwidth limits and/or if pssible restrict the number of concurrent flows/torrents.
I do not use torrents myself and hence have little first hand experience in how to properly configure a torrent client.
But I know one issue is that bittorrent tries to be a good internet citizen and tries to stay out of the way of more important traffic, but does so by measuring induced delay, and I believe it will throttle when seeing >= 100 ms latency increase, but cake target's for 5ms of acceptable standing queue, so bittorrents µTP protocol might constantly do the wrong thing for the right reasons...
@moeller0 I'm on VDSL2 synced at 64199Kbps down and 7999Kbps up. I'm using PPPoE for BT in the UK.
53000 is what I have set in the down for cake and 7700 up, so I would have thought I'm way below running into any kind of bloat issues, I could probably set it a lot higher.
I posted my config above, please do let me know if it looks okay to you?
Layer cake + DSCP marking works brilliantly once it's set up.
It's certainly not trivial though. I have three SQM instances running and 600 lines of firewall script to classify (and reclassify) packets using DSCP tags based on many different criteria using the flexibility of iptables, ipsets, and dnsmasq. Once a packet has been (re)classified, the DSCP tag is associated with its connection using connmark, and the tags are applied to all packets on that connection before they are shaped by SQM. I can do this for incoming traffic because I've split my SQM between the WAN interface and the LAN interfaces like this:
If you can't split the upload/download SQM in this way you can't prioritize incoming traffic, because the packets hit SQM before iptables, so you don't have an opportunity to apply the DSCP tags. I think there's another approach using virtual interfaces (veth's), but I don't know much about that.
To be honest I doubt I would have made the effort if I hadn't been stuck at home for months under COVID-19 lockdown
