Comment lire les valeurs de net_graph 3

exemple de net_graph 3

1. Les fps c’est le nombre d’images par seconde que votre machine affiche. Cette valeur est limité par le fps_max de votre machine ou bien par le taux de rafraîchissement de votre écran.

2. Le ping c’est:

• le ping netgraph représente  l’aller-retour des paquets envoyés, sans inclure les délais de calcul de tickrate ou updaterate
• latence scoreboard (ping) c’est simplement le temps de l’aller des paquets
• la commande rcon status, bah en fait ce n’est pas très clair ^^

IN c’est que vous (votre machine) reçoit, de la part du serveur

OUT c’est ce qui est envoyé par vous (votre machine) au serveur,

IN et OUT contiennent plusieurs composants, de gauche à droite:

3. La taille du paquet en Bytes qui en cours d’envoi et de réception

4. La moyenne de KiloBytes par seconde qui est en cours d’envoi ou de réception des données de jeu

5. La moyenne d’updates qui sont reçus ou envoyés par seconde

Si vous multipliez 3. par 5. et divisez par 1000, vous aurez une bonne idée de la valeur de 4. (plus ou moins car 4. et 5. sont des moyennes). En utilisant les chiffres que l’on voit ci-dessus, pour IN on obtient (154*102,4/1000)=15,7696 … on voit que la valeur montrée ci dessus du net_graph 3 étant 15,16, on tombe presque dessus.

Le nombre d’updates de IN reçus par le client par seconde (controllé par cl_updaterate) sera dans la plupart des cas égal au tickrate du serveur, mais ne dépassera jamais:

• le cl_updaterate du client
• le sv_maxupdaterate du serveur
• le tickrate su serveur ET du client qui sont toujours égales, vu que le client utilisera le même tickrate que le serveur auquel il est connecté

Le plus petit de ces 3 chiffres determinera le chiffre que vous voyez en update par secondes reçus par le client.

Si jamais la bande passante du client ET/OU du serveur n’est pas suffisante, ou est limitée par le rate du client ou le sv_maxrate du serveur, alors le client ne verra pas le updates de IN reçus pas le client par seconde équivalents au tickrate du serveur. Dans ce cas, le client verra du choke.

Si le serveur n’a pas assez de ressources CPU pour maintenir les fps du serveur au dessus du tickrate du serveur, le client ne verra pas les updates IN reçus par le client par seconde équivalents au tickrate du serveur. Ceci est un autre cas ou le client verrait du choke.

Le nombre d’updates de OUT envoyés par votre machine par seconde (contrôlé par cl_cmdrate) ne dépassera jamais:

• le cl_cmdrate du client
• le tickrate du client/serveur
• les fps du client

Le plus petit de ces 3 chiffres determinera le chiffre que vous voyez en update par secondes envoyés par le client

Il se peut que les updates OUT envoyés par votre machine par seconde dépassent les fps, mais en réalité, ce n’est pas le cas. C’est simplement que les données net_graph 3 ne sont pas souvent parfaitement synchronisés et dû au fait que les chiffres en 4. et 5. ci-dessus ne sont que des moyennes. Il se peut aussi que l’on observe une erreur dans les net_graph 3 qui arrive lorsque la moyenne des updates que vous recevez paraît plus grande que les sv_maxupdaterate, tickrate du serveur et le cl_updaterate du client, qui étaient tous à 100 lors de la prise du screen ci-dessus, malgré l’affichage que l’on voit.

6. Loss sont les paquets perdus à cause de soucis sur le réseau, soit avec votre fournisseur d’accès, soit entre votre fournisseur d’accès et votre machine, soit du fournisseur d’accès de votre serveur. Si vous avez du loss, vous aurez probablement du choke. En d’autres termes, n’essayez pas de résoudre des soucis de choke si vous avec du loss. Les soucis de loss ne peuvent que se régler directement avec votre fournisseur d’accès, l’administrateur de votre machine ou avec votre GSP. Si tout va bien pour d’autres machines, c’est que le réseau de votre GSP fonctionne bien.

7. Le choke correspond simplement au fait que le serveur essaye de vous envoyer des informations mais qu’il n’y arrive pas. Les raisons du choke ne sont pas simple à comprendre, à diagnostiquer ou à réparer, mais ceci fera l’objet d’un autre article.

J’espère avoir été clair dans mes explications, et vous invite une fois de plus à laisser vos remarques et commentaires.

Comprendre le ping, le rate et les fps

Ping

Définition “officielle” du ping:

Ping est le nom d’une commande informatique (développée par Mike Muuss) permettant d’envoyer une requête ICMP ‘Echo’ d’une machine à une autre machine. Si la machine ne répond pas il se peut que l’on ne puisse pas communiquer avec elle.

L’analogie avec le ping-pong est que cette commande envoie une trame (le Ping) et attend son retour (le Pong). Selon la réponse on connaît l’état de la machine distante.

Cette commande réseau de base permet d’obtenir des informations et en particulier le temps de réponse de la machine à travers le réseau et aussi quel est l’état de la connexion avec cette machine (renvoi code d’erreur correspondant).

In-game, voici plusieurs utilisations du ping:

1. Scoreboard ping – un aller simple entre votre machine et le serveur
2. Net-graph ping – un aller-retour entre votre machine et le serveur (moins les retards dues au traitement des informations)
3. Latence – cf. 2, mais pas à 100%, les retards dues au traitement des informations est exclu.

Définition “gamer” du ping:

Le ping c’est ce que font les sous-marins, hein ? Et bien c’est le même principe ! Afin de vous donner une idée de combien de temps (exprimé en “ms”, millisecondes) de communication il y a entre vous et votre serveur de jeu, le serveur vous indique un “chiffre de ping”, qui exprime le temps mis a vous envoyé un paquet d’info puis à le récupérer. 1000 ms = 1 seconde

Votre ping dans le jeu et légèrement différent, parce qu’il n’y a pas cette aller-retour qui est effectué – les “paquets” qui sont envoyés contiennent des informations que chaque ordinateur doit déchiffrer pour ensuite renvoyer une paquet en réponse. Un program normal de ping ne fait qu’envoyer le plus simple des paquets et récupère le plus simple de paquets.

En d’autres termes, si vous “pingez” un serveur web qui se situe au même endroit que le serveur de jeu, vous obtiendrez un plus petit ping (en ms) que celui obtenu en jeu. C’est déjà important de comprendre ça.

Plus votre ping est grand, plus votre jeu sera moisi. Plus vous êtes loin du serveur, plus vous avez de chance à ce que les informations entre vous et le serveur soient décalées (ie: votre adversaire ayant un meilleur ping peut vous tuer avant que vous ne vous en rendiez compte). Cela fonctionne peu comme la différence entre un coup de fil à l’étranger (décalage des voix) et un coup de fil à votre voisin, le temps de réponse varie en fonction de la distance.

Le ping peut aussi être appelé latence. La latence signifie le décalage (toujours en ms) entre votre machine et le serveur.

Pourquoi est-ce que mon ping change constamment ?

Simplement parce que le ping ne dépend pas QUE de la distance ! Il est aussi soumis à d’autres influences telles que la vitesse CPU, les relays internet, les échanges, les utilisateurs sur votre dslam – un paquet de facteurs. Le ping affiché est une moyenne lors de la dernière vérification, il est constamment mis à jour.

RATE

Définition “officielle” du rate:

Le montant maximum de Bytes Par Seconde que le client va demander au serveur. Le rate côté client prend le dessus sur celui du serveur (sv_maxrate) si sa valeur est plus faible que ce dernier. b = bit, B = Byte, il y a 8 bits dans un Byte

Définition “gamer” du rate:

Disons que le serveur veut vous envoyer 100 updates par seconde, chaque update contenant 200 Bytes. 100 x 200 = 20,000 Bytes. Maintenant, disons que vous avez une connexion adsl pourrie, ce qui veut dire que télécharger à cette vitesse (20,000 Bytes / seconde) serait impossible. Cela signifie donc que vous perdriez des données envoyées par le serveur. En diminuant votre rate à 10,000, le serveur ne tentera plus de vous en envoyer 20,000, donc plus de perte de données. 

Est-ce que cela signifie que vous ne pouvez pas jouer ? Et bien non, pas vraiment. Le jeu autorise ce phénomène et sur votre machine “remplacera” les données perdues. Exemple: un tonneau qui roule – le serveur va vous envoyer la position A et la position C, et votre machine va vous montrer le tonneau qui roule entre ces deux points, plutôt que d’attendre que le serveur lui fournisse le point B intermédiaire. Le serveur va ensuite procéder à la vérification du point B, pour éventuellement réparer l’interpolation effectuée par votre machine. 

Donc le RATE est très important afin d’éviter de “boucher” votre connexion internet et afin de rendre votre jeu plus fluide. Il n’y a donc pas d’intérêt à essayer de recevoir 20,000 Bytes/seconde de la part du serveur si cela va empêcher votre machine de retourner les informations correspondantes au serveur ! Comment savez-vous si tout fonctionne ? Et bien commencez pas le rate par défaut, et augmentez-le jusqu’à ce que vous voyez un fable choke régulier et un faible loss régulier dans votre net_graph. Le minimum étant en règle généralet 5,000 et le maximum sur un serveur avec un tickrate de 100 est de 30,000.

FPS

Définition “officielle” des fps:

fps sur le net_graph représente le nombre d’images pas seconde de votre machine (et pas le serveur) . Les fps sont limités pas le fps_max du client, ou bien par la fréquence de rafraîchissement de votre moniteur si le vertical-sync est utilisé.

Définition “gamer” des fps:

fps (frames per second) est en fait le nombre d’images que votre moniteur affiche pas seconde pendant que vous jouez. Plus ce chiffre est grand, plus votre jeu sera fluide. Vos fps seront limités pas la vitesse de votre machine (ceci est une évidence) mais aussi par le taux de rafraîchissement de votre écran (Hz = FPS).

Si le taux de rafraîchissement de votre écran est de 85Hz, alors le fait d’utiliser vsync limite vos fps à 85. Cela veut donc dire que votre carte graphique affichera seulement 85 images par seconde. Si vous désactivez vsync, votre carte graphique pourra donc afficher plus de 85 images par seconde. Néanmoins, cela est complètement inutile, puisque votre moniteur ne peut en afficher que 85 (puisqu’il est de 85Hz). Si vous essayez de lui envoyer plus de 85 images par seconde, votre carte graphique servira de tampon et oubliera certaines images afin que l’écran n’en reçoive que 85. Au final, à plus de 85 fps (sur votre netgraph), les fps que vous voyez sont limités par votre écran.

Le nombre de fps qu’un oeil humain peut discerner est variable en fonction de l’acuité visuelle de chacun, mais je ne vais pas rentrer dans ce débat. Néanmoins pour vous donner une moyenne, à partir de 60 fps, votre oeil ne distingue plus de différence (entre 30 et 60 on peut remarquer une légère amélioration dans le fluidité). Pour en savoir plus, rdv ici.

Pour en revenir aux jeux, vous pouvez contrôler combien de fps votre moniteur affiche de deux façons:

In-game, la commande est fps_max 100 ou 200, etc …

Votre écran possède un tau de rafraîchissement. Vous pouvez les trouver en ouvrant de Panneau de control > Affichage ou sur la notice de votre écran. Il n’est pas recommandé de demander à votre écran d’afficher plus que ce qu’il est capable d’afficher.

Vous pouvez forcer le taux de rafraîchissement de votre écran (le taux de rafraîchissement c’est les fps) avec certaines applications ou vous pouvez simplement activer ‘Vertical Sync” dans les options de vos jeux.

 

Voilà pour cette petite introduction au fabuleux monde de la config des gamers. Restez connectez, d’autres articles viendront étoffer cette base de connaissances. N’hésitez pas à poser vos questions ou remarques en commentaire.