I'm sorry if this has been asked before.
As far as I know cake tries to distribute the available bandwidth fairly between IP-addresses.
Is it possible to prioritize a device (e.g my gaming console) and share the excess ?
short answer: no
long answer:
cake itself does not, by choice.
fair-queueing should "shield" your gaming console from lag-spikes induced by other activity in your network by default.
if it does not, you should clarify 
you can modify sqm-scripts to have seperate classes.
2 Likes
In my experience, SQM QoS with 'cake' works much better than any device specific QoS configuration.
2 Likes
Thanks for your reply. Is there a tutorial or a guide so I can try this? I'm not that good with linux.
So you could select layer_cake.qos (in sqm, which I assume you use already) instead of piece_of_cake.qos. That way sqm will use DSCP markings to put packets into one of (by default) three priority tiers. The caveat is that the higher the prority tier the smaller the guaranteed prioritized bandwidth, so the normal recommendation would not be "move your gaming machine into the highest priorety tier" but rather move everything to be known unfair and problematic (like bit torrent) into the back-ground (lowest priority) tier. While that theory and functionality is all sane the tricky bit is getting the packets DSCP marked correctly. In theory this again should be no problem as application surely will allow to configure the required DSCP marking (but in reality almost no application that should does, I am looking at you bit torrent clients...). Again you might be able to mark packets correctly using iptables (and setting marks depending on src IP address to isolate your gaming host) on say the router's LAN interface (assuming sqm works on the WAN interface). BUT on ingress sqm sees the packets before iptables is available and before NAT has been performed, so there simply is insufficient information to isolate the internal host IPs. Cake works around this by peeking into the kernel's NAT tables to get a pretty good idea what the internal IP is going to be. In theory you might be able to pull all of this off, but I doubt that this will lead to a robust configuration.
But to concurr wth @fuller, what in sqm-scripts defau;ts does not work for your use case (honest question, sqm-scripts has some traffic conditions which is has a hard time shaping correctly, you might actually be unlucky).
Best Regards
It really depends on the particular network. For one of my networks SQM does a very poor job. The QoS in Gargoyle, which uses prioritisation, does a far better job. In this particular network there is a large amount of uploading to the cloud. The uploading bandwidth is saturated for at least 50% of the time (24/7) and during some periods 100% of the time. Hence have the best QoS is critical. I have dedicated a RPi to the task of uploading backups to the cloud and set it at the lowest priority. Many other computers and devices on the network are also uploading to the cloud. In addition to this there is high priority Skype and VoIP on the network. While Gargoyle QoS is not perfect, it is far better for this particular situation.
The only reason I have moved to the ROOter firmware, based on LEDE, is for the Multi-WAN support, which is not available on Gargoyle.
Note that sqm/cake/layer_cake should allow to configure per device fairness, so that the uploading hosts should leave the interactive hosts more or less alone (but the effectiveness of that partly depends on the traffic patterns). Layer_cake will also try to treat a few DSCP markings with higher priority, markings that might/should be used by VoIP clients. The per-internal-IP fairness will do not much good at all if one tries to use skype on a machine that is currently in the process of backing data up...
This is an additional advantage of the Gargoyle QoS system. It allows priorities to be configured based on destination IP addresses and/or ports. Skype normally uses a known group of IP addresses, so these can be given a higher priority than the destination IP addresses for cloud backup. This then ensures better traffic control even on an individual client or group of clients.
Yes, for some use-cases that certainly is an advantage but it comes at the cost of perpetual whack-a-mole of configuring ports and IP-addresses (which typically are not guaranteed to be stable over time).
The point I want to make is evident in the "normally" above 
But, if you manage to get your applications to use the correct DSCP markings (mainly CS1/BK for bulk traffic) cake's diffserv3 and diffserv4 modes allow also prioretization of say typical VoIP traffic (in sqm look at layer_cake). I also add that in both cases the challenge is pretty much to get the correct markings on the individual flows... which is especially tricky for ingress traffic in networks using NAT/NAPT/masquerading. Even though there now is an epic thread in which @dlakelan cleverly developed a scheme using veth pairs to solve this particular problem.
Also agreed, if you want/need that level of detailed control than sqm is not the right tool for you, given that sqm favors simplicity and "doing-roughly-the-right-thing" out of the box over full control and configurability...
epic is right. I think the warning that comes with that is that it seems like it might require hardware with something better than typical consumer router. I personally am at the point where I agree with https://arstechnica.com/gadgets/2016/01/numbers-dont-lie-its-time-to-build-your-own-router/ I'd use something different than what that guy used, but basically along the same lines. You can build an epic gigabit 4 core Intel router for something less than $200, it will have enough power to also be a NAS and a telephony server and a NextCloud installation if you want it to. Then use simple access points for wifi.
FireHOL and FireQOS have a whole well designed special purpose language for sophisticated custom firewall and qos schemes, and they work well. And they can partially solve the whack-a-mole problem using ipsets...
the key to ingress traffic control seems to be to do it in your router, and turn it into egress control on the LAN or on a virtual ethernet. Then the ingress traffic has been through iptables and can get marked easily before shaping on the LAN egress.