¿Unha VPN baixa de verdade o teu ping nos xogos en liña?
Outra ruta pode gañarlle a un camiño ineficiente ou engadirlle demora. Compara a mesma rexión de xogo e vixía o jitter, as perdas e a cola local, non só o ping.
Si, ás veces, e a razón é máis aburrida do que admiten a maioría das guías. Un túnel envía o tráfico do teu xogo a unha saída e desde alí por outra ruta ata os mesmos servidores, así que pode substituír un camiño congestionado ou desviado ou simplemente engadir un salto e unha cola cando a ruta orixinal xa era boa. Só unha medición na túa propia conexión e na túa propia rexión che di en que caso estás, e dous xogadores do mesmo provedor poden obter resultados opostos desde o mesmo punto de saída. As comprobacións de abaixo están ordenadas para que o número que acabas comparando sexa un que poidas defender: mesma rexión, mesma hora do día, mesmo servidor.
Fixa a rexión e o servidor antes de comparar
Cada variable que deixas derivar convértese nunha explicación que non podes descartar. Fixa a rexión de xogo, o dispositivo, a rede de acceso e a hora do día, e despois compara unha liña base contra un único punto de saída. Cambia un só factor por proba, ou o resultado non se pode interpretar.
Escolle o punto de saída pola ruta, non pola etiqueta do país. Un servidor na capital da rexión na que xogas pode chegar mal á infraestrutura do xogo, mentres que un máis afastado pode estar nun mellor par. A bandeira do país é unha suposición sobre a topoloxía disfrazada de información.
Onde exista un campo de prácticas ou unha partida contra bots, úsao. As partidas en vivo rotan xogadores, asignan servidores distintos entre roldas e varían a carga de fondo, o que converte unha comparación controlada en ruído.
O ping medio agocha o que realmente sentes
O que os xogadores chaman lag adoita ser variación máis que unha media alta. Un 60 ms constante séntese previsible, mentres que unha media de 40 ms con picos de 120 ms fai que apuntar pareza roto. Rexistra a distribución, non o número único que o xogo imprime nunha esquina. Usa a capa de rede do propio xogo se a ten e despois corrobora desde o equipo con ferramentas de paquetes contra o enderezo que a sesión está a usar realmente.
ping -c 20 <game-server>
mtr -rwc 50 <game-server>As perdas e o jitter son os campos que paga a pena ler. As respostas ICMP ausentes por si soas proban pouco, porque moitos equipos despriorizan os pings mentres reenvían perfectamente o tráfico do propio xogo. Corrobora cos contadores do xogo antes de concluír nada sobre perdas.
A conxestión local pesa máis que calquera elección de saída
Nada do que fai unha VPN pode reparar unha subida saturada na túa propia liña. Unha copia de seguridade doméstica, unha sincronización na nube ou unha videollamada enchen o búfer de subida, os paquetes pequenos do xogo fan cola detrás dos datos masivos e a latencia dispárase para todos os da conexión.
Proba por Ethernet nunha posición fixa se podes, e fai unha segunda proba mentres a subida está ocupada. Se o pico aparece baixo carga e desaparece cando esta para, atopaches a cola e ningún punto de saída a vai arranxar. O bufferbloat na ligazón de acceso é o culpable habitual.
O inalámbrico merece a mesma sospeita. Unha ligazón Wi-Fi marxinal degrádase coa distancia e as interferencias, e a saída do túnel leva a culpa porque é o máis novo da cadea. Pasa a unha conexión por cable nunha proba e a resposta adoita quedar obvia. Se a proba por cable é estable e a inalámbrica non, estás depurando radio, non encamiñamento.
UDP nun túnel segue sendo UDP nun túnel
Os xogos envían datagramas UDP. Unha VPN envolveos no que use o seu transporte exterior, e se ese transporte exterior é TCP, o seu comportamento de retransmisión e ordenación queda entre ti e o xogo. Un túnel que se reconecta a medio partido produce o mesmo tartamudeo que unha mala ruta, por unha razón completamente distinta. As directrices de uso de UDP do IETF explican por que o comportamento dos datagramas difire de TCP nas formas que aquí importan.
Os protocolos tamén fallan de xeito distinto. Reenviar TCP a un servizo que só escoita UDP produce silencio en vez dun erro, e editar un porto non pode facer aparecer un escoitador que nunca se iniciou. Compara perfís de servidor válidos ou a comparación carece de sentido.
Un efecto que non é de rede paga a pena coñecer: unha nova saída cambia a rexión que infire o servizo, o que pode activar un paso de verificación ou un desaxuste de localización na túa conta. Iso é un evento de conta, non de latencia, e non se repara escollendo un punto de saída máis próximo.
Anota os números antes de xulgar pola sensación
Mantén os mesmos campos en cada proba, incluídas as que senten ben, porque a comparación útil é entre dúas sesións rexistradas e non entre unha impresión e un recordo. Unha sesión curta rexistrada así vale máis que unha noite de opinións, e permíteche notar cando o encamiñamento dun provedor empeora. A folla de abaixo é o mínimo que fai honesta unha comparación posterior.
| Campo | Que rexistrar | Que descarta |
|---|---|---|
| Saída e rexión de xogo | cidade de saída máis a etiqueta da rexión no xogo | mesturar a ruta posterior dunha saída co teu camiño local |
| Ida e volta media | media da quenda de sondaxe, a mesma ferramenta cada vez | xulgar unha sesión a partir dunha soa mostra |
| Peor pico | a única peor mostra desa quenda | unha media que agocha curtos estalidos de cola |
| Perdas | porcentaxe no fluxo do xogo, non só en ICMP | ler pings despriorizados como perdas reais |
| Xanela de proba | hora local de inicio e fin, día laborable ou fin de semana | comparar a hora punta cunha mañá tranquila |
Xulga pola sensación por riba dos números. A capacidade de resposta nunha partida real é o resultado que che importa, e unha medición que mellora mentres o xogo sente peor díxoche que medías a cousa equivocada. Repite a folla despois de calquera cambio de provedor ou de ruta, xa que a resposta só é válida para o camiño que mediste.