Sí, de vegades, i la raó és més avorrida del que admeten la majoria de guies. Un túnel envia el trànsit del joc a una sortida i des d’allà per una ruta diferent cap als mateixos servidors, de manera que pot substituir un camí congestionat o desviat o simplement afegir un salt i una cua quan la ruta original ja era bona. Només un mesurament a la vostra pròpia connexió i a la vostra pròpia regió us diu en quin cas esteu, i dos jugadors del mateix proveïdor poden obtenir resultats oposats des del mateix punt final. Les comprovacions següents estan ordenades perquè el número que acabeu comparant sigui un que pugueu defensar: mateixa regió, mateixa hora del dia, mateix servidor.

Fixeu la regió i el servidor abans de comparar

Cada variable que deixeu derivar es converteix en una explicació que no podeu descartar. Fixeu la regió del joc, el dispositiu, la xarxa d’accés i l’hora del dia, i després compareu una línia de base amb un punt final. Canvieu un sol factor per execució, o el resultat serà ininterpretable.

Trieu el punt final per ruta, no per etiqueta de país. Un servidor a la capital de la regió on jugueu pot arribar malament a la infraestructura del joc, mentre que un de més llunyà pot seure sobre un parell millor. La bandera del país és una conjectura sobre la topologia disfressada d’informació.

On hi hagi un camp de pràctiques o una partida contra bots, feu-lo servir. Les partides en directe roten jugadors, assignen servidors diferents entre rondes i varien la càrrega de fons, cosa que converteix una comparació controlada en soroll.

El ping mitjà amaga el que realment noteu

El que els jugadors anomenen lag sol ser variació i no una mitjana alta. Un 60 ms estable es nota previsible, mentre que una mitjana de 40 ms amb pics de 120 ms fa que apuntar sembli trencat. Enregistreu la distribució, no el número únic que el joc imprimeix en un racó. Feu servir la capa de xarxa pròpia del joc si en té, i després corroboreu-ho des de l’amfitrió amb una eina de paquets contra l’adreça que la sessió utilitza realment.

ping -c 20 <game-server>
mtr -rwc 50 <game-server>

Les pèrdues i la fluctuació són els camps que val la pena llegir. Les respostes ICMP que falten per si soles proven poc, perquè molts amfitrions desprioritzen els pings mentre reenvien perfectament el trànsit propi del joc. Corroboreu-ho amb els comptadors del joc abans de concloure res sobre les pèrdues.

La congestió local supera qualsevol elecció de sortida

Res del que fa un VPN no pot reparar una pujada saturada a la vostra línia. Una còpia de seguretat domèstica, una sincronització al núvol o una videotrucada omplen el buffer de pujada, els paquets petits del joc fan cua darrere de les dades massives i la latència salta per a tothom a la connexió.

Proveu amb Ethernet en una posició fixa si podeu, i feu una segona prova mentre la pujada està ocupada. Si el pic apareix sota càrrega i desapareix quan s’atura, heu trobat la cua i cap punt final no la repararà. El bufferbloat a l’enllaç d’accés és el culpable habitual.

El sense fil mereix la mateixa sospita. Un enllaç Wi-Fi marginal es degrada amb la distància i la interferència, i la sortida del túnel rep la culpa perquè és la cosa més nova de la cadena. Passeu a una connexió per cable per a una execució i la resposta sol fer-se evident. Si l’execució per cable és estable i la sense fil no, esteu depurant la ràdio, no l’encaminament.

L’UDP dins d’un túnel continua sent UDP dins d’un túnel

Els jocs envien datagrames UDP. Un VPN els embolcalla en el que faci servir el seu transport exterior, i si aquest transport exterior és TCP, el seu comportament de retransmissió i ordenació se situa entre vosaltres i el joc. Un túnel que es reconnecta a mitja partida produeix la mateixa stutter que una ruta dolenta, per una raó completament diferent. Directrius d’ús d’UDP expliquen per què el comportament dels datagrames difereix del TCP en els aspectes que importen aquí.

Els protocols també fallen de maneres diferents. Reenviar TCP a un servei que només escolta UDP dóna silenci en lloc d’un error, i una edició de port no pot conjurar un oient que mai es va iniciar. Compareu perfils de servidor vàlids o la comparació no té sentit.

Un efecte no relacionat amb la xarxa val la pena conèixer-lo: una sortida nova canvia la regió que el servei infereix, cosa que pot desencadenar un pas de verificació o una discrepància d’ubicació al vostre compte. Això és un esdeveniment del compte, no de latència, i no es repara triant un punt final més proper.

Anoteu els números abans de jutjar per sensació

Mantingueu els mateixos camps per a cada execució, incloses les execucions que es noten bé, perquè la comparació útil és entre dues sessions enregistrades i no entre una impressió i un record. Una sessió curta enregistrada així val més que una nit d’opinions, i us permet adonar-vos quan l’encaminament d’un proveïdor canvia a pitjor. El full de sota és el mínim que fa honesta una comparació posterior.

CampQuè enregistrarQuè descarta
Sortida i regió del jocciutat de sortida més l’etiqueta de regió del jocbarrejar la ruta posterior d’una sortida amb el vostre camí local
Temps d’anada i tornada mitjàmitjana de l’execució de prova, la mateixa eina cada vegadajutjar una sessió a partir d’una sola mostra
Pitjor picl’única mostra pitjor d’aquella execucióuna mitjana que amaga ràfegues curtes de cua
Pèrduespercentatge sobre el flux del joc, no només sobre ICMPllegir pings desprioritzats com a pèrdues reals
Finestra de provahora local d’inici i fi, dia feiner o cap de setmanacomparar l’hora punta amb un matí tranquil

Jutgeu per sensació a més dels números. La capacitat de resposta en una partida real és el resultat que us importa, i un mesurament que millora mentre el joc es nota pitjor us ha dit que vau mesurar la cosa equivocada. Torneu a executar el full després de qualsevol canvi de proveïdor o ruta, ja que la resposta només és vàlida per al camí que vau mesurar.

Articles relacionats