Jitter og pakketab på et VPN-opkald: hvad du skal sammenligne
Forsinket, men jævn tale og tale, der bryder ud i huller, er forskellige fejl. Sammenlign appens egne statistikker, den lokale radio og én belastet vej.
Robotagtig tale og tabte stavelser lyder forskelligt, fordi de er forskellige fejl. Jitter ændrer, hvornår pakkerne ankommer; tab betyder, at de slet ikke ankommer. Begge kan forekomme, mens en hastighedstest rapporterer en sund download, fordi gennemstrømning og rettidig levering måler forskellige ting. Match evidensen med lyden, før du ændrer nogen indstilling.
Hvorfor sene pakker og manglende pakker lyder forskelligt
Medie forlader afsenderen i et jævnt tempo, og rigtige netværk leverer det med ujævne mellemrum. Applikationer buffer lidt for at udjævne det og bytter forsinkelse for kontinuitet: hæv bufferen, og samtalen føles langsom; sænk den, og der opstår huller. En pakke, der ankommer efter sin afspilningsfrist, er reelt tabt, selv om den aldrig blev droppet. Derfor kan to forbindelser med samme båndbredde give vidt forskellige opkald.
Retningen betyder også noget. Indgående og udgående medie kan tage forskellige veje, især når den ene side er på et mobilnetværk.
Tallene, du skal læse i det dårlige vindue
Brug applikationens egne statistikker, hvor den tilbyder dem, og læs dem, mens opkaldet er dårligt, ikke efter det er slut. Et medierelay er ofte en anden vært end tjenestens websted, så en ping til forsiden måler en vej, opkaldet ikke bruger. Se på tabprocent, rundtur-tid og jitter hver for sig, og noter, om klienten sender eller modtager problemet. En VPN-genopkobling under opkaldet er en tredje hændelse, der skal registreres, ikke smeltes sammen med de andre.
Skærmbilleder af statistikpanelet slår en erindring om opkaldet, fordi tallene kan sammenlignes senere. Tyve sekunders tabprocent fortæller dig, om vejen dropper pakker nu, men ikke om tabet kommer i byger, eller hvornår det begyndte.
Gentag derfor målingen under en anden betingelse i stedet for at læse ét vindue som en dom. To vinduer taget under forskellige betingelser siger mere end ét langt vindue taget under ingen af dem.
Hvad en jitterbuffer gør ved fristen
En jitterbuffer holder indgående pakker kort tilbage, så ujævne ankomster — den forsinkelsesvariation, som RFC 3393 definerer som en metrik — kan afspilles på et regelmæssigt ur. Bufferstørrelsen sætter afspilningsfristen: hver pakke senere end den frist kasseres, uanset indhold. Kodekker er forskellige i, hvor meget de kan skjule, og en kodek, der interpolerer en manglende ramme, kan skjule ét tab, men ikke en serie af dem. Derfor giver samme tabprocent forskellig opkaldskvalitet på forskellige kodekker.
At justere bufferen er en afvejning, ikke en rettelse. En større buffer køber kontinuitet på bekostning af forsinkelse i samtalen, og den kan ikke genvinde pakker, der ankommer efter fristen.
Sammenlign radioen og belastningen før udgangen
Hold udgangen og applikationen fast, mens du ændrer én lokal betingelse ad gangen. Et stærkt signalikon siger intet om kanaltrængsel. Hvis problemet følger ét rum eller ét adgangspunkt, er radioen den næste undersøgelse.
ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9
ping giver et tabstal og en spredning, du kan sammenligne på tværs af betingelser, og mtr viser tab pr. hop langs vejen. Mellemliggende hop, der fejler, mens senere svarer, nedprioriterer normalt ICMP i stedet for at droppe brugertrafik. Gentag begge, mens en kontrolleret upload kører, fordi et link, der er fint i tomgang og ubrugeligt under belastning, peger på kødannelse og ikke på VPN’en. Hvis kun én betingelse genskaber problemet, er den anden betingelse netop blevet udelukket.
Ret kun det, sammenligningen understøtter
Hver sammenligning understøtter én rettelse, og at anvende flere på én gang ødelægger evidensen. En svag lokal vej kræver en bedre kanal eller Ethernet, konkurrerende trafik kræver planlægning eller en kødisciplin, og én dårlig udgang kræver at sammenligne en anden udgang under samme betingelser. Når du skifter VPN-transport, skal du holde profilen gyldig og ændre én variabel ad gangen. Test den samme samtale igen med normal baggrundsaktivitet i stedet for at dømme succes på, om en hastighedstestscore steg.
Skriv retning, tab, jitter, rundtur-tid og den betingelse, hver blev målt under, ned. Den registrering gør en vag klage over opkaldskvalitet til en konstatering, nogen kan handle på. Gem den sammen med billetten, så den næste sammenligning starter fra samme baseline.