Dagbog-bloggen

Hvad er min pingtid?

Hos Kviknet får vi ofte dette spørgsmål fra gamere, som vil checke os ud, inden de bestiller en internetforbindelse.

Det svarer lidt til at spørge en bilforhandler, hvor hurtigt man kommer på arbejde i sin nye bil, og derfor har har vores svar indtil nu været, at det kan vi ikke sige noget om på forhånd, da der ikke findes noget entydigt svar.

Det afhænger nemlig af hvor man bor, hvor man skal hen, hvordan trafikken er på den givne dag osv.

I dag vil jeg dog forsøge at komme lidt nærmere et svar, der kan bruges.

Hvad menes der med pingtid?

I en gamers verden er pingtid et udtryk for den forsinkelse, også kendt som latency, der indgår i et onlinespil.

Pingtiden har betydning for, om man i et FPS-spil (First Person Shooter) kan nå at reagere hurtigt nok. En gamer vil typisk opleve, at en pingtid, der er meget højere end de andre deltageres, vil gøre, at man taber spillet, da man bliver besejret, før man når at se sin modstander på skærmen.

Derfor er en lav pingtid vigtig, og hvis man kan få en lavere pingtid end sine modstandere, har man en taktisk fordel.

Pingtiden er dog sammensat af mange forskellige faktorer, og vi skal derfor se på, hvordan den egentlig opstår.

Et onlinespil består af et antal klienter og en server. Hver klient kommunikerer med serveren, og der udveksles typisk små datagrammer (UDP-pakker) med kommandoer i en proprietær protokol, der er optimeret til det pågældende spil.

Spilserver

Spilserveren har til formål at agere knudepunkt for datagrammerne, og når et datagram fra en deltager modtages og processeres, resulterer det ofte i, at der skal sendes datagrammer tilbage, ikke alene til afsenderen men også til de andre deltagere i spillet.

Den tid, det tager, fra et datagram forlader afsenderens PC, til der kommer et svar fra spilserveren, udgør selve pingtiden, der også er kendt som round trip time (RTT).

Hvis man spørger et netværkstekniker, er pingtiden et udtryk for den forsinkelse, der ligger i selve netværket, mens en gamers definition af pingtiden også inkluderer den tid, serveren skal bruge på at processere datagrammerne og sende et svar retur.

Pingtiden i Kviknets netværk

Lad os se på, hvordan pingtiden opstår i det underliggende netværk hos Kviknet.

Pingtid - generelt princip

Allerførst har vi klientens PC. En dedikeret gamer har koblet PC'en til WiFi-routeren med et kabel, så der er så få forstyrrende elementer som muligt.

N00bs køber Denons obscenely overpriced ethernetkabel med iltfrit kobber, guldstik og medfølgende voodoo-besværgelser, mens folk der ved, hvad de laver, bruger det billigste parsnoede patchkabel, de kan finde.

WiFi-routeren er typisk koblet til vores access-netværk gennem en DSL, en coax-forbindelse eller en fiber.

Trafikken går herefter gennem vores backbone, før den forlader vores netværk ved en edge-router og finder sin vej til den spilserver, gameren er koblet op på.

Når trafikken skal retur til vores gamer, tager den typisk næsten samme vej tilbage. På internettet routes trafikken assymetrisk, men i access-forbindelsen og på hjemmenetværket tager trafikken præcis samme vej retur.

De forskellige elementer i nettet tilføjer forskellige forsinkelser, som til sammen udgør pingtiden.

Turen fra PC'en til WiFi-routeren og tilbage igen tager typisk 1 millisekund eller derunder. Her er det ikke de fysiske afstande, der medfører forsinkelsen, men derimod processeringen på PC'en og i WiFi-routeren.

Pingtid på hjemmenetværk

Turen fra WiFi-routeren gennem DSL-forbindelsen til internetudbyderens access-netværk og retur tager typisk 5-10 millisekunder. Hvis man har en coax- eller fiber-forbindelse er ping-tiden i access-forbindelsen meget lille, typisk under et millisekund.

PIngtid DSL

Næste trin er turen gennem vores backbone, og her spiller geografien en afgørende rolle. I Danmark ligger de fleste udbyderes backbone-kabler langs motorvejene.

PIngtid backbone-netværk

Hvis vores kunde bor i Aalborg, og vores edge-routere står i København, skal trafikken tilbagelægge lidt over 800 kilometer i alt, hvilket målt i lysets hastighed gennem en single-mode fiber ved 1310 nm bølgelængde giver lige knap 4 millisekunder.

Bor kunden i Odense, er distancen ca. 300 km, og så tager det ca. 1,5 millisekunder.

Alt efter hvor i landet man bor, er der således et absolut minimum for den pingtid, man kan opnå, uanset om man bruger DSL, coax eller fiber.

I praksis tager turen gennem backbone-netværket en smule længere tid, da trafikken skal igennem et antal routere undervejs, før den når vores edge-routere. Vi kan derfor som hovedregel regne med følgende forsinkelser i transportnettet:

  • Fra Aalborg til København: 5 ms
  • Fra Odense til København: 3 ms

Forsinkelsen fra vores edge-routere og indtil datagrammerne når spilserveren kan være hvad som helst, afhængigt af hvor i verden, spilserveren står.

Typisk vil en gamer vælge en spilserver, der står i Europa, og i nogle tilfælde er der tale om en virtuel server hosted af Amazon, der har et datacenter i Frankfurt am Main i Tyskland.

Fra København til Frankfurt er der 1.700 km tur-retur, og pingtiden er derfor minimum lidt over 8 millisekunder.

PIngtid internet

I praksis er den væsentligt højere, blandt andet fordi trafikken i vores tilfælde skal ind over AMS-IX i Holland. Derfor måler vi p.t. ca. 20 millisekunder mellem vores netværk i København og Amazons datacenter i Frankfurt.

Skal vores gamer i Aalborg med en DSL-forbindelse fra Kviknet spille på en spilserver hos Amazon i Frankfurt, vil pingtiden derfor udgøre følgende:

  • Hjemme-netværk: 1 ms
  • DSL: 7 ms
  • Access- og backbonenetværk: 5 ms
  • Fra København til Frankfurt: 20 ms
  • I alt: 33 ms

Der er således meget at spare, hvis man kan få sin spilserver lidt tættere på.

Hos Kviknet har vi derfor stillet en CS:GO-server til rådighed for kunderne. Serveren er tilsluttet vores netværk i København, og en DSL-kunde i Aalborg vil derfor typisk have en pingtid på ca. 13 ms, mens en coax-kunde i Odense har en pingtid på ca. 3 ms.

Det giver en lille, strategisk fordel for vores kunder, hvis de spiller med andre gamere uden for vores netværk.

Planen er, at vi stille og roligt vil stille flere typer spilservere til rådighed, efterhånden som behovet vokser.

Hvordan kan jeg måle pingtiden selv?

Man kan foretage et ICMP-ping vha. ping-kommandoen på Windows og Linux.

Det virker dog ikke altid, for netværksudstyr, herunder mange ISP-routere, nedprioriterer at svare på ping-forespørgsler.

Det sker, fordi routerens primære opgave er at forwarde trafik i sit data plane, og en ping-pakke, der har routeren selv som sin endelige destination, skal ikke forwardes, men i stedet behandles i routerens control plane.

En routers control plane er typisk en lille computer med begrænset hukommelse og CPU, da den kun har til opgave at vedligeholde opsætningen af routerens data plane, der foretager det tunge arbejde med at forwarde trafik.

For at undgå, at man kan sætte routeren ud af spillet med et rask DoS-angreb mod control planet, nedprioriteres svar på ping-forespørgsler og andre ting, der ikke er vitale for routerens drift.

Derfor kan en ping-test mod internetudbyderens netværksudstyr give en kunstigt høj pingtid, som ikke passer på den reelle latency, når man sender trafik gennem netværket.

Skal man have et nogenlunde retvisende svar på en pingtest, skal man derfor pinge en server, som ikke nedprioriterer svar på ping.

Hos Kviknet anbefaler vi af og til vores kunder at prøve at pinge en af vores webservere, hvis de mener, pingtiden ser for høj ud. Det giver typisk et andet billede af situationen.

Derudover er vi ved at bygge et såkaldt looking glass, der skal give brugere uden for vores netværk mulighed for at teste ping-tiden mod en vilkårlig IP-adresse, herunder gaming-servere o.l.

Mere info om dette følger i et senere indlæg.

P.S. Pingtiden er også vigtig for en anden slags gamere, nemlig high-frequency traders, som lever af at game aktiemarkedet gennem front running. Her kan selv få millisekunder betyde forskellen på at tjene eller tabe milliarder - eller ødelægge verdensøkonomien. Nogle gange begge dele.

Relateret indhold

Yoel Caspersens billede
Yoel Caspersen er direktør hos Kviknet, har en baggrund som udvikler og har gennem en længere årrække beskæftiget sig med udvikling af hostede PBX-løsninger, internetbutikker og software til online video- og tv-distribution. Dagbog-bloggen er en stafetblog for iværksættere.

Kommentarer (53)

Kommentarer (53)
Baldur Norddahl

Denons obscenely overpriced ethernetkabel med iltfrit kobber, guldstik og medfølgende voodoo-besværgelser

Prøv at læse anmeldelserne af kablet på Amazon. Det kabel kan lidt af hvert.

Thomas Toft

Turen fra PC'en til WiFi-routeren og tilbage igen tager typisk 1 millisekund eller derunder

Hahaha, åh den var god.

Jens Christian Gram

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9216ms
rtt min/avg/max/mdev = 0.341/0.363/0.409/0.029 ms

Det passer da meget godt.
Læg mærke til at han skriver at det er via. et kabel, og ikke wifi.

Yoel Caspersen Blogger

Jeg er glad for, du kan lide den :-)

og lidt old-skool at kalde det datagrammer :-D pakker tak, på IP niveau

Nu brugte jeg betegnelsen datagram for at understrege, at der er tale om UDP-pakker - men du har nok ret i, at det er en lidt oldschool betegnelse på dansk.

Til andre, der ikke er helt skarpe i netværk, kan jeg nævne, at størstedelen af IP-trafikken på internettet består af enten UDP-pakker eller TCP-pakker.

UDP (user datagram protocol) er "selvstændige" pakker, forstået på den måde, at der ikke er nogen garanti for, at en UDP-pakke når frem. Hvis et link er overbelastet undervejs, bliver UDP-pakkerne droppet uden at afsenderen får besked.

TCP (transmission control protocol) fungerer på en lidt anden måde - her sørger hver ende af forbindelsen for at gensende tabte pakker, så forbindelsen bliver 100 % pålidelig. TCP indeholder også en mekanisme til flow control, så afsenderen ikke sender data hurtigere end modtageren kan nå at modtage dem. Det sikrer en optimal udnyttelse af båndbredden, og TCP bruges i dag til stort set al en-vejs videostreaming, lige fra porno til Netflix og HBO.

UDP har til gengæld en anden styrke - fordi UDP ikke indeholder en transmissionskontrol, er UDP god til tidskritiske data som IP-telefoni og video-konferencer, hvor man kan leve med et moderat pakketab men ikke ønsker nogen forsinkelse.

Det samme gælder mange spil - kommandoerne kan være små, men tidskritiske, og derfor er der spiludviklere, der bygger deres egen customized protokol oven på UDP.

Du kan også overveje at opsætte RING server fra https://ring.nlnog.net/ så får du lidt latencymålinger fra verden, og dine kunder kan pinge den.

Det har vi faktisk allerede gjort - men vores node er nede lige nu, da RING-admins under opgraderingen af softwaren har crashed den. Det er på to-do-listen at få den geninstalleret :-)

Yoel Caspersen Blogger

Men er der ikke tillige en problematik omkring Interleaving / fastpath ifm xDSL?

Det er egentlig et godt spørgsmål.

Interleaving kan slås fra på ADSL, hvilket i TDC-verdenen bliver markedsført som "Gaming speeds". Vi har kørt nogle forsøg med det, men vi opnåede ikke nogen relevant forskel på latency i vores test-setup, så vi har ikke indført det som et produkt hos os.

Hos nogle kunder ser det imidlertid ud som om, det godt kunne gøre en forskel, men jeg antager, det afhænger af den valgte hastighedsprofil i det enkelte tilfælde.

En meget stor del af vores DSL-kunder kører VDSL, og her kan interleaving ikke slås fra. Det styres i stedet af DLM, som tilpasser niveauerne af interleaving dynamisk.

Benny Lyne Amorsen

I dag kan en god provider-edge-router lægge mindst 3 MPLS-tags og 2 VLAN-tags på en pakke, omskrive DSCP og 802.11p-værdier, filtrere og duplikere og alskens andre ting med fuld hastighed, også ved flere hundrede Gbps. (Den kan så nemt koste mere end en mio. DKK)

Men den kan ikke bytte src- og dst- adresse i IP og MAC-headeren og ændre ICMP-typen til echo-reply i stedet for echo-request. Det synes jeg personligt er absurd.

Det ville gøre supporternes liv meget lettere hvis de kunne fortælle kunderne: "ping denne adresse, det er den nærmeste router til jeres forbindelse, så kan I se om problemet er jeres linje eller længere ude på nettet at det går langsomt." Jeg forstår simpelthen ikke at ingen af routerproducenterne prioriterer at løse det problem.

Tilsvarende er det trælst at ens overvågning siger at der er høj latency til en core-router, bare fordi den har travlt med at varetage sine egentlige opgaver. Det giver falske alarmer.

Jeg har kun set én routerproducent tage ping alvorligt, og det er OneAccess. De laver desværre ikke core- eller provider-edge-routere, kun routere som er beregnet til at blive sat op hos kunder. De kan svare på ping med samme hastighed som de kan route pakker. Det burde alle routere kunne.

Christian Soelberg Due

Rigtigt cool artikel Joel

Jeg hjælper til dagligt lidt hos Shark Gaming som konsulent og talte lige med dem ift. en ide. Kunne du have lyst til at få denne artikel udgivet i Shark Gaming Magazine der månedligt læses af 10.000+ gamere? Det er et online magasin, men det indexeres ikke, så du kan godt genbruge teksten.

Det udsendes til et nyhedsbrev med 50.000+ gamere og promoveres forskellige steder.

Du vil naturligvis være istand til at nævne Kviknet i artiklen og vi har grafikere der kan løse den del.

Yoel Caspersen Blogger

Hahaha, åh den var god.

Nu er jeg måske lidt weekend-sløv, og tænker nok generelt ikke så hurtigt - men jeg kunne også godt tænke mig at få uddybet denne :-)

I mit eget hjemme-setup giver WiFi-forbindelsen fra PC'en til routeren ca. 1,5 millisekunders pingtid, hvor en kablet forbindelse til sammenligning giver ca. 0,5 millisekunder.

Hvis man går op i sin pingtid, er det i hvert fald en lavthængende frugt, hvis det er nemt at tilslutte et kabel i stedet.

Baldur Norddahl

Ja, det er egentlig ret spøjst at man ikke har gjort det i hardware endnu.

De fleste routere implementerer BFD på linjekortene (herunder også ZTE). Det er næsten det samme.

Men selvom ICMP echo reply (ping) var implementeret i hardware, så ville det stadig være en dårlig ide at pinge en router. Næsten alt den slags er rate limited og bliver sendt afsted med laveste QoS. Det er hellere ikke sikkert at ICMP pakker følger samme vej tilbage som den normale trafik.

Udbyder A benytter transitleverandør T1 og T2. Udbyder B benytter transitleverandør T1 og T3. Transitleverandør T3 har væsentligt lavere priser end transitleverandør T1. Der er en direkte peering mellem T2 og T3.

Hvis du som kunde hos A pinger en server hos B går trafikken A -> T1 -> B da det er den bedste (korteste) vej. Trafikken tilbage går derimod B -> T3 -> T2 -> A da udbyder B foretrækker at bruge den billigere vej igennem T3 selvom det er en længere vej.

Hvis du som kunde hos A pinger en server hos T1 så går trafikken A -> T1 og T1 -> A. Det vil sige at ser du på en traceroute, så følger trafikken fra alle de mellemliggende routere hos T1 en anden vej end de pakker der når helt ind i netværket hos B.

Hvis du som kunde hos A pinger den første router hos B, så er der en mulighed for at lige denne svarer direkte tilbage via T1 selvom B i alle andre situationer sender trafikken tilbage via T3. Det sker typisk hvis routeren hos B har fået en IP adresse af transitudbyderen T1 på peering interfacet (det er standard).

Trafikrouting på internettet er ekstremt asymmetrisk og hvis man ikke har en god fornemmelse af dette, så bliver man bare forvirret over at pinge routere som man har fundet via traceroute.

Hvis man skal kende en vej mellem to parter, skal man udføre traceroute fra begge sider. Og selv da skal man glemme alt om de ping tider der observeres fra de mellemliggende hop, for de pakker har måske fulgt en helt tredje vej.

Yoel Caspersen Blogger

Trafikrouting på internettet er ekstremt asymmetrisk og hvis man ikke har en god fornemmelse af dette, så bliver man bare forvirret over at pinge routere som man har fundet via traceroute.

Enig, man skal ikke stole for meget på traceroutes og ping-tider generelt.

Men det ville dog være rart, hvis en slutbruger kunne stole på den pingtid, han får op imod sin default gateway hos internetudbyderen. Den ville i vores setup faktisk være et udtryk for den minimalt opnåelige pingtid - hvis ikke det var fordi routeren nedprioriterer pakkerne og svarer med stærkt varierende pingtid hvis overhovedet.

Jesper Louis Andersen

En ret vigtigt detalje er at mange spilsevere medierer spillet mellem klienter. Hver spiller har sådan set sit eget spil de spiller og serveren skal så stykke virkeligheden sammen fra de brudstykker den får fra hver spiller og få deres spil til at hænge sammen den anden vej.

Der er en del trick, men det væsentlige er at du "spoler tiden tilbage" på serversiden for at se hvor en spiller var på et givet tidspunkt når du beregner om noget rammer eller ej. Moderne engines har som regel en hel del trick der udjævner noget af fordelen, så længe du kan få pingtiden ned under en 30ms eller sådan. Naturligvis er det fuldstændigt umuligt at redde den hvis du sidder med 70ms eller lignende, men længere nede kan du gøre visse ting for at optimere noget fairness mellem spillere der har forskellige pingtider.

Kristian Klausen

Hos Kviknet har vi derfor stillet en CS:GO-server til rådighed for kunderne. Serveren er tilsluttet vores netværk i København, og en DSL-kunde i Aalborg vil derfor typisk have en pingtid på ca. 13 ms, mens en coax-kunde i Odense har en pingtid på ca. 3 ms.

Jeg er lidt tvivlende over for ideen. Altså de fleste i CS:GO (min opfattelse) bruger mathcmaking, hvor spillet sørger for at finde spillere på omkring samme niveau, og så spiller men på en af de officielle Valve servere (men trafikken kører vist igennem nogle relays).

Det fint nok med en CS:GO server, men jeg kan ikke rigtig hvad det giver. De fleste i CS:GO bruger jo matchmaking, fordi det er let, hurtigt og man kommer til at spille med nogen på ca samme niveau. Så hvorfor gå ind på en "community" CS:GO server, uden alt det? For måske at spare 10 ms? Det kan ikke svare sig :)

Hvis man skulle gøre noget, så skulle man få en peering aftale i hus med Valve, det kan vist lade sig gøre.

Jan Juul Mortensen

Hvorfor skal internetforbindelsen lige en tur over et backbone i København, hvis nu serveren står hos naboen i Aalborg. Det at man hjemme bruger et kabel for, at hente 1 ms virker latterligt i forhold til hvad man kunne opnå, hvis ikke udbyderne absolut skal tvinge trafikken på tværs af landet, det virker dybt forældet i forhold til de tekniske muligheder og man belaster "motorvejene" i begge retninger unødigt.

Yoel Caspersen Blogger

Hvorfor skal internetforbindelsen lige en tur over et backbone i København, hvis nu serveren står hos naboen i Aalborg.

Det handler om økonomi. Hvis vi skal route trafikken lokalt i Aalborg, skal vi have en router på telefoncentralen i Aalborg, og på landsplan vil det være over 50 steder, der skal opstilles en router.

Mængden af trafik, der routes lokalt i Aalborg, er forsvindende lille, så det er en bedre forretning at nøjes med et mindre antal routere, som står mere centralt i landet.

Størstedelen af vores trafik kommer fra de store streaming-giganter som Netflix, Google osv, og her kommer trafikken alligevel fra København, da det er her, vi peerer med omverdenen.

Helge Svendsen

Hvad med blot at angive ping tiden fra internet skyen til ydersiden af kundens router?

Det er vel det eneste i reelt set har nogen indflydelse på.

Claus Krogsgaard-Mattsson

Sikkert ikke det rette forum, men hvorfor har jeg så høj ping på YouSee coax?

Du beskriver coax som 3 ms. fra Odense. På min coax i Hillerød Vest, har jeg 10-12 ms. til centralen i Hillerød (<6km). Det synes jeg ikke giver mening, men YouSee siger at det er standard :/ Har du input til at forbedre dette? Det skal siges, at før skiftet til DOCSIS3.1 udstyret i vejen, så lå den på 6-8 ms.

Yoel Caspersen Blogger

Hvad med blot at angive ping tiden fra internet skyen til ydersiden af kundens router?

Det er vel det eneste i reelt set har nogen indflydelse på.

Generelt har vi megen lille indflydelse på pingtiden i vores eget net, da noget af det afhænger af fysiske afstande, mens andre dele afhænger af topologien i vores underleverandørers netværk.

Men vi kan selvfølgelig give et kvalificeret gæt, bl.a. baseret på målt pingtid til andre kunder i samme område. Det kan dog ikke stå alene, men skal også ledsages af en her-og-nu-pingtid til den eksterne IP-adresse, brugeren er interesseret i, samt et udtrykkeligt forbehold for, at det kun er hvordan situationen ser ud lige her og nu, og ikke er et løfte om en eventuel fremtidig pingtid.

Pingtiden fra vores net og ud til andre IP-adresser på internettet er vi næsten ude af stand til at gøre noget som helst ved. I grelle tilfælde, hvor pingtiden stiger voldsomt i et hop tæt på os, kan vi rette henvendelser til vores upstream providers, og hvis der er forskel på pingtiden på vores upstream providers kan vi styre den udgående trafik i den bedste retning.

Yoel Caspersen Blogger

Du beskriver coax som 3 ms. fra Odense. På min coax i Hillerød Vest, har jeg 10-12 ms. til centralen i Hillerød (<6km).

Hvordan tester du pingtiden mod centralen i Hillerød? Er det din default gateway hos YouSee, som du pinger?

I så fald, er du så sikker på, der ikke sker en nedprioritering af ping-svaret?

Jeg har ikke dyrket spørgsmålet om pingtid på coax specielt meget, men blot taget udgangspunkt i nogle målinger, vi tidligere har lavet, som viste en pingtid på 5 ms fra København (heraf 3 ms i transportnettet). Det er meget muligt, der kommer nogle ekstra millisekunder på i DOCSIS 3.1-setup'et.

Claus Krogsgaard-Mattsson

Hvordan tester du pingtiden mod centralen i Hillerød? Er det din default gateway hos YouSee, som du pinger?

Jeg pinger en ip, der ligger sidst i Hi-domænet (centralen i Hillerød). Den ligger et hop længere nede end default gateway. Min router er sat i bro-tilstand, således jeg rammer en punkt ude i nettet som default gateway. Det punkt har helt klart en meget lave prioritering, da svartiden her er forringet med yderligere 4-6 ms., altså typisk omkring de 18 ms. Det skal siges, at mit stik ikke er opgraderet og jeg forsat har en af de asymetriske hastighedsprofiler. Jeg bliver opgraderet 5. juli til en symetrisk 300MBit/s (med nyt stik) og håber selvsagt at det giver yderligere stabilitet og lavere ping. Jeg måler relativt store udfald i svartideren (jitter), som også er steget efter opgraderingen af nettet. Jeg er ikke sikker på pingsvaret er nedprioriteret. Jeg har dog ikke målt under 10 ms. til nogen kilde, hverken i eller udenfor TDCs net.

Jacob Bunk Nielsen

Jeg havde tidligere en ADSL-linje fra Fullrate, som jeg fik ændret til "gamerprofil". Det betød at ping-tiden til første hop faldt fra 11-12 ms til 4-5 ms på en 10/2 Mbps linje. Det lyder ikke af meget, men det kunne tydeligt mærkes på de SSH-forbindelser jeg ofte kørte hen over linjen.

Baldur Norddahl

Her er et bud på hvorfor mange routere ikke implementerer echo reply i hardware. Lad os analysere hvordan den typiske router flytter trafik:

IP over ethernet pakker har en header hvor der blandt andet findes følgende felter:

Afsender MAC adresse
Modtager MAC adresse
Afsender IP adresse
Modtager IP adresse

En pakke afsendt fra en kunderouter til udbyderens default gateway har felterne udfyldt således:

Afsender MAC adresse: kunderouterens MAC adresse
Modtager MAC adresse: gateway routerens MAC adresse
Afsender IP adresse: kundens IP adresse
Modtager IP adresse: IP adresse hvor pakken skal sendes hen, eksempelvis IP adressen på version2.dk.

Bemærk at ovenstående netpakke ikke indeholder gatewayens IP adresse. Det er kun gatewayens MAC adresse der er med.

Linjekortet i gateway routeren kigger på feltet "modtager IP adresse". Der laves et opslag i routing tabellen. Dette opslag giver følgende oplysninger:

Udgående interface
MAC adresse på næste router

Linjekortet tager herefter den modtagne netpakke og retter headeren således:

Afsender MAC adresse: gateway routerens MAC adresse
Modtager MAC adresse: MAC adresse på næste router
IP adresserne rettes ikke

Herefter sendes pakken på det udgående interface.

Så langt så godt. Men hvad sker der hvis vi pinger default gateway? Det vil sige at vi sender en netpakke med gateway routerens IP adresse i feltet "modtager IP adresse".

Men linjekortet har ikke nogen egentlig IP stak og kan ikke fortolke IP pakker direkte. I stedet har routeren et ekstra skjult interface internt hvortil der sidder en lille computer forbundet. Ofte vil denne computer køre Linux, BSD eller et andet custom operativsystem. Ofte er dette interface et helt almindeligt 1 gigabit ethernet interface og computeren er i Raspberry PI klassen.

Tricket er så at der indlæses en ekstra route til gateway IP adressen i linjekortets routing tabel, således at "udgående interface" er det interne interface til den lille computer. Alle pakker til gateway IP adressen bliver dermed sendt til computeren. Det inkluderer også ping pakker.

Da Linux, BSD eller hvilket operativsystem de nu har valgt at bygge på, allerede implementerer en IP stak, herunder evnen til at svare på ping, så behøver router producenten ikke foretage sig yderligere. Det er muligt at man nemt kunne udvide linjekortets funktionalitet så det svarer på ping direkte, men vinder producenten flere ordre hvis de implementere dette?

En anden ting er at routerne ofte indeholder underdimensionerede computere. Det har ingen betydning for almindelig trafik som aldrig kommer i nærheden af computeren. Det er også almindeligt for selv kraftige routere at linket til computeren kun er et billigt 1 gigabit. Det giver en risiko for at man kan lave et denial of service angreb imod linket mellem dataplan og kontrolplan. Derfor har producenterne implementeret rate limit på stort set alt slags trafik til kontrolplanet. Der skal ikke sendes mange ping pakker før at linjekortet først sætter pakkerne i en kø og senere helt dropper dem.

Det korte af det lange er at man skal huske at linjekort / dataplan sjældent håndterer pakker hvor routerens egen IP adresse indgår som afsender eller modtager. Den slags pakker bliver sendt til kontrolplan. Moderne routere kan implementere undtagelser til denne regel som en optimering men forvent det ikke.

Jesper Louis Andersen

https://en.wikipedia.org/wiki/Content-addressable_memory

Typisk anvendes der en form for CAM til at udføre opgaven Baldur beskriver. Tabellen er ofte ret lille (under 1024 entries) og alt der ikke matcher ryger til Raspberry PI-kontrolkortet som så laver route-lookup og skifter ud i CAM-tabellen så næste opslag kører hurtigt.

Problemet med at lave Ping i hardware er at en fejl er fatal. Så af gode grunde holder man alt hvor det er muligt i software, hvor du bare kan firmware-opdatere routeren. Desuden har det den fordel at du kan opgradere ældre routerhardware uden at skulle ned og pille i dataplanet.

Uffe Callesen

Nu skal vi lige huske at interleaving typisk er aktiveret af en årsag (forbedret FEC) så det med blindt at slå det fra for at få lavere latency kommer med en (potentiel) omkostning i form af pakketab ;-) (og jeg gætter på at gamerne heller ikke er pisse vilde med pakketab).

Per Hvid

ISP konkurrerer på BD, men hvor er der ingen konkurrence på latency.
Hvorfor oplyser ISP'er ikke deres latency?

Ivo Santos

Jeg er så heldig at bo et sted (vanløse /København) hvor jeg har ren fiber forbindelse, og min ping tid til version2 er under 5 ms.

linux-cq11:~> ping -c 4 www.version2.dk
PING www.version2.dk (109.238.50.21) 56(84) bytes of data.
64 bytes from 109.238.50.21: icmp_seq=1 ttl=248 time=2.18 ms
64 bytes from 109.238.50.21: icmp_seq=2 ttl=248 time=2.13 ms
64 bytes from 109.238.50.21: icmp_seq=3 ttl=248 time=2.09 ms
64 bytes from 109.238.50.21: icmp_seq=4 ttl=248 time=2.11 ms

--- www.version2.dk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.098/2.132/2.181/0.045 ms

For en hel del år siden fik jeg en email fra en nordman som ville leje min, den gang, spille server fordi jeg åbenbart havde en god ping tid.

Og nu vi er ved ping tider så er det jo også en del som selv har en privat spilleserver kørende privat, hvad enter der er minecraft eller noget andet, og det er ping tider jo også vigtig, specielt når vi taler om f.eks. coax til coax, eller noget andet, hvilket også er vigtigt at tage med.

Yoel Caspersen Blogger

Nu skal vi lige huske at interleaving typisk er aktiveret af en årsag (forbedret FEC) så det med blindt at slå det fra for at få lavere latency kommer med en (potentiel) omkostning i form af pakketab ;-)

Enig, det skal bruges med varsomhed, og det er nok det første, man skal aktivere igen, hvis der er problemer med linien. Så det er ikke en one-size-fits all, men noget, der kan hjælpe i visse situationer.

Yoel Caspersen Blogger

Jeg mente: Hvorfor er der ingen konkurrence på Latency?

Nu gætter jeg kun - men på DSL vil de fleste selskaber et stykke hen ad vejen have den samme pingtid, da størstedelen udgøres af selve DSL'en, som i de fleste tilfælde termineres i TDC's DSLAM'er. Så kan de optimere deres transportnet, men pga. de fysiske afstande er der alligevel en grænse for, hvor meget de kan opnå her.

For fiberselskabernes vedkommende er den lavere pingtid faktisk en faktor, de reklamerer med i dag. Men hvis man er alt for specifik, når man lover kunderne lav pingtid, kan det til gengæld give problemer i forhold til support og bristede forventninger, hvis pingtiden stiger uden for udbyderens netværk og kontrol.

Hvorfor oplyser ISP'er ikke deres latency?

Af ovennævnte grunde og fordi de måske helst ikke vil have kunderne til at gå deres forbindelses tekniske egenskaber alt for meget efter i sømmene.

Hos Kviknet vil vi nu i åbenhedens ånd forsøge alligevel.

Jacob Bunk Nielsen

Oplevede du nogen stabilitetsproblemer med gamerprofil, og hvor meget kostede det dig på hastigheden - hvis noget overhovedet?

Nej, ingen stabilitetsproblemer overhovedet. Det kostede heller ikke noget på hastigheden, men jeg havde også kun en 10/2 Mbps linje. Så det var ren forbedring.

Jeg er klar over at det sikkert langt fra er alle der er lige så heldige, og jeg forstår sagtens hvorfor man som udbyder ikke giver at have support-bøvlet, hvis det giver anledning til problemer.

Yoel Caspersen Blogger

Jeg er klar over at det sikkert langt fra er alle der er lige så heldige, og jeg forstår sagtens hvorfor man som udbyder ikke giver at have support-bøvlet, hvis det giver anledning til problemer.

Vores hidtidige holdning har været, at det ikke gav nok, men det var baseret på vores egen interne test. Vi skal dog nok lige have testet nogle flere linier for at kunne drage den konklusion - hvis kunderne ønsker produktet, skal det jo bare prissættes korrekt, så det går op med den ekstra support.

Jesper Louis Andersen

Nu skal vi lige huske at interleaving typisk er aktiveret af en årsag (forbedret FEC) så det med blindt at slå det fra for at få lavere latency kommer med en (potentiel) omkostning i form af pakketab ;-) (og jeg gætter på at gamerne heller ikke er pisse vilde med pakketab).

Du vil rigtigt gerne lave det tradeoff! Lavere latency for eventuelt tab af pakker er 100% det rigtige at gøre i alle situationer. Vi har et kæmpe problem med at producenter at netværkshardware sælger "ingen pakketab". Det gør de ved at have enorme buffere i deres udstyr. Men en buffer er en kø og det går ud over latency. Desuden har mange ISPer også telenetværk så de har ingen interesse i at fjerne jitter og latency i deres IP-netværk. Sæt nu at Facetime, Skype og Hangouts virkede endnu bedre :)

TCP reagerer som udgangspunkt kun på pakketab som en indikator for at der sendes data for hurtigt. Hvis du absorberer pakkerne i en buffer i netværket opdager TCP først for sent at der er et problem, og det leder til yderligere jitter og latency i netværket. Det er fuldstændigt dræbende for et spil hvis der er for mange connections der bare hamrer derudaf. Google har for nyligt lavet BBR-congestion algoritmen for at undgå dette problem, men det er ikke specielt udbredt. Ideen at at du jævnligt prober for bandwidth/delay produktet så du rammer den optimale sendehastighed med mindst mulig latency. Så undgår du også stående køer i netværket. Se også CoDel.

De fleste latency-sensitive spil er UDP-baserede men sender ved forholdvist lave båndbredder. Alle spil siden ca Quake 3 kan håndtere at der tabes et par UDP pakker undervejs, så længe tabet er under en passende tærskelværdi. Man koder mod "sidste pakke vi ved klienten har modtaget" og holder historik over ældre world-states. Af den grund kan sådanne spil godt håndtere at der ryger en pakke i ny og næ, bare det ikke er alt for mange (1 ud af 500 er et rimeligt bud).

Frans Josef Meyer

""Hvorfor oplyser ISP'er ikke deres latency?""

Jeg savner mere at ISP'erne oplyser deres peerings relationer, særligt de nationale.

Jeg ved ikke hvor kendt det er - men der er 2 af de store erhvervs rettet og markedsdominerende ISPer som har droppet deres tidl. direkte peering mellem sig, hvilket resultere i at der nu sker et asymmetrisk trafik flow mellem dem via to 3. parter og selvom asymmetrisk trafik flow ikke kan undgås globalt, så er det dog at fortrække med et symmetrisk og national trafik flow, mellem aktøre, nationalt.

Hvis jeg som kunde hos en dansk XYZ ISP'er skal rundt om et IX i NewYork for at browse rundt hos dr.dk vil jeg anse det for en så uforventelig ting ved produktet at jeg bør være oplyst om det før indgåelse af abn.

Jeg var ude for at et mobil selskab fast sendte alt deres danske trafik rundt om et IX i udlandet, og tilbage til DK derfra, hvis man hev fat bestemte dansk hostet tjenester - men ikke alle, hvilket gav unødvendig høj latency til de pågældende, da jeg gjorde dem opmærksom herpå, rettet de det uden at "kny" - derimod er svaret fra de 2 erhvervs rettet og markedsdominerende ISPer, kort sagt: Nå!

Branchen burde selv oprette en gennemsigtighed politik og klar varedeklaration på det punkt .

Hvis jeg tager toget med DSB til Skive fra Kbh. - og på et stykke af vejen bliver befordreret af et Arriva tog, forventer jeg at de 2 er forbundet, så jeg ikke skal tage en taxa mellem en DSB station og en Arriva station undervejs, fordi de 2 selskaber ikke er på talefod, og ikke vil mødes på en fælles station.
Og hvis det er således, så skal de pro-aktivt oplyse det på forhånd.
Ikk? :-)

Jens Jönsson

P.S. Pingtiden er også vigtig for en anden slags gamere, nemlig high-frequency traders, som lever af at game aktiemarkedet gennem front running. Her kan selv få millisekunder betyde forskellen på at tjene eller tabe milliarder - eller ødelægge verdensøkonomien. Nogle gange begge dele.

Det sjove er jo så faktisk at der ikke bruges fiber. Det er primært trådløst, som leverer en bedre latency end fiber, da signalet fysisk går den mere direkte vej...

https://arstechnica.com/information-technology/2016/11/private-microwave...

Jens Jönsson

For fiberselskabernes vedkommende er den lavere pingtid faktisk en faktor, de reklamerer med i dag. Men hvis man er alt for specifik, når man lover kunderne lav pingtid, kan det til gengæld give problemer i forhold til support og bristede forventninger, hvis pingtiden stiger uden for udbyderens netværk og kontrol.

Det er jo så her det bliver sjovt. Jeg har nævnt det før og gør det gerne igen. De kunder vi har på trådløst har bedre latency end jeg f.eks. har på den Stofa fiber jeg har hjemme privat. Det fremgår faktisk meget klart og tydeligt af Yoel fine beskrivelse....

De 2-3 ms mellem kunde og central/mast udstyr, betyder så lidt i det store spil. Traditionelt har man bare altid sagt at latency er lavest på fiber. Det er så ikke altid tilfældet. Fast trådløst kan f.eks. sagtens være med....

Jens Jönsson

Sikkert ikke det rette forum, men hvorfor har jeg så høj ping på YouSee coax?

Du beskriver coax som 3 ms. fra Odense. På min coax i Hillerød Vest, har jeg 10-12 ms. til centralen i Hillerød (<6km). Det synes jeg ikke giver mening, men YouSee siger at det er standard :/ Har du input til at forbedre dette? Det skal siges, at før skiftet til DOCSIS3.1 udstyret i vejen, så lå den på 6-8 ms.

Latency på COAX er meget afhængigt af hvor meget (eller lidt) støj der er på COAX nettet.
Når youSee og andre (os selv inklusiv) opgraderer til DOCSIS v3.1 og dermed højere båndbredde, så stiller det (meget) større krav til det fysiske net.
Er der meget støj, så vælger CMTS'en en anden profil hvad angår modulering.
Det sikrer så mod pakketab, men i stedet stiger latency.

Du skal huske at der er stor forskel på hvor meget data der kan klemmes igennem på samme frekvensbredde. Det er QAM moduleringen der afgør det. Des mindre støj des bedre mulighed for at køre højere QAM modulering.

Det er sådan set samme problematik som Interleaving/Fastpath på xDSL....

Jens Jönsson

Vi har et kæmpe problem med at producenter at netværkshardware sælger "ingen pakketab". Det gør de ved at have enorme buffere i deres udstyr.

Det er mange gange et problem på f.eks. fiber netværk. På http://www.dslreports.com/speedtest får du testet din forbindelse for bufferbloat (en årsag til at en (fiber)forbindelse kan føles såååååååå langsom)....

Læs mere på http://bufferbloat.net og aktiver FQ_Codel i din router....

Jens Jönsson
Benny Lyne Amorsen

Det er muligt at man nemt kunne udvide linjekortets funktionalitet så det svarer på ping direkte, men vinder producenten flere ordre hvis de implementere dette?


Det tror jeg personligt på at de gør. Jeg kan i al fald godt forestille mig hvor lange threads der vil være på diverse NOF-lister... Om ikke andet så vil det skaffe meget omtale blandt de relevante mennesker.

Log ind eller opret en konto for at skrive kommentarer