Måle nettverkshastighet i C++: årsaker til avvik og feilsøking

Hva betyr det når nettverkshastigheten avviker?

Når et C++-program måler lavere hastighet enn bredbåndsabonnementet tilsier, betyr det ikke nødvendigvis at forbindelsen er defekt. Resultatet påvirkes av målemetoden, serveren, protokollen, ruteren, Wi-Fi-forholdene og belastningen på nettet. En seriøs test bør derfor skille mellom nedlasting, opplasting, latency, jitter og pakketap.

Hastighet oppgis ofte i Mbit/s, mens filstørrelser vanligvis oppgis i MB. Én byte består av åtte bit, og protokolloverhead gjør at en praktisk filoverføring normalt blir noe lavere enn den teoretiske linjehastigheten.

Årsak 1: Målemetoden i C++ gir feil resultat

En vanlig årsak er at programmet starter og stopper tidtakingen på feil tidspunkt. DNS-oppslag, TCP-tilkobling, TLS-forhandling og eventuell bufferoppretting kan bli inkludert i målingen. Ved små testfiler får disse faste kostnadene stor betydning, og resultatet kan se ut som lav nettverkshastighet.

Bruk en monotontgående klokke, for eksempel std::chrono::steady_clock, og mål bare perioden der nyttige byte faktisk overføres. Tell mottatte eller sendte byte fra applikasjonen, og gjenta testen med større datamengder slik at oppstartsfasen får mindre påvirkning.

Årsak 2: TCP-vindu og enkelt forbindelse begrenser gjennomstrømmingen

TCP øker sendingsmengden gradvis og reduserer den når pakker går tapt. På forbindelser med høy latency kan én TCP-forbindelse derfor bruke lang tid på å fylle kapasiteten. Dette merkes særlig ved fiberforbindelser med lang avstand til testserveren eller ved bruk av en liten mottaksbuffer.

Vurder større lese- og skrivebuffere, hold forbindelsen åpen og test over en tilstrekkelig lang periode. Sammenlign også én forbindelse med flere parallelle forbindelser, men oppgi antallet tydelig i resultatet. Parallelle forbindelser kan vise tilgjengelig kapasitet, men de beskriver ikke nødvendigvis ytelsen til én vanlig nettleserforespørsel.

Årsak 3: Wi-Fi, ruter eller modem skaper flaskehalsen

Wi-Fi påvirkes av avstand, vegger, kanalstøy og mange samtidige klienter. En eldre ruter eller et modem kan også ha begrenset kapasitet, spesielt når trafikken går gjennom VPN, brannmur eller andre funksjoner som krever ekstra behandling. Derfor kan en test på Wi-Fi bli betydelig lavere enn en test på kablet nettverk.

Koble testmaskinen direkte til ruteren med Ethernet, og kjør samme C++-test på nytt. Test deretter på 5 GHz eller 6 GHz dersom utstyret støtter det, og flytt deg nærmere aksesspunktet. Hvis kabeltesten er god mens Wi-Fi-testen er lav, ligger årsaken sannsynligvis i det lokale nettet og ikke hos internettleverandøren.

Årsak 4: Testserveren eller ruten til serveren er overbelastet

En hastighetstest måler ikke bare tilgangslinjen. Den måler også kapasiteten mellom deg og den valgte serveren. En server langt unna, en overbelastet node eller en ugunstig ruting hos operatøren kan gi lav nedlasting, lav opplasting eller høy latency selv om forbindelsen lokalt fungerer normalt.

Velg flere testservere i ulike norske eller nordiske regioner, og sammenlign resultatene på samme tidspunkt. Dokumenter serverens adresse, nettprotokoll og testtid. Store forskjeller mellom servere peker mot serverkapasitet eller ruting, mens like resultater overalt peker mot lokal forbindelse, ISP eller måleprogram.

Årsak 5: Bakgrunnstrafikk bruker kapasiteten

Andre enheter kan bruke forbindelsen til skylagring, videomøter, strømmetjenester, spilloppdateringer eller sikkerhetskopiering. Da måler C++-programmet bare den kapasiteten som er igjen. Opplasting er ofte spesielt sårbar fordi én aktiv sikkerhetskopiering kan fylle hele oppstrømmen og samtidig øke latency for annen trafikk.

Stans tunge overføringer på datamaskinen og andre enheter før testen. Kjør flere målinger med og uten bakgrunnstrafikk, og noter om latency eller pakketap øker under belastning. En ruter med køstyring eller passende QoS kan redusere forsinkelsen, men innstillingen må tilpasses den faktiske linjehastigheten.

Årsak 6: Pakketap, jitter eller overbelastning reduserer ytelsen

Pakketap tvinger TCP til å sende data på nytt og kan redusere gjennomstrømmingen kraftig. Jitter betyr at latency varierer over tid, mens køoverbelastning kan gi høy forsinkelse når forbindelsen brukes aktivt. En enkel gjennomsnittlig Mbit/s-verdi skjuler ofte disse problemene.

Mål latency både uten trafikk og mens en kontrollert nedlasting eller opplasting pågår. Registrer minimum, gjennomsnitt og maksimum, samt antall tapte pakker. Verktøy som ping og traceroute kan gi indikasjoner, men de bør tolkes sammen med testresultater fra flere servere fordi ICMP-trafikk kan behandles annerledes enn TCP- eller HTTPS-trafikk.

Slik bygger du en mer pålitelig C++-test

Definer testforløpet

1. Finn serveren og mål DNS- og tilkoblingstid separat.
2. Opprett forbindelsen før selve hastighetsmålingen starter.
3. Overfør en stor nok datamengde til at oppstartskostnaden blir liten.
4. Mål nedlasting og opplasting i separate tester.
5. Gjenta hver test flere ganger og beregn median, ikke bare gjennomsnitt.

Rapporter nok detaljer

Resultatet bør inneholde tidspunkt, server, protokoll, lokal tilkoblingstype, testvarighet, overførte byte, Mbit/s, latency, jitter og pakketap. Oppgi også om testen ble kjørt via Wi-Fi, Ethernet, VPN eller en proxy. Da kan resultatet sammenlignes med andre målinger og brukes i dialogen med ISP eller operatør.

Optimalisering og tolkning av resultatene

Start med å isolere feilen: test først med Ethernet, deretter med flere servere og til slutt med kontrollert bakgrunnstrafikk. Dersom bare én server gir lav hastighet, bør du undersøke serveren eller rutingen. Dersom alle servere er lave på både kabel og Wi-Fi, kontroller modem, ruter, abonnementets tekniske profil og eventuelle begrensninger hos ISP.

Ikke bruk én enkelt måling som bevis på en permanent feil. Kjør tester på ulike tidspunkter, særlig når nettet vanligvis er belastet. En stabil forbindelse med litt lavere hastighet kan være mer brukbar enn en forbindelse med høy topphastighet, men betydelig jitter eller pakketap.

For generell kontroll av linjen kan du sammenligne programmet med en etablert nettverkshastighetstest. Bruk sammenligningen som et diagnostisk holdepunkt, og sørg for at server, protokoll og testbetingelser er så like som mulig.