Update : cet article est surtout axé sur la bande passante et la relation entre maxpackets et fps. Les commentaires sur la latence ne signifient pas qu'il s'agit du décalage entre ce que vous faites et ce qui se passe. C'est une latence générale entre client et serveur. Ca a une influence, mais dans une moindre mesure.

Il y a quelques temps, je me suis intéressé à l'utilisation de la bande passante sous Q3A, car je venais de remarquer un comportement bizarre selon mes réglages et qui influait grandement sur ma connexion câble. En gros, en passant de maxp=100 à maxp=125, je saturais mon lien. Et parfois, en maxp=100 j'avais de gros lag alors qu'en passant à maxp=70 tout allait pour le mieux. Intrigué, j'ai sorti mon sniffer réseau et j'ai commencé à étudier les échanges client/serveur dans différentes conditions. Fort de ces traces sniffer, j'ai pu démontrer le fonctionnement réseau de Q3. Il est fort probable que vous n'appreniez pas grand chose de nouveau pour la plupart, mais j'ai trouvé utile de partager le résultat et les conclusions de mes analyses.

Résumé : Q3A fait souffrir principalement la partie remontante des connexions des joueurs. En effet, la charge induite par le serveur est relativement faible quelque soit sa configuration, et en plus elle est sur le débit client le plus élevé dans les connexions "hauts débits" actuelles (adsl et câble en 512/128). Les débits annoncés de 512/128 sont des maximums (débit crête), qui sont relativement bien respecté pour l'adsl et très fluctuant pour le câble selon le nombre de personnes sur votre lien. Cela veut dire que vous n'êtes pas à ces débits, mais en moyenne vous êtes sur des débits moyen pas trop loin (à 20% près tout de même). La partie la plus importante pour le joueur est son débit remontant, soit les 128 Kbps. En rnis il n'y a pas de front montant et descendant, c'est le même tuyau pour tous les échanges. Ces personnes doivent donc considérer la somme des deux débits générés par Q3A et voir si cela tient dans leur débit employé (64 Kbps ou 128 Kbps). C'est une approximation mais ce n'est pas trop loin de la vérité. Attention à ces derniers (rnis ou modem), des collisions sont possibles et donc il faut une marge non négligeable pour ne pas subir de problème de saturation du lien. Le fichier excel téléchargeable en haut de cette page permet de faire le calcul réel du débit selon vos réglages, offre aussi une vision de charge pour un serveur en fonction des connexions des clients (et leur nombre) et de ses réglages.

Je possède une connexion câble stable et privilégiée (grenouille.com le montre), et cela m'annonce des débits réels de l'ordre de 26 KBps en upload (208 Kbps au lieu de 256 Kbps crête) et de 116 KBps en download (928Kbps au lieu de 1024Kbps crête).

Ce qui définit vos updates au serveur et votre débit employé pour faire ces updates le plus précisément possible et influer sur votre latence réelle par rapport au serveur, est la valeur de cl_maxpackets. Le problème est que cette valeur est directement en relation avec vos fps. Ainsi, un joueur avec 125fps constant et maxp=100 n'est en réalité qu'à maxp=63, car il ne peut y avoir d'update que sur une synchro d'image. Bref, tout réglage de maxp entre 120 et 63 ne change rien sur votre débit avec 125fps constant. A l'inverse, Q3A est capable de maximiser légèrement votre débit pour des valeurs seuils (typiquement, dans notre cas de figure, maxp=60 est en fait maxp=63 aussi). Bref, avec 125fps constant, le passage de maxp=100 à maxp=125 n'est pas une hausse de 25% de votre débit remontant, mais une hausse de 100% ! Oui, cela double votre débit. D'après mes nombreuses traces, vous passez de l'ordre de 45Kbps à 90Kbps en upload, ce qui est dangereusement près du débit réel en upload des connexions 512/128, d'autant que ces valeurs sont des valeurs moyennes hautes, c'est-à-dire que par moments vous avez plus que ces valeurs, et il suffit d'utiliser des armes gourmandes en ressources pour faire souffrir sa connexion (lg et pg en première ligne).

Attention ! La fluctuation des fps agit directement sur votre débit ! Si vous êtes en maxp=100 avec 125fps fluctuant, vous allez avoir des variations importantes de votre débit qui va non seulement jouer sur la saturation de votre lien, mais aussi sur la latence du jeu par rapport à vous, sans que vous ne le sachiez (sans tenir compte de votre ping qui peut aussi en rajouter !). Comme je l'ai dit, à 125fps et maxp=100, vous consommez en gros 45Kbps en débit remontant. Vous avez tout d'un coup une baisse de fps et vous tombez à 100fps ? Alors vous allez AUGMENTER votre débit !!!!! Vous passez à un débit remontant de l'ordre de 70Kbps. Oui, avec une valeur de maxp inférieure à vos fps, vous êtes à un débit en paquets par seconde multiple de vos fps, en baissant vos fps, vous vous rapprochez de votre valeur maximale de débit. En conclusion, pour maxp=100 il ne faut pas être à plus de 100fps. A 125fps, il n'y a pas d'écart entre un maxp=60 et un maxp=100. Si vos fps fluctuent entre 125 et une valeur inférieure, avec maxp=100 vous allez à chaque baisse de fps augmenter votre débit et potentiellement saturer votre lien (rnis, câble poussif, plaque adsl de seconde zone...) en plus de changer votre feeling de jeu. Un joueur qui fluctue entre 125fps et 80fps verra de grande variation. Avec maxp=100, il passera de 45Kbps en upload (125fps) à 56Kbps (80fps) à 70Kbps (100fps).

Il apparaît aussi que pour des compétitions en LAN, il est souhaitable de monter le sv_fps des serveurs à 60 ou plus, et que dans ce cas, il faut autoriser le maxpackets 125. Un lien 10Mbps Full Duplex par joueur est parfait, et un serveur se contentera largement d'un lien 100Mbps Full Duplex. Attention aux cartes employées pour les serveurs, certains chipsets sont déplorables. 3Com, Intel ou Realtek sont préconisés et Xircom est à éviter.


I. Notions de base

Q3A fonctionne en mode client/serveur. Le joueur (client) envoi à intervalles réguliers des informations au serveur, et celui-ci en fait de même vers chaque joueurs.

Les paramètres permettant d'influencer l'utilisation de la bande passante, côté client, sont :

snaps
rate
cl_maxpackets
com_maxfps

Côté serveur, il est possible de limiter les valeurs des clients, et pour influencer l'utilisation de la bande passante, le paramètre est :

sv_fps


Sur quoi cela va-t-il jouer ?

Comme l'avait montré Twouan précédemment, le fait de jouer avec les paramètres serveur/client influence la latence générale du jeu. Au delà de ça, il faut bien saisir ce que cela implique sur votre débit réel et donc ce qui est possible d'utiliser selon votre connexion.

II. Le serveur

Sv_fps correspond au nombre de paquets par seconde envoyés par le serveur vers les joueurs, indiquant les différentes positions de chacun, les tirs, les items... à cet instant T. Par défaut, et majoritairement, un serveur à pour valeur 20. Parfois on trouve des serveurs en 25 voire 30.

20 informations par seconde, cela veut dire que - de base - il y a un décalage de 1/20 sec (50ms) entre chaque update du serveur (et donc entre ce que vous voyez et la réalité). En augmentant la valeur de sv_fps, on réduit le temps de latence : 1/25 = 40ms, 1/30 = 33ms ... 1/60 = 17ms. En LAN, il sera préférable de monter cette valeur (les démos seront d'autant plus grosses).

De fait, on a une image du jeu beaucoup plus réaliste et il devient magiquement plus simple de toucher, d'éviter, d'anticiper... mais cela a un prix : le débit engendré.

Avec sv_fps = 20, le serveur envoi 20 pps (paquets par seconde) à chaque joueur. Selon ce qui se passe, chaque paquet aura une taille comprise entre 90 octets et 400 octets, en dehors de grosses pointes assez rares d'après mes traces sniffer. Prenons une taille moyenne de 200 octets (réaliste en tdm ou ctf). Cela veut dire que chaque joueur verra une consommation de sa bande passante descendante de 20*200 = 4 000 octets/s = 32 000 bits/s = 31.25 Kbps.

Le serveur, de son côté, consommera une bande passante en upload de (nbre de joueurs)*31.25 Kbps. Pour un match de TDM, ça fait un minimum de 8*31.25 = 250 Kbps. Si on rajoute un admin et des coachs, on monte à 11*31.25 = 343.75 Kbps.

III. Le joueur

Le joueur doit avant tout se mettre en rapport avec le serveur. Si ce dernier possède un sv_fps spécifique, il va devoir mettre son snaps à au moins cette valeur, voire plus. La rumeur veut qu'il faille avoir une valeur qui divise 100 avec une valeur finie (100/snaps = valeur finie : 2, 2.5, etc.). La valeur du snaps va influer sur l'interpolation entre deux updates du serveur.

Viens ensuite la valeur du rate, contrôlé par le serveur avec les commandes maxrate et minrate. Cette valeur correspond au débit maximum du joueur pour l'envoi des données (en octets/s) vers le serveur. Du moins c'est ainsi que je le comprend, mais les tests réalisés pour le moment ne montrent pas l'influence de ce paramètre. Tout commentaire est le bienvenue.

Enfin, l'aspect le plus important pour le client est la commande cl_maxpackets. Il s'agit du nombre de paquets par seconde que le client va tenter d'envoyer au serveur. Sa valeur maximale est de 125. Toutefois, cette valeur est aussi en relation avec les fps (nombre d'images par seconde) du joueur ! Depuis osp 1.02, il existe une valeur maximale du framerate, qui est de 125 depuis la version 1.03 d'osp.

Reprenons le mécanisme général d'une partie.
Le jeu se passe en continue sur le serveur. Celui-ci possède la réelle position de chaque entité (items, tirs, position des joueurs, projectiles...), il connait très régulièrement l'évolution des mouvements et actions de chaque joueurs par une remontée d'informations de ceux-ci, fréquence qui dépend de leur réel cl_maxpackets (100=10ms, 63=16ms, 125=8ms...). Le client (joueur) possède pour sa part une info antérieure de ce qui se passe. Il reçoit du serveur l'état de la partie à intervalles réguliers dépendant de la valeur de sv_fps du serveur (20=50ms, 25=40ms...). Il y a un décalage d'une info entre le serveur et le client. Le joueur reçoit à T l'image exacte du serveur à T-1, donc avec déjà 50ms de retard (si sv_fps=20). Entre temps, le joueur interpole les déplacements de tout ce qui bouge dans la partie, et le repositionne bien à chaque réception d'infos. Plus vous envoyez d'infos au serveur (maxp réel élevé), plus vous réduisez votre latence générale et plus vous avez de chance de tuer/toucher/attraper un item par rapport à un autre joueur qui, lui, envoit moins d'infos.

Soit un serveur classique avec sv_fps = 20.
Un client avec rate = 10 000, snaps = 40, cl_maxpackets = 100 et 125 fps constant.

Toutes les 50ms (1/20 sec) le serveur update les infos côté client en envoyant un paquet. Le client va de son côté envoyer des infos au serveur " théoriquement " 100 fois par seconde (maxp = 100), soit toutes les 10ms. Donc, logiquement, un échange classique se fait ainsi :

Temps 0.000 0.010 0.020 0.030 0.040 0.0501 0.0502 ...

Source Serveur Client Client Client Client Serveur Client ...

Destination Client Serveur Serveur Serveur Serveur Client Serveur ...

Or, nous avons dis que les fps intervenaient et limitaient la valeur de pps (paquets par seconde). A raison de 125fps, nous avons une update possible toutes les 1/125sec = 8ms, or nous ne pouvons envoyer un paquet que toutes les 10ms. Que se passe-t-il ? On perd des paquets, tout simplement... et on en perd 1 sur 2 ! Le premier est synchro, la seconde fenêtre est à 8ms, le client n'a rien à envoyer, il attendra alors le 2eme tour (2*8=16ms) pour l'envoyer, et donc il sera en retard au troisième tours (24ms) car il sera prêt à 16+10=26ms, il devra donc attendre le tour suivant (4*8 = 32ms), etc.

Donc, nous n'allons réellement envoyer qu'à un maxp à 62.5 (soit 62 et 63 pps). Bref, on arrive à des updates toutes les 1/62.5sec = 16ms... si vous avez 125 fps constant ! Vous avez une petite configuration et parfois vous tombez à 80 fps ? Alors vous n'avez plus que des fenêtres d'envois de données à 1/80sec = 12.5ms. Intéressant, cette valeur est supérieure à la valeur induite par maxp=100 (10ms)... certes, vous n'allez pas pourvoir suivre vos 10ms espérées, mais vous passez tout de même à 12.5ms... mais ? de quoi ? chaque 12.5ms une update ? Mais c'est mieux que les 16ms en étant à 125 fps ?????

Oui. Vous êtes à un équivalent de maxpackets = 80. Attention, ce n'est possible QUE parce que vous avez maxp > 80 (fps). Avec maxp=60, le changement serait tout autre.

Pardon ? Je m'explique.

Votre réelle fréquence d'envoi au serveur est un diviseur de vos fps donnant un entier. Si vous avez un maxp supérieur ou égal à vos fps, vous envoyez (nbre de fps) pps. Si vous avez moins, vous envoyez (nbre fps)/maxp = x, x devient y l'entier supérieur à x (apparemment si x est très proche de l'entier inférieur, il devient celui-ci, q3 semble capable d'anticiper son envoi de paquet : x = y dans ce cas) et vous envoyez alors (nbre fps)/y = z pps.

Exemple : 80 fps et maxp=60, ça donne 80/60 = 1.5, donc vous allez utiliser la valeur entière supérieure à 1.5, c'est-à-dire 2, soit un update de 80/2 = 40 pps ! Avec 125 fps, vous auriez alors : 125/60 = 2.08. Or, 2.08 est très proche de 2, q3 va être capable de gérer ce léger écart, en se réajustant lorsque le cumul de l'écart sera trop grand (en perdant sur un tour un envoi de paquet), et donc on a 125/2 = 62.5 pps (62 pps puis 63 pps, puis 62 pps...).

On en déduit que le mieux, en étant avec maxp = 100, c'est d'avoir 100fps constant ! Bon, d'un autre côté, vous ne passez plus tous les sauts.

Bref, l'apport du cl_maxpackets à 125 est énorme, bien plus qu'on ne le croit puisqu'il va permettre de réellement bénéficier d'une update du serveur plus précise, tout en gardant le bonheur des tricks dépendant des fps. Il est même probable qu'il multiplie par deux vos updates si vous avez un PC pas trop lent.

IV. Quel est l'impact sur ma connexion ?

Tous mes dires s'appuient sur des traces sniffer que j'ai réalisé dans différentes situations, allant de moi tout seul sur un serveur, au match de ctf 5v5 avec GTV et 3 spec, en passant par des duels et des 2v2. Les résultats sont incontournables, avec maxp=100, il est préférable d'avoir au maximum 100fps, au-dessus de cette valeur vous passez à l'équivalent de 62.5 pps !

Les traces sniffer montrent aussi la taille moyenne des infos échangées entre un client q3 et un serveur.

La taille moyenne haute d'un paquet client->serveur est de 90 octets (720 bits). En fait, cela varie entre 70 et 100 octets, mais c'est très largement en-dessous de 85 octets la majeur partie du temps.

Concernant le serveur, c'est plus délicat car cela dépend de nombreux éléments. Sur une partie de 20mn en CTF, à 5v5 avec 3 spec et une GTV (merci Bigfoot), j'arrive à une moyenne haute de l'ordre de 200 octets (1600 bits), sachant qu'il y a régulièrement des montées à 300 - 400 octets, voire même quelques rares pics à 1024 octets ! Mais c'est plus généralement autour de 110 - 180 octets, et un peu dans les 200 - 280 octets.

Bref, en acceptant un petit coup de lag et un poil de pl très rare, on peut partir sur un raisonnement à base de 90 octets et 200 octets.

Le serveur envoit sv_fps*200 octets/s au joueur.

sv_fps 20 25 30

Kbps 31.25 39.06 46.87

Le client va envoyer maxp*90 octets/s au serveur en fonction des fps.

Fps = 125

Maxp 125 100 60 50

Kbps 87.89 43.94 43.94 29.29

Fps = 100

Maxp 125 100 90 60

Kbps 70.31 70.31 35.15 35.15

Fps = 80

Maxp 125 100 80 70 60

Kbps 56.25 56.25 56.25 28.12 28.12

Donc, du point de vue joueur, on consomme au pire des cas 46.87 / 87.89 Kbps si on a une connexion avec deux fronts (type adsl, ls, cable) et sinon 134.76 Kbps autrement (rnis, modem).

Le serveur, de son côté, utilise au pire :

TDM + 2 coach + 1 admin + 1 gtv : 12*46.87 + 12*87.89 = 1617.12 Kbps répartis en download/upload ainsi : 1054.68 / 562.44 Kbps

CTF + 2 coach + 1 admin + 1 gtv : 14*46.87 + 14*87.89 = 1886.64 Kbps répartis en download/upload ainsi : 1230.46 / 656.18 Kbps

 

Update : As arQon rightfully told me, this article is mainly about bandwidth usage and the relationship between maxpackets and fps. Comments on latency are not about the delta between a player action and a reaction in the game, it's about a general game latency between server and client. This may change a bit things for a client, but way fewer.

Some time ago, I decided to get a closer look at Q3A bandwidth usage, because I was experiencing some weird connection troubles depending on my net settings, despite I'd moved from isdn to cable. In fact, upping my cl_maxpackets (maxp) from 100 to 125 was timing out me all the time. Sometimes, even with maxp=100 I had some big lag while reducing to maxp=70 everything just worked well. I was wondering why, so I used my network sniffer and went in all the traces I got to understand q3a bandwidth usage. I looked at the traces in various environments. Now, I hope I have a good understanding of how it works, so I've decided to share my analyzes and conclusions with the community. Maybe you'll learn nothing from it, maybe not.

Summary : On a player side, Q3A is stressing a lot the upload link. Indeed, the server's load for a client (player) is usually not very much and is on the download link, the usual bigger one for players using nowadays high speed internet connections such as cable or adsl (512/128 Kbps). Those speeds of 512/128 or whatever else are maximums (peak speed), if this is quite well followed by adsl connections, this is not necessary the case for cable's one. However, for both, usual high average speeds are not too far from those announced (in a range of 20%). The most important speed link to care for a player is the upload one, that means the 128 Kbps. On isdn or modem, there's no download and upload speed, they're mix all together. Players with those connections have to watch for the total of the load generated in both ways and see if this is compatible with their speed. This is an approximation but it's not very far from truth. Be careful, however, to keep a margin because of possible collisions for that type of connection. The excel file downloadable at the top of this page is useful to calculate the real throughput in consideration of your settings, it gives also an estimation of the server's load in consideration of the players' settings (and their number) and server's settings

I have a good and quite stable cable connection (as grenouille.com shows), and this gives my real speed : 26 KBps for upload (208 Kbps instead of 256 Kbps) and 116 KBps for download (928 Kbps instead of 1024 Kbps).

What's defining the updates of the server from your side and give the bandwidth needed for those updates and also changing the latency of the game from your POV, is the value of cl_maxpackets. Problem is that this value is directly in relation with your framerate. So, a player with a constant 125 fps framerate and maxp=100 is, in reality, only at maxp=63, because an update can only be synchronized with a new frame. So, whatever is your setting of maxp between 63 and 120, this have no modification of your bandwidth utilisation, if you have a constant 125 fps. On the other side, Q3A is capable of upping a bit your throughput for threshold value (typically, in our case, maxp=60 is in reality maxp=63 too). So, upping maxp to 125 from 100, with constant 125fps, is not 25% more bandwidth used in upload, it's 100% more ! Yes, this is doubling your bitrate. Considering my traces, you go from 45Kbps to 90Kbps in upload used, a critical value for connections of 512/128 because it is very close to the real upload bitrate you have. Keep in mind that those value I'm giving are high average, so there's sometimes bigger values capable of killing your link (especially high bandwidth weapons like lg and pg).

Be careful ! Variations of your fps acts directly on your bitrate ! If you have maxp=100 with 125fps non constant, you'll have some very important variations of your bitrate, which can saturate your link, but also play on the general game latency from your pov, without warning you (without considering your ping variation that can add more variation !). As I said, at 125fps and maxp=100, you're using 45Kbps in upload. You have a sudden loss of fps and you drop to 100fps ? Then you will UP your bitrate !!!! Your upload bitrate is growing to 70Kbps and you can reduce your general latency of a max of 6ms. Yes, with a value of maxp lower than your fps, you have a packets per second rate which is a multiple of your fps. So, by lowering your fps, you get closer to your max pps bitrate possible. In conclusion, with maxp=100 you should not have more than 100fps. With 125fps, there's no change between maxp=60 and maxp=100. If your fps goes from 125 to some lower value, you can raise your bitrate and possibely kill your upload link (welcome isdn, poor cable and adsl connections...). In addition, you will also change the game feeling. A player with his fps going from 125 to 80, for example, will see a big change. With maxp=100, the player will use 45Kbps in upload (125fps), or 56Kbps (80fps), or 70Kbps (100fps).

So, it is highly recommended for LAN tournament to up the sv_fps setting of servers to 60 or more, and also let people use maxp=125. A 10Mbps Full Duplex link is enough for a player while a server will have plenty of bandwidth with a 100Mbps Full Duplex link. I personnaly recommend to avoid xircom NIC because they seem to have trouble getting in high bandwidth usage, will 3Com, Intel, Realtek... are usually good.

sv_fps 20 25 30

Kbps 31.25 39.06 46.87

The player will sends maxp*90 octets/s to the server depending on the fps.

Fps = 125

Maxp 125 100 60 50

Kbps 87.89 43.94 43.94 29.29

Fps = 100

Maxp 125 100 90 60

Kbps 70.31 70.31 35.15 35.15

Fps = 80

Maxp 125 100 80 70 60

Kbps 56.25 56.25 56.25 28.12 28.12

So, in the player side, we use in worst case 46.87 / 87.89 Kbps with a full duplex connection (adsl, ls, cable) or 134.76 Kbps otherwise (isdn, modem).

The server will need :

TDM + 2 coach + 1 admin + 1 gtv : 12*46.87 + 12*87.89 = 1617.12 Kbps split in download/upload like it : 1054.68 / 562.44 Kbps

CTF + 2 coach + 1 admin + 1 gtv : 14*46.87 + 14*87.89 = 1886.64 Kbps split in download/upload like it : 1230.46 / 656.18 Kbps