Senker en VPN faktisk pingtiden din i nettspill?
En annen rute kan slå en ineffektiv vei eller legge til forsinkelse. Sammenlign samme spillregion og følg med på jitter, tap og lokal kø, ikke bare ping.
Ja, noen ganger, og grunnen er kjedeligere enn de fleste guider innrømmer. En tunnel sender spilltrafikken din til en utgang og derfra langs en annen rute til de samme serverne, så den kan erstatte en overbelastet eller omvei eller rett og slett legge til et hopp og en kø når den opprinnelige ruten allerede var god. Bare en måling på din egen forbindelse i din egen region forteller deg hvilket tilfelle du er i, og to spillere hos samme leverandør kan få motsatte resultater fra samme endepunkt. Kontrollene nedenfor er ordnet slik at tallet du til slutt sammenligner er et du kan forsvare: samme region, samme tid på dagen, samme server.
Lås regionen og serveren før du sammenligner
Hver variabel du lar drive blir en forklaring du ikke kan utelukke. Lås spillregionen, enheten, aksessnettet og tiden på dagen, og sammenlign deretter en basislinje mot ett endepunkt. Endre én faktor per kjøring, ellers er resultatet ufortolkbart.
Velg endepunktet etter rute, ikke etter landsetikett. En server i hovedstaden i regionen du spiller i kan fortsatt nå spillinfrastrukturen dårlig, mens en lenger unna kan sitte på en bedre peer. Flagg er en gjetning om topologi kledd som informasjon.
Der det finnes en treningsbane eller botkamp, bruk den. Live-kamper roterer spillere, tildeler forskjellige servere mellom runder og varierer bakgrunnslasten, noe som gjør en kontrollert sammenligning til støy.
Gjennomsnittlig ping skjuler det du faktisk merker
Det spillerne kaller lag er vanligvis variasjon og ikke et høyt gjennomsnitt. Jevnt 60 ms føles forutsigbart, mens et gjennomsnitt på 40 ms med 120 ms-topper får siktingen til å føles ødelagt. Registrer fordelingen, ikke det ene tallet spillet skriver i et hjørne. Bruk spillets eget nettverksoverlegg hvis det finnes, og bekreft deretter fra verten med et pakkeverktøy mot adressen økten faktisk bruker.
ping -c 20 <game-server>
mtr -rwc 50 <game-server>
Tap og jitter er feltene som er verdt å lese. Manglende ICMP-svar beviser lite alene, fordi mange verter nedprioriterer ping mens de videresender spillets egen trafikk helt fint. Bekreft med tellerne i spillet før du konkluderer noe om tap.
Lokal overbelastning går foran ethvert utgangsvalg
Ingenting en VPN gjør kan reparere en mettet opplasting på din egen linje. En hjemme-backup, en skysynkronisering eller en videosamtale fyller oppstrømsbufferen, de små pakkene fra spillet stiller seg i kø bak bulkdata, og forsinkelsen hopper for alle på forbindelsen.
Test på Ethernet på en fast plass hvis du kan, og kjør en ny test mens opplastingen er opptatt. Hvis toppen dukker opp under last og forsvinner når den stopper, har du funnet køen, og ingen endepunkt vil fikse den. Bufferbloat på aksesslinjen er den vanlige synderen.
Trådløst fortjener samme mistanke. En marginal Wi-Fi-lenke forringes med avstand og interferens, og tunnelutgangen får skylden fordi den er det nyeste i kjeden. Bytt til kablet forbindelse for én kjøring, og svaret blir vanligvis åpenbart. Hvis den kablede kjøringen er stabil og den trådløse ikke, feilsøker du radio, ikke ruting.
UDP i en tunnel er fortsatt UDP i en tunnel
Spill sender UDP-datagrammer. En VPN pakker dem inn i det den ytre transporten bruker, og hvis den ytre transporten er TCP, sitter dens retransmisjons- og ordensatferd mellom deg og spillet. En tunnel som kobler til på nytt midt i en kamp gir samme hakking som en dårlig rute, av en helt annen grunn. IETFs retningslinjer for UDP-bruk forklarer hvorfor datagramatferd skiller seg fra TCP på de måtene som betyr noe her.
Protokoller feiler også forskjellig. Å videresende TCP til en tjeneste som bare lytter på UDP gir stillhet i stedet for en feil, og en portendring kan ikke trylle fram en lytter som aldri ble startet. Sammenlign gyldige serverprofiler, ellers er sammenligningen meningsløs.
Én ikke-nettverksbasert effekt er verdt å kjenne: en ny utgang endrer regionen tjenesten utleder, noe som kan utløse et verifiseringstrinn eller en plasseringskonflikt i kontoen din. Det er en kontobegivenhet, ikke en latensbegivenhet, og den repareres ikke ved å velge et nærmere endepunkt.
Skriv ned tallene før du dømmer etter følelse
Behold de samme feltene for hver kjøring, også de som føles fine, fordi den nyttige sammenligningen er mellom to registrerte økter og ikke mellom et inntrykk og en erindring. En kort økt registrert slik er verdt mer enn en kveld med meninger, og den lar deg legge merke til når en leverandørs ruting blir dårligere. Arket nedenfor er minimumet som gjør en senere sammenligning ærlig.
| Felt | Hva som skal registreres | Hva det utelukker |
|---|---|---|
| Utgang og spillregion | utgangsby plus regionetiketten i spillet | å blande en utgangs videre rute med din lokale vei |
| Gjennomsnittlig rundtur | gjennomsnitt av målekjøringen, samme verktøy hver gang | å dømme en økt ut fra én prøve |
| Verste topp | den ene verste prøven i den kjøringen | et gjennomsnitt som skjuler korte køutbrudd |
| Tap | prosent på spillflyten, ikke på ICMP alene | å lese nedprioriterte ping som reelt tap |
| Testvindu | lokal start- og sluttid, ukedag eller helg | å sammenligne rushtid med en rolig morgen |
Døm etter følelse på toppen av tallene. Respons i en ekte kamp er resultatet du bryr deg om, og en måling som blir bedre mens spillet føles verre har fortalt deg at du målte feil ting. Kjør arket på nytt etter enhver leverandør- eller ruteendring, siden svaret bare er gyldig for veien du målte.