Jump to content
Kvalm

Hastighedstest af bredbånd

Recommended Posts

Jeg har fiberlan 50-100 mbit i hjemmet. Når jeg tester forbindelsen på bredbandkollen.se og http://hastighedstest.tdc.dk får jeg ikke samme resultat. Dette uanset hvad jeg vælger af målestation på bredbandkollen. Bredbandskollen - 94 download og 12 upload TDC - oftest det halve vedr. download og 15 mbit upload DOG har jeg lige haft en download hastighed med TDC på 87 mbit. Det er lige fra væggen uden andet udstyr end en Realtek RTL8168C tilkoblet - og der er ingen trådløse telefoner til at genere. Hvorfor er der forskel på målingerne?

Del dette indlæg


Link til indlæg
Del på andre sites

TDC's hastigheds test er gearet til ADSL og VDSL brugere...ikke til at teste fiberkunder. Prøv inde på f.eks. http://speedtest.net/ Men den kan nu også væltes hvis du sidder på en 1/1 Gbit/s linje ;) Endnu være bliver det hvis du bruger IT og telestyrelsen's TPtest...da den kan have problemer med at følge med en 20Mbit/s linje. Så det korte af det lange er at du bruger det forkerte "værktøj". PS. Lantency har ingen indflydelse på hastighed. Mvh Henrik, Netværkstekniker.

Del dette indlæg


Link til indlæg
Del på andre sites
TDC's hastigheds test er gearet til ADSL og VDSL brugere...ikke til at teste fiberkunder. Prøv inde på f.eks. http://speedtest.net/ Men den kan nu også væltes hvis du sidder på en 1/1 Gbit/s linje ;) Endnu være bliver det hvis du bruger IT og telestyrelsen's TPtest...da den kan have problemer med at følge med en 20Mbit/s linje. Så det korte af det lange er at du bruger det forkerte "værktøj". PS. Lantency har ingen indflydelse på hastighed. Mvh Henrik, Netværkstekniker.
Goodie - resultat er: ping: 5 ms, download 94 mbit, upload 15 mbit :)

Del dette indlæg


Link til indlæg
Del på andre sites
PS. Lantency har ingen indflydelse på hastighed.
Du skal vist have lidt penge tilbage, så... ;) Hvis du eks. har 20ms mellem A <-> B, så kan en ACK modtages, lad os sige 5 x hurtigere, end via A<->B med en latency på 100ms. (groft sagt) Med højere latencies, så går det endnu mere galt, da tcp-data skal vente endnu længere på at få svar - og derefter kunne sende næste pakke. Jow - så kan du udnytte UDP, som ikke er lige så afhængig af latency. Men så mister du data-korrektion, medmindre du implementerer en mekanisme/ekstra layer til (igen) at overvåge trafikken, og gensende korrupte/tabte pakker. Så snart vi skal ud på de Interwebs'ske stepper, så kan vi heller ikke bruge samme MTU som på vore lokalnetværk - og så sætter vi endnu et par faktorer i sving, som kan have indflydelse på hastigheden, da pakkerne nu fragmenteres yderligere. Osv osv... Et gammelt skriv, for at linke til noget, kunne være eks.: http://rescomp.stanford.edu/~cheshire/rants/Latency.html

Del dette indlæg


Link til indlæg
Del på andre sites
Så hva er dommen efter' date=' at du nu har modtaget pingværdierne :)[/quote']Dine pingværdier burde ikke have noget at sige, når vi er nede i sådanne småtterier. Forskellen er minimal på dine opgivne værdier (på den givne hastighed din linie kan levere). Havde du derimod haft høj latency, evt. kombineret med pakketab, så ville der være noget at komme efter.

Del dette indlæg


Link til indlæg
Del på andre sites
Dine pingværdier burde ikke have noget at sige' date=' når vi er nede i sådanne småtterier. Forskellen er minimal på dine opgivne værdier (på den givne hastighed din linie kan levere). Havde du derimod haft høj latency, evt. kombineret med pakketab, så ville der være noget at komme efter.[/quote'] Goodie - jeg lader være at rekvirere en comhem-tekniker så :) Thanx folks !

Del dette indlæg


Link til indlæg
Del på andre sites
Du skal vist have lidt penge tilbage, så... ;) Hvis du eks. har 20ms mellem A <-> B, så kan en ACK modtages, lad os sige 5 x hurtigere, end via A<->B med en latency på 100ms. (groft sagt) Med højere latencies, så går det endnu mere galt, da tcp-data skal vente endnu længere på at få svar - og derefter kunne sende næste pakke. Jow - så kan du udnytte UDP, som ikke er lige så afhængig af latency. Men så mister du data-korrektion, medmindre du implementerer en mekanisme/ekstra layer til (igen) at overvåge trafikken, og gensende korrupte/tabte pakker. Så snart vi skal ud på de Interwebs'ske stepper, så kan vi heller ikke bruge samme MTU som på vore lokalnetværk - og så sætter vi endnu et par faktorer i sving, som kan have indflydelse på hastigheden, da pakkerne nu fragmenteres yderligere. Osv osv... Et gammelt skriv, for at linke til noget, kunne være eks.: http://rescomp.stanford.edu/~cheshire/rants/Latency.html
Nej, nej og atter nej. Hvis dit udsagn var sandt ville båndbredden falde linært med afstanden. Det gør den ikke. Det eneste tidspunkt din lantency (by proxy) vil påvirke din hastighed er ved en bottleneck, f.eks en core-router der har for meget throughput. Medmindre du sidder på et 36.6K modem...dit link kunne seriøst trænge til at blive opdateret. Man skal også kigge på protokol latency. Dette er fra samme adresse, samme ledningsvej til samme DSLAM på samme central: SHDSL
Pinger www.tm.se [84.243.62.13] med 32 byte data:
Svar fra 84.243.62.13: byte=32 tid=4ms TTL=55
Svar fra 84.243.62.13: byte=32 tid=4ms TTL=55
Svar fra 84.243.62.13: byte=32 tid=4ms TTL=55
Svar fra 84.243.62.13: byte=32 tid=4ms TTL=55
ADSL2+:
Pinger www.tm.se [84.243.62.13] med 32 byte data:
Svar fra 84.243.62.13: byte=32 tid=29ms TTL=54
Svar fra 84.243.62.13: byte=32 tid=29ms TTL=54
Svar fra 84.243.62.13: byte=32 tid=29ms TTL=54
Svar fra 84.243.62.13: byte=32 tid=29ms TTL=54

Hvis du trak en black fiber direkte herfra og om på den anden siden af Jorden ville lantency stadig ikke ændre throughput. Grunde til du oplever lave hastigheder fra f.eks Asien er ikke pga. latency...menmangel på båndbredde i deres peerings...det samme glder for USA...bottleneck der er de kalber der ligger tværs over Atlanten...og det ved du jo godt selv:

Dine pingværdier burde ikke have noget at sige' date=' når vi er nede i sådanne småtterier. Forskellen er minimal på dine opgivne værdier (på den givne hastighed din linie kan levere). Havde du derimod haft høj latency, evt. kombineret med pakketab, så ville der være noget at komme efter.[/quote'] Vi snakker ikke 36K her...

Del dette indlæg


Link til indlæg
Del på andre sites

Oh yes - det var et gammelt link...helt med vilje ;) Faktum er dog stadig, at din båndbreddes effektivitet falder med øget latency. Eksempel: Båndbredde: 10000 Kbps Latency: 5ms Throughput (tcp): 9950 Kbps -- Båndbredde: 10000 Kbps Latency: 100ms Throughput (tcp): 2017 Kbps Pakketab: 0.5% (eksempel) Max TCP Window: 65536 (Kb) Packet payload: 1472 ...og så videre. Og ja - båndbredden ændrer sig ikke. Men dataene fylder mindre og mindre på linien når latency stiger = nedsat hastighed. Giver det bedre mening? (i.f.t. det jeg egentlig prøver at kommunikere ud :))

Del dette indlæg


Link til indlæg
Del på andre sites

Jeg ser også langsomme hastigheder til DK i forhold til SE. For mig ser det ud til at min udbyder (Rätt Internet Kapacitet i Sverige AB) har knap så gode peerings til DK Heldigvis er det ikke lige DK jeg har behov for de helt høje download-hastigheder fra.

Del dette indlæg


Link til indlæg
Del på andre sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gæst
Svar på dette emne...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Tilføj...