Sì, a volte, e il motivo è più noioso di quanto ammettano la maggior parte delle guide. Un tunnel invia il traffico del gioco verso un'uscita e da lì lungo un percorso diverso verso gli stessi server, quindi può sostituire un cammino congestionato o deviato oppure semplicemente aggiungere un salto e una coda quando il percorso originale era già buono. Solo una misura sulla tua connessione, nella tua regione, ti dice in quale caso ti trovi, e due giocatori dello stesso provider possono ottenere risultati opposti dallo stesso endpoint. I controlli qui sotto sono ordinati perché il numero che finirai per confrontare sia difendibile: stessa regione, stessa ora del giorno, stesso server.

Fissa la regione e il server prima di confrontare

Ogni variabile lasciata variare diventa una spiegazione che non puoi escludere. Fissa la regione di gioco, il dispositivo, la rete di accesso e l'ora del giorno, poi confronta una baseline con un solo endpoint. Cambia un fattore per prova, altrimenti il risultato è ininterpretabile.

Scegli l'endpoint in base alla rotta, non all'etichetta del paese. Un server nella capitale della regione in cui giochi può comunque raggiungere male l'infrastruttura del gioco, mentre uno più lontano può trovarsi su un peer migliore. La bandiera del paese è una supposizione sulla topologia travestita da informazione.

Dove esiste un poligono di tiro o una partita contro i bot, usalo. Le partite dal vivo ruotano i giocatori, assegnano server diversi tra un round e l'altro e variano il carico di fondo, il che trasforma un confronto controllato in rumore.

Il ping medio nasconde ciò che senti davvero

Quello che i giocatori chiamano lag è di solito variazione più che una media alta. Un 60 ms stabile sembra prevedibile, mentre una media di 40 ms con picchi di 120 ms fa sembrare la mira rotta. Registra la distribuzione, non il singolo numero che il gioco stampa in un angolo. Usa l'overlay di rete del gioco se esiste, poi verifica dall'host con uno strumento a pacchetti l'indirizzo che la sessione sta davvero usando.

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

Perdite e jitter sono i campi che vale la pena leggere. Le risposte ICMP mancanti da sole dimostrano poco, perché molti host danno priorità bassa ai ping mentre inoltrano perfettamente il traffico del gioco. Verifica con i contatori di gioco prima di concludere qualcosa sulle perdite.

La congestione locale conta più di qualsiasi scelta di uscita

Niente di ciò che fa un VPN può riparare un upload saturo sulla tua linea. Un backup domestico, una sincronizzazione cloud o una videochiamata riempiono il buffer in uscita, i pacchetti piccoli del gioco si accodano dietro i dati in blocco e la latenza salta per tutti sulla connessione.

Prova su Ethernet in una posizione fissa se puoi, ed esegui una seconda prova mentre l'upload è occupato. Se il picco appare sotto carico e scompare quando si ferma, hai trovato la coda e nessun endpoint la risolverà. Il bufferbloat sul collegamento di accesso è il colpevole abituale.

Il wireless merita lo stesso sospetto. Un collegamento Wi-Fi al limite peggiora con la distanza e le interferenze, e la colpa va all'uscita del tunnel perché è la cosa più nuova della catena. Passa a una connessione cablata per una prova e la risposta di solito diventa ovvia. Se la prova cablata è stabile e quella wireless no, stai facendo debug della radio, non del routing.

UDP in un tunnel resta UDP in un tunnel

I giochi inviano datagrammi UDP. Un VPN li incapsula in ciò che usa il suo trasporto esterno, e se quel trasporto esterno è TCP, il suo comportamento di ritrasmissione e ordinamento si frappone tra te e il gioco. Un tunnel che si riconnette a metà partita produce lo stesso singhiozzo di una brutta rotta, per una ragione del tutto diversa. Le linee guida sull'uso di UDP dell'IETF spiegano perché il comportamento dei datagrammi differisce da TCP nei modi che qui contano.

Anche i protocolli falliscono in modo diverso. Inoltrare TCP a un servizio che ascolta solo UDP produce silenzio invece di un errore, e modificare una porta non può evocare un listener che non è mai stato avviato. Confronta profili server validi, altrimenti il confronto è privo di senso.

Un effetto non di rete vale la pena conoscerlo: una nuova uscita cambia la regione che il servizio deduce, il che può attivare una fase di verifica o un disallineamento di posizione nel tuo account. È un evento dell'account, non di latenza, e non si ripara scegliendo un endpoint più vicino.

Annota i numeri prima di giudicare a sensazione

Mantieni gli stessi campi per ogni prova, comprese quelle che sembrano a posto, perché il confronto utile è tra due sessioni registrate e non tra un'impressione e un ricordo. Una sessione breve registrata così vale più di una serata di opinioni, e ti permette di notare quando il routing di un provider peggiora. La scheda qui sotto è il minimo che rende onesto un confronto successivo.

CampoCosa registrareCosa esclude
Uscita e regione di giococittà di uscita più l'etichetta della regione nel giocomescolare la rotta successiva di un'uscita con il tuo percorso locale
Andata e ritorno mediamedia della serie di misure, stesso strumento ogni voltagiudicare una sessione da un solo campione
Picco peggiorel'unico campione peggiore di quella serieuna media che nasconde brevi raffiche di coda
Perditepercentuale sul flusso di gioco, non solo su ICMPleggere ping a bassa priorità come perdite reali
Finestra di provaora di inizio e fine locale, giorno feriale o fine settimanaconfrontare l'ora di punta con una mattina tranquilla

Giudica a sensazione sopra i numeri. La reattività in una partita reale è il risultato che ti interessa, e una misura che migliora mentre il gioco sembra peggiore ti ha detto che stavi misurando la cosa sbagliata. Riesegui la scheda dopo ogni cambio di provider o di rotta, perché la risposta vale solo per il percorso misurato.

Articoli correlati