Mesure en cours…
Le verdict apparaît après quelques secondes de mesure.
Comparaison avec les autres tests vers ce serveur…
Le test ci-dessous tourne déjà, à 64 Hz, le tick rate de Counter-Strike 2. Aucun clic, aucune inscription.
Mesure en cours…
Le verdict apparaît après quelques secondes de mesure.
Comparaison avec les autres tests vers ce serveur…
Supprimer vraiment tous les résultats ?
| Date | Durée | Ping moy. | Jitter moy. | Perte de paquets | Action |
|---|
Tu peek, tu vois l’adversaire, tu tires — et tu meurs quand même. Une demi-seconde plus tard, ton personnage est trois mètres en arrière.
Ce n’est pas ton aim. Le rubberbanding, c’est le serveur qui corrige ta position parce qu’il n’a rien reçu de toi pendant un moment ; les balles qui ne comptent pas sont des actions jamais arrivées. Les deux viennent de paquets perdus et du jitter, pas du débit. C’est pour ça que ta ligne peut réussir tous les speedtests et rendre CS2 injouable : CS2 envoie de petites mises à jour à rythme fixe et ne renvoie jamais une mise à jour perdue.
Ce que ce test envoie : 64 paquets par seconde de 250 octets — le rythme de Counter-Strike 2, pas un ping générique. vérifié
Valve fait tourner les serveurs officiels de CS2 à 64 ticks ; le sub-tick ne fait qu’horodater les actions entre deux ticks.
Laisse la mesure tourner au moins 60 secondes. Voici ce que chacun des trois chiffres signifie pour ce jeu.
Pour CS2, le pire des trois chiffres. Un paquet perdu est un tir que le serveur n’a pas vu ou une position qu’il doit deviner. Moins d’un pour cent suffit pour des tirs qui ne comptent pas. Si des traits rouges apparaissent alors que CS2 est fermé, ce n’est pas la faute de Valve.
L’avertissement que CS2 affiche mesure la même chose que cette colonne : l’irrégularité d’arrivée de tes paquets. Régulièrement lent reste jouable, irrégulièrement rapide non.
Sous 30 ms, les duels se jouent à armes égales ; au-delà de 80 ms, tu perds la plupart des angles avant que le modèle adverse n’apparaisse. Une mauvaise route ne se voit souvent que vers une seule région — essaie les serveurs en haut.
Ce que tu vois en jeu — et quel chiffre de cette page l’explique.
| Ce que tu vois sur Counter-Strike 2 | Regarde | Ce que ça veut dire |
|---|---|---|
| Tu es ramené en arrière (rubberbanding) | Perte de paquets | Le serveur n’a pas reçu tes positions et te remet où il t’a vu en dernier. |
| Les tirs ne comptent pas | Perte de paquets | Le tir a été dessiné chez toi, le paquet n’est jamais arrivé. |
| CS2 affiche « net jitter » | Jitter | Les temps de trajet varient trop pour que le client interpole proprement. |
| Mauvais seulement le soir | Jitter + perte | Saturation, chez toi ou chez ton fournisseur. Mesure à l’heure où ça va mal, pas à midi. |
Le sub-tick donne à ton action un horodatage entre deux ticks. Un tir quatre millisecondes après un tick n’est plus arrondi au suivant, il compte là où il a eu lieu. Ça supprime une erreur d’arrondi — et un arrondi n’est pas une perte.
Un paquet qui n’arrive jamais ne porte aucun horodatage. Le serveur n’a rien à placer. Le sub-tick rend une connexion propre plus précise et ne change rien à une connexion qui perd des paquets. C’est pourquoi la colonne rouge reste le premier chiffre à regarder.
Même chose pour l’idée qu’un serveur à tick rate plus élevé compenserait la perte. Le tick rate décide à quelle fréquence le serveur avance ; la perte décide si ta mise à jour en fait partie. À 1 % de perte, il t’en manque une à peu près toutes les secondes et demie.
Si la mesure montre de la perte ou un jitter élevé, suis ces points dans l’ordre.
Le symptôme : Le problème n’arrive que dans certaines parties.
Laisse ce test tourner dans une autre fenêtre pendant que tu joues, puis regarde la ligne de temps. Un graphique propre pendant une mauvaise partie veut dire que ta ligne allait bien et que le problème était après notre serveur.
Le symptôme : La perte arrive par vagues toutes les quelques minutes.
Une perte par vagues est la signature d’une liaison radio qui réémet, pas d’un réseau saturé. Un seul passage au câble Ethernet sépare les deux cas : si c’est propre, la cause est ton Wi-Fi, pas ton fournisseur.
Le symptôme : Le ping grimpe dès que quelqu’un regarde une vidéo.
Mises à jour, cloud, streams : tout passe par la même file d’attente que tes paquets de jeu. Mets tout en pause, remesure, et si l’écart est net, active la QoS ou le SQM de ta box. Le test de bufferbloat mesure exactement cet effet.
Le symptôme : Le câble est propre chez toi, mais les coupures restent.
Laisse le test tourner une heure à l’heure où ça coupe, puis exporte le rapport PDF depuis la page de résultat : heure, route, graphique et chaque coupure. C’est un document qu’un support technique peut traiter.
Sous 30 ms, c’est très bon ; jusqu’à 60 ms, tu le sens peu ; au-delà de 80 ms, tu perds des duels avant de voir l’adversaire.
Parce qu’une bonne connexion au speedtest dit seulement que le débit est là. Le rubberbanding vient de paquets perdus, que seul un test en UDP montre.
Passe au câble, coupe les téléchargements, et mesure ici : si le jitter reste élevé au câble avec tout coupé, la cause est chez ton fournisseur.
Non, vers nos serveurs à New York, San Jose, Francfort et Singapour. Une ligne propre ici prouve que ta partie du chemin va bien.