I would like to clarify a point for the purpose of understanding ... visibly the DSCP selector for gaming recommends CS4 with as priority discharge AF41, AF42, AF43 (respectively low medium and high) knowing that I play mainly fifa (oscillates between 72 and 120 packets) and call of Duty (360 to 1300 packets) I find myself with either a game more responsive with one rather than the other depending on the rate of discharge ... is there a way to vary the drop rate depending on the game in question? It is known that a drop rate too high causes a lag, especially fifa very sensitive to variation.
As before, DSCPs by themselves are really just numbers/bit-patterns any meaning they carry comes from how they are treated (what the IETF calls per hop behaviour or PHB).
So assuming you use cake with diffserv4:
/* 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)
In that context AF41-3 will map a packet into "Streaming Media"/Video, while CS4 will map packets into "Latency Sensitive"/Voice. However Video gets up to 50% of capacity at high priority, while Voice only gets 25%.
So if a game like CoD goes up to 1300 packets/second this will result in bursty traffic with an average worst-case (assuming maximally large packets) rate of:
(1300 * 1538 * 8) /1000^2 = 15.9952 Mbps
These will likely cluster around tick times so transiently the rates will be higher.
Therefore I would really only:
a) play one game at a time in your network
b) map that game's packets into the Video tin (e.g. by marking CS3). So you have the highest chance of getting priority treatment.
Are you talking about the DSCPs or something related to the games? Because if you only prioritize the game packets, the "amount" of priority they get over besteffort traffic is identical independent on wether they map to Voice or Video tin, all that matters is that that tin has higher priority than the rest of the traffic.
No, not in sqm/cake. You can increase the interval (cake's rtt N parameter with N being the interval in milliseconds) which will increase the time cake takes to engage in dropping and also increases the target parameter, which measures the permissible standing queue, but increasing that will make cake respond sloppier for all tins.
And just to clarify for my own understanding as well, all of this DSCP stuff only matters where the connection is completely saturated right? Because for all the many high bandwidth connections non saturating traffic is going to mean tinning doesn't make a difference, right?
Essentially yes, however sorting flows into tins has a (tiny) cost associated with it. If the current traffic stays below capacity (even transiently) there will be no queue developing and hence packets are essentially transmitted immediately. If some transient queues develop DSCPs/diffserv-modes can affect the order of the packets (higher priority packets have a higher probability of being sent out quicker) but that is what prioritization is all about; my point is even if the average rate stay below capacity there might be bursts of packets that engage cake's priority system (such short bursts however are unlikely to trigger cake into dropping or marking packets, for that the queue's sojourn time for a hash bin needs to be persistently over target for a full interval, with interval defaulting to 100ms that requires transient queues >= 100ms, or "not-so-transient" queues).
Hope this helps.
For these temporally localised bursts would that need to be effective saturation but just over the very short time of the localized burst? And if this doesn't result in dropping or marking (what does marking involve?) does the prioritisation still make a difference?
So in essence then is the point that even with average traffic being below max capacity there could well be localized periods rendering prioritisation important?
Yes if the kernel dumps a few packets into the qdisc (to make something up, because a whole WiFI aggregate with a bunch of packets reached the kernel and needs to go out to the internet) this process can operate well above the interface's egress rate, hence small bursts can develop even if the average rate stays below the line rate (tangent: an ethernet interface is either 100% busy or 0 percent, what changes is effectively the duty cycle).
Marking, is something cake does if a packet carries either the ECT(0) or ECT(1) bit pattern in the 2 bit ECN field in the IP header, it then changes either pattern to CE (congestion experienced), following rfc3168 cake will essentially mark a packet following the same rules it uses for dropping, except packets that promise to use ECN will be marked instead of dropped. (Not fully true, cake's BLUE component ramps up a hard dropping probability depending on the queue size of a hash bin, but that is slow and will basically only engage for unresponsive flows). So in the context of cake marking or dropping will start if for a give hash bin the minimal sojourn time over the last interval duration stayed above target.
Let's assume that we either have a standing queue in total below target or above target but not yet for a full interval, the fact that we have a queue means we likely have more than one packet, and once we have more than one packet, both the flow-queueing and the priority scheduler (actually a single combined scheduler) will do its thing an potentially re-order packets. Which is the whole reason for this scheduler to exist.
If the small latency increases introduced by potentially having to wait for a few packets are that important then yes prioritisation becomes important.
However flow-queuing by itself already helps a lot here, in the old FIFO days if a single bulk flow dumped say 100 packets into the queue your VoIP packet entering the queue just behind this batch, will be queued until all 100 packets have been transmitted, with flow queueing it will be more like you having to wait for one or two of these 100 packets to be transmitted before your VoIP packets gets its turn.
Unless the number of concurrently active flows is really large (in relation to the egress rate) flow-queueing is a surprisingly simply yet helpful approach. Back in the FIFO days all one could do was build priority hierarchies to make sure the VoIP packet got sent out quick enough (with enough pitfalls like the driver internal queue being a FIFO itself).
I am not saying that prioritization hierarchies are not useful even in combination with a flow-queueing scheduler, just that they are not half as essential as they often where in the past. And to be explicit, sqm-scripts does not aim to be the best traffc-shaper/AQM for all, but rather a simple (hah, I can dream) to configure shaper+AQM solution "for the rest of us" (that aims to be "good enough" by default).
1 Like
I understand that the selector is DSCP CS4 / behavior flash / override AF4
CS3 flash and Af3...
I thought that the cs4 in case of bufferbloat drop on AF4... low medium or high why would it go on the flash box instead of staying on override flash ???
I'm talking about the cake script and diffserv4... the current rules will give priority to a COD game instead of Fifa and vice versa because they don't have a similar package sequence!
Maybe we could follow your lead and have you post a french version of your question (as well as a translation) then I can use autotranslate from french to german cutting out the middleman?
Are you actually playing both COD and fifa at the same time? Or are you reporting that cake works better for one or the other?
Ich spreche von script cake und diffserv4... die aktuellen Regeln wĂŒrden ein COD-Spiel anstelle von Fifa priorisieren und umgekehrt, weil sie keine Ă€hnliche Paketsequenz haben!
Ja cake funktioniert fĂŒr das eine Spiel besser als fĂŒr das andere
Nah, I am fine with translating to German, my idea was to improve the joy of our conversation by letting you write in french instead of "forcing" you to write in english. 
Which game works better with cake the 1300 pps CoD or FiFa and is FiFa still using TCP?
An Englishman, a German, and a Frenchman...
... the best one involves lashes and pillows.
1 Like
HonnĂȘtement fifa je sais pas pourquoi mais il nây a pas de tcp câest certain ..
câest vraiment udp port 3659.
Les paquets comparer Ă dâautre jeu sont vraiment petit, exemple le dĂ©but de la partie indique des paquets de 72 puis en fin de partie 122 maximum âŠ.
Sur COD selon les Maps et le nombre de joueurs ça varie entre 300 et 1302
Non pas en mĂȘme temps , je joue Ă un jeu et une heure aprĂšs a un autre .. quand un va mieux lâautre va pas impossible dâavoir les 2 jeux et tout les jeux qui fonctionne normalement .. jâai toujours cette latence qui parfois dĂ©cide de me laisser jouer normalement mais câest extrĂȘmement rare ..
MĂȘme en supprimant la quasi totalitĂ© du bufferbloat il nây a aucune diffĂ©rence en jouant ..
You guys didnt understand each others on the "1300 packets". He meant 1300 bytes packets not 1300 pps.
At least i think so..
Thanks, you are right. I just translated from french and I totally misunderstood the issue.
I actually do not think that sqm/cake care too much about packet size, qosify however does offer behaviorally defined rules that might take packet rate and packet size into account.
1 Like
Ok je comprend mieux pourquoi jâai la sensation que qosify est plus adaptĂ© Ă fifa et cake Ă COD.
Oui par exemple avec wireshark Je vois DSCP cs4, lenght 122 et pkts 122
The preferred language in the OpenWrt forum is english.
When writing in your native language, please always provide an english translation.
This way other users all around the world can take part in the discussion and possibly benefit from the outcome, without having to use a translator.
Thanks! 