Come questo test misura la tua connessione
Questa pagina descrive esattamente cosa invia PingPacketTest.com, come diventa i tre numeri della home e, nell’ultima parte, cosa quei numeri non possono dire. Se leggi solo una parte, leggi l’ultima.
Cosa invia davvero il test
Il browser apre un DataChannel WebRTC verso uno dei server di misura e invia piccoli pacchetti. Il canale usa ordered: false e maxRetransmits: 0: il browser non può né rimandare un pacchetto né trattenerne uno perché ne manca uno precedente. È vero UDP, lo stesso trasporto che usano quasi tutti i giochi online.
Ogni pacchetto porta un numero e l’ora di partenza, alla dimensione del gioco scelto. Il server fa una sola cosa: lo rimanda indietro. L’andata e ritorno si misura tutta nel tuo browser, con un solo orologio. Un pacchetto il cui eco non arriva mai conta come perso.
Perché uno speed test non risponde a questa domanda
Uno speed test misura la banda via TCP, fatto apposta per nascondere il problema che cerchi: un pacchetto perso viene rimandato in silenzio e alla fine resta una velocità un po’ più bassa.
Un gioco non lo fa. Invia una posizione a ritmo fisso e va avanti; un aggiornamento perso non viene mai rimandato. Per questo una linea può superare ogni speed test e causare comunque rubberbanding.
Tick rate: perché il gioco scelto cambia la misura
Un server di gioco fa avanzare il mondo a passi fissi, i tick. Quel ritmo decide quanto spesso passano pacchetti sulla tua linea e quanto costa un ritardo: a 128 tick, 60 ms di andata e ritorno sono quasi otto aggiornamenti, a 20 tick appena uno.
Scegliere un gioco qui cambia quindi ritmo di invio e dimensione dei pacchetti della misura stessa. Il ritmo di ogni titolo, la sua fonte e se è verificato o stimato sono nel database dei tick rate.
Dove sono i server di misura
Sono quattro: New York, San Jose, Francoforte e Singapore. Il browser misura di default verso il più vicino; puoi cambiarlo per controllare un percorso preciso. Il server usato è indicato su ogni risultato, perché un ping senza destinazione non significa nulla.
Come si calcolano i numeri
Il primo secondo non conta. Ogni misura inizia con un secondo di riscaldamento: i pacchetti partono, ma non vengono contati. I primi pacchetti di un percorso sono più lenti, e quel costo appartiene all’apertura della connessione, non alla tua linea. Vale solo all’inizio: un’interruzione a metà misura compare per intero.
Il ping è una mediana, con tutto l’intervallo dietro. Il grafico disegna un punto ogni 100 ms; il punto è la mediana dei pacchetti di quella fetta, la banda ombreggiata va dal più basso al più alto. Nulla viene smussato.
La perdita di pacchetti non viene mai mediata. Un solo pacchetto perso disegna il suo segno a ogni livello di zoom. Un pacchetto contato come perso che arriva dopo torna valido: era in ritardo, non perso.
Il jitter si misura su finestre fisse di un secondo (deviazione standard delle andate e ritorni di ogni secondo, mediata). Così la stessa linea dà lo stesso jitter a ogni tick rate. Un’andata e ritorno oltre i 1000 ms conta come perdita.
Come nascono verdetto e percentile
Il verdetto prende il peggiore dei tre numeri, non la media. 20 ms di ping con 2 % di perdita non è una buona connessione. Le soglie di jitter derivano dal tick rate (mezzo tick per «buono», un tick per «giocabile», con tetto a 15 e 30 ms); quelle del ping sono una scelta, pubblicata qui: 30/60 ms da 100 Hz, 40/80 ms a 60–64 tick, 60/100 ms a 30 tick, 80/150 ms sotto. Per la perdita la soglia è uguale ovunque: oltre l’1 % non basta.
Il percentile ti confronta con le misure fatte qui, non con internet. Chi apre un test di perdita di pacchetti non è un campione casuale: molti arrivano perché qualcosa già non va.
Cosa significa la riga Tipo di NAT
Durante la misura, la riga di stato indica il tipo della coppia di candidati ICE usata davvero: host per un percorso pubblico diretto, server-reflexive per un passaggio attraverso un NAT che ha permesso un percorso diretto, relay per una connessione tramite intermediario. Mostrato come Aperto, Moderato e Rigido, le parole dei menu delle console. Un browser non può leggere il valore della console; questa è l’osservazione equivalente.
Come si contano interruzioni e disponibilità
Oltre un minuto, lo strumento dice cosa ha fatto la linea in quel tempo. Un’interruzione è un tratto di almeno un secondo intero in cui ogni finestra da 100 ms ha perso almeno un pacchetto. La disponibilità è la parte del tempo misurato fuori da quei tratti. I valori si calcolano una volta, alla fine, e si salvano con il risultato.
Cosa questo test non può dire
Misuriamo il percorso verso il nostro server, non verso quello del gioco. Se il percorso verso Francoforte è pulito e il gioco scatta lo stesso, il problema può essere tra il tuo provider e il data center del gioco.
Un’andata e ritorno non dice in che direzione si è perso un pacchetto. E non è un traceroute: prova una perdita sul percorso intero, senza indicare il tratto colpevole.
Se UDP è bloccato, il test ripiega su TCP. Il ping resta indicativo, ma la perdita risulta più bassa del reale perché TCP ritrasmette. Lo stesso via relay (TURN): il percorso è più lungo di quello vero.
Misuriamo la connessione così com’è, con tutto ciò che la usa. Un download, una console che si aggiorna o uno streaming in casa finiscono nel risultato. Se una misura è brutta, ripetila con tutto il resto spento.
Un browser non è un ambiente in tempo reale. Un computer molto carico o una scheda in background possono aggiungere un po’ di jitter che viene dal tuo dispositivo, non dal provider.
Non è un test di velocità. E niente su questo sito è un campione casuale di internet: ogni confronto pubblicato dice «tra i test fatti qui».
Per continuare
Il database dei tick rate elenca ogni gioco con il ritmo inviato, la fonte e lo stato. Le statistiche sulla perdita di pacchetti e le statistiche dal vivo sono in inglese. Il test parte appena lo apri.
Domande, correzioni o un errore di metodo: info@pingpackettest.com.