Router eller bærbar computer uden CPU? Hvorfor din VPN-hastighed stopper for tidligt

En router reklamerer med hurtigt Wi-Fi og kæmper derefter med at kryptere trafik for tre enheder på én gang. En bærbar computer når en grænse for regnekraft, mens der endnu er plads i adgangsforbindelsen. Serveren får normalt skylden først, og den er normalt uskyldig. Grænsen sidder på den maskine, der udfører tunnelarbejdet, og at finde den betyder at overvåge den maskine i stedet for hastighedstesten.

Symptomet peger på én maskine, ikke på internettet

Hvor tunnelen kører, afgør, hvilken processor der betaler for den. Hvis routeren afslutter den, deler hver dækket klient den routers budget. Hvis den bærbare kører en klient, betaler den bærbare, og routeren gør ikke. Tunneler i begge ender skaber to arbejdsbelastninger, som hver kan blive grænsen på en anden dag. At navngive maskinen er det første skridt, og det er det skridt, folk springer over, når de åbner en sag mod udbyderen.

Tæl enhederne mellem applikationen og den fjerne ende, og markér derefter den, der krypterer. Alt andet er blot en bærer af bytes, som den ikke kan læse.

Overvåg belastningen per kerne under en overførsel

En samlet CPU-procent er det forkerte instrument, fordi krypteringsarbejde ofte binder en enkelt kerne, mens resten står stille. Se på tal per kerne under en kontrolleret overførsel, og hold øje med en kerne tæt på udnyttelse. Et moderat gennemsnit med én travl tråd er et stærkt signal, mens et højt gennemsnit uden en travl tråd normalt betyder et urelateret program. Mønstret betyder mere end tallet.

mpstat -P ALL 1 5
top -H -b -n 1 | head -20
lscpu | grep -i -E "model name|aes"

Den tredje kommando fortæller, om processoren eksponerer AES-instruktioner, hvilket ændrer prisen på samme cipher med en bred margin. Den fortæller ikke, om VPN-implementeringen bruger dem, og netop mellemrummet mellem de to fakta er, hvor de fleste optimeringspåstande kommer fra.

Adskil kryptering fra pakkehåndtering

Kryptering er én omkostning blandt flere. Kopiering af pakker mellem kernen og brugerrum, ruteopslag, firewallregler og interfacehåndtering bidrager alle, og nogle implementeringer betaler mere for kopiering end for kryptografi. Læg mærke til, hvilken tæller der stiger sammen med overførslen, i stedet for at stole på, at procesnavnet forklarer hver cyklus. En tunnel i brugerrum og en tunnel i kernen kan vise helt forskellige profiler for identisk trafik.

Hvis én kerne er travl inde i kernen, adskiller løsningen sig fra en travl tråd i brugerrum, og profilen fortæller, hvilken du har. Den forskel er en time værd, før du køber hardware.

Sammenlign lignende med lignende, før du drager en konklusion

En sammenligning er kun nyttig, hvis opgaven, adgangsnetværket og endepunktet forbliver de samme. Skift serveren, og resultatet omfatter den servers rute og kapacitet; skift netværket, og det omfatter operatøren. Brug den samme fil, den samme destination og den samme tid på dagen, og standset dit eget baggrundsarbejde. Hvis du skal skifte enheden, skift da kun enheden.

Strøm og varme ændrer vedvarende ydeevne, så en kort kørsel på en kold maskine er ikke samme måling som en lang overførsel på en varm. Sammenlign lignende strømforhold, og skriv dem ned, fordi en termisk grænse ser præcis ud som en grænse for regnekraft i en graf.

Brug understøttet offload, og verificer at det faktisk blev aktiveret

Nogle implementeringer kan flytte en del af datastien ned i kernen eller ud i hardware, og tilgængeligheden afhænger af klienten, styresystemet, serveren og konfigurationen. Læs dokumentationen for den version, du kører, og brug dens egen statusudskrift eller logfiler til at bekræfte, at funktionen er aktiv. En installeret pakke eller et afkrydset felt er ikke bevis. OpenVPN-manualen dokumenterer datakanalvalg for sine egne udgivelser, og disse valg er forskellige mellem versioner.

Når en understøttet ændring flytter loftet, skal du køre både applikationsopgaven og en bulkoverførsel igen og beholde den forrige profil, så du kan rulle tilbage. En bulkrate, der fordobles, mens applikationen forbliver langsom, har flyttet flaskehalsen snarere end fjernet den.

Hvis processorobservationer ikke følger symptomet, vend tilbage til netværkssiden. Wi-Fi-genforsøg, kødannelse og udgangsstien giver det samme resultat helt uden CPU-indblanding.