yoel caspersen blog bloghoved

Juleopgave del 3: En retvisende hastighedstest

Af 37

Forleden lærte jeg, at julen ikke slutter, når juletræet den 27. december strippes for sin pynt og stilles udenfor til skam og vanære, men faktisk varer indtil 6. januar.

Jeg kan derfor med god samvittighed på årets sidste dag offentliggøre 3. og sidste afsnit af vores juleopgave omkring hastighedsoptimering hos kunderne, og i dag skal det handle om, hvordan vi dokumenterer, at vi leverer den hastighed, kunden har bestilt.

Med høje hastigheder kommer høje forventninger

Mange af vores coax-kunder vælger at opgradere til 300/60 Mbit/s, og vores bolignetkunder har netop fået mulighed for at komme op på 500 Mbit/s, og inden længe vil hastigheden komme helt op i nærheden af den fysiske grænse på et 1 Gbit/s interface, der ligger lige omkring 920 Mbit/s.

At lave en speedtest, der kan dokumentere 920 Mbit/s er ikke trivielt.

For det første er der rigtig mange ting, der kan gå galt - er kundens PC koblet direkte til routeren med et kabel, er der noget på PC'en, der sløver den, fx antivirus, og er vi sikre på, at vores access-netværk hos den specifikke kunde faktisk kan levere 1 Gbit/s ekstra?

Når det er afklaret, kommer næste udfordring: Speedtest-serveren i den anden ende. Dels skal forbindelsen hele vejen hen til serveren kunne bære 1 Gbit/s trafik, men da en testserver typisk betjener mange samtidige brugere, skal selve netværksinterfacet på testserveren være over 1 Gbit/s - hvilket i praksis vil sige 10 Gbit/s.

Dertil kommer spørgsmålet, om hastigheden skal kunne måles på en enkelt stream, hvilket i praksis udelukker LAGs bestående af n x 1 Gbit/s interfaces på testserveren.

Vi anbefaler altid kunden at teste op mod vores egen server, men vi ved også, at de fleste blot ukritisk vælger den første og den bedste hastighedstest, de kan finde på nettet.

Rigtig mange hastighedstests er baseret på Ooklas Speedtest.net, og vi har gennem længere tid hørt rygter om, at folk fik meget forskellige resultater herfra.

Speedtest.net har en række danske testservere, der står hos de fleste større internetudbydere, heriblandt også en testserver hos Kviknet, og vha. en algoritme udvælger Speedtest.net en testserver i nærheden, når en bruger skal foretage en hastighedstest.

En forklaring på svingende resultater kan derfor være, at der er forskel på disse testservere og deres opkobling til internettet.

Vi satte os derfor for at undersøge og dokumentere dette, og i første omgang har vi opsat en probe på en af vores egne servere, der hver time foretager en download-test fra hver af de danske testservere på Speedtest.net.

Målingerne kan ses på vores website, og jeg må tilstå, at jeg er en smule overrasket over resultatet.

Illustration: Screenshot fra Kviknets hastighedsmåling

Ikke uventet er serverne opdelt i to hovedgrupper - over og under 1 Gbit/s, som med stor sandsynlighed afslører, om den enkelte server er tilkoblet med 10 Gbit/s interface eller 1 Gbit/s interface.

Illustration: Screenshot fra Kviknets hastighedsmåling

Men gruppen med hastigheder under 1 Gbit/s indeholder også et par servere, som med stor sandsynlighed giver direkte misvisende resultater, så snart hastigheden på kundens forbindelse overstiger 100 Mbit/s.

I en tid, hvor flere og flere internetudbydere begynder at sælge forbindelser i nærheden af 1 Gbit/s, bør de enkelte testserveres ejere overveje, om ikke man skulle opgradere til 10 Gbit/s interface eller så småt begynde at lukke sine testservere ned.

Er vores målinger retvisende?

Svaret er simpelt: Nej, det er de ikke altid, men det er work-in-progress, og det er det bedste, vi har på nuværende tidspunkt.

Især når vi kommer over 1 Gbit/s kan der være usikkerheder i målingen, da vi rammer loftet for vores egen probe mellem 2 og 3 Gbit/s.

Blandt de høje hastigheder kan store udsving fra måling til måling også være et udtryk for overbelastede peering-links mellem vores egen probe og den testserver, der måles på.

Selve testen udføres med wget, og her støder vi ind i en begrænsning: Wget henter kun data med 1 TCP-forbindelse, og derved ender trafikken på en enkelt CPU i vores probe-server, som agerer flaskehals.

Der er 16 TX/RX queues på netkortet, og hvis vi kan finde eller udvikle en klient, som henter med flere streams, kan vi øge throughput og dermed give et mere reelt billede af, hvor høj kapacitet en bruger kan forvente fra den enkelte testserver.

Derudover tester vi p.t. kun downstream hastighed set i forhold til klienten, men det er som regel også den retning, der er vigtigst for den enkelte.

Vores samlede anbefaling til kunderne er derfor således:

  • Foretag kun speedtest med kabel direkte fra computer til router
  • Sluk for antivirus, torrent-klienter og andet, der kan forstyrre testen
  • Vælg Kviknets testserver på Speedtest.net eller en tilsvarende server med høj kapacitet
  • Husk, at en høj hastighed på internetforbindelsen ikke garanterer, at man altid kan hente data med høj hastighed - ligesom en Porsche ikke bringer en hurtigere frem i trafikken i myldretiden, er den oplevede hastighed på internettet et produkt af mange faktorer, hvoraf størstedelen faktisk ligger uden for internetudbyderens kontrol

Gode forslag fra læserne til forbedring af vores monitorering af de danske testservere modtages gerne.

Tilbage er der blot at ønske jer alle et rigtig godt nytår - med eller uden Dronningens nytårstale!

Relateret indhold

Kommentarer (37)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jens Jönsson

Da vi begyndte at levere hastigheder over 100 Mbit/s fandt jeg hurtigt ud af, hvor mange speedtest servere der reelt slet ikke kan levere. Lige meget hvor ny PC og hvor hurtig forbindelse jeg sad på, kunne jeg mange gange ikke få presset mere data igennem end et par hundrede Mbit/s. For at teste lavede jeg derfor en speedtest server på eget lokal net og testede op i mod. De viste sig derfor tydeligt, at min PC godt kunne følge med. Den havde en ren Windows 10 installation og Intel netkort med nyeste drivere. Det var andre steder fra PC og mod testserveren, som var et problem...

Man skal derfor som kunde kun benytte speedtest som en retningsvisende test, der indikerer om der i kæden fra kunden til serveren kunne være noget galt.

Jeg fandt også ud af, at især "firewall" fra Antivirus producenter har det med at sløve PC'ens forbindelse til Internet helt betragteligt ned i hastighed....

Interessant at se at store udbydere som SE og Waoo har så "sløve" testservere. De burde da om nogen ha' fart over feltet....

  • 4
  • 0
#2 Claus Bruun

Hej

Interessant information.

Er kurverne en sp-line over én dag eller har i målt over flere dage og midlet ? Hvis I har data fra flere dage/uger, kunne det være interessant at set alle målingerne oven- i-hinanden. Så man kan danne sig et billede over, om kurven gentager sig hver dag/uge og derfor afspejler forbrugsmønstret.

Jeg har tidligere prøvet at måle ind- og udgående trafik på mit arbejde, hvor resultaterne blev plottet, som dots hen over ugen, men med alle uger oven-i-hinanden. Og efter nogle uger kunne man tydeligt se mønstret.

  • 1
  • 0
#3 Yoel Caspersen Blogger

Er kurverne en sp-line over én dag eller har i målt over flere dage og midlet ?

Nej, der er tale om øjebliksbilleder hver time. Man kan få en pænere kurve ved at tage et gennemsnit over flere målinger, men egentlig vil vi jo gerne se, om man kan tage en hastighedstest med høj hastighed sådan cirka lige nu - og hvis der er afvigelser fra normen for den enkelte testserver, er det næsten mere relevant end et gennemsnit, såfremt afvigelsen ikke skyldes fejl i vores måling.

  • 1
  • 0
#5 Yoel Caspersen Blogger

Hold da op en rutsjebane!

Der er nogle af serverne på listen, hvor hastighedsmålingerne generelt svinger ret meget, mens andre servere på listen ser ud til at udvise en mere konsistent performance i området over 1 Gbit/s.

Det gælder fx lige nu og her serverne fra Fibia og TDC, hvor grafen ser ret jævn ud.

Spørgsmålet er, om man heraf kan udlede, at de "stabile" servere kører på dedikeret hardware.

Hvis udsvingene i målingerne på de "ustabile" servere er størst om aftenen, indikerer det en flaskehals i et peering-link, men umiddelbart er der også store udsving for mange af serverne i løbet af dagen. Det lugter lidt af, at der måske er tale om test-servere, som kører på virtuelle maskiner uden dedikerede ressourcer.

I øvrigt ser der ud til at være trængsel i området 700 - 900 Mbit/s. Mange af serverne i dette område udviser også en konsistent performance, hvilket tyder på, at flaskehalsen alene findes i den enkelte servers 1 Gbit/s netværksinterface.

Kviknets egen testserver er i øvrigt en LXC-instans i et Proxmox-cluster.

  • 1
  • 0
#8 Lasse Mølgaard

Over tid er jeg enig i at BitTorrent kan udnytte ens forbindelse maksimalt, men det er primært i begyndelsen, det går langsomt med at downloade.

Så hvis du vil have et retvisende billede, vil jeg tro du skal kigge på hvor hurtig hastigheden er efter 5 minutter.

Det kræver til gengæld at man kan downloade en passende stor fil, hvis formålet er at se om man virkelig har en 1 Gbps forbindelse.

Lidt matematik siger mig at testfilen skal i så fald fylde minimum 35 GB.

Jeg ved ikke om man kan tweake BitTorrent til at komme op på maksimal båndbredde hurtigere?

  • 0
  • 0
#9 Martin Jensen

Det kommer helt an på hvad man henter, og dermed hvem der seeder.

Hent f.eks. nyeste Centos-Everything DVD .iso på ca. 8 GB - der plejer jeg at være max 2 sekunder om at maxe min linie ud og finde en ny flaskehals,

Du kan godt optimere BitTorrent drastisk. Standard-værdierne er typisk tilpasset beskedent hardware og ganske små forbindelser. Du skal typisk 1) hæve antallet af forbindelser der må være i brug, 2) hæve antallet af samtidige halv-åbne forbindelser og 3) reducere delay mellem nye forbindelser forsøges oprettet.

På den måde får du langt hurtigere afsøgt den swarm der er om en Torrent, får fat i seeds og peers, og går fra waiting slots til upload slots.

Som en sidebemærkning får du også testet din routers håndtering af mange åbne forbindelser, især indenfor UDP, og hvis din linie er hurtig, din maskines storage subsystem.

en minimal browser-kodet iperf3 implementering vil nok være et bedre bud til Hr. og Fru standard-kunde. :-)

  • 2
  • 0
#10 Yoel Caspersen Blogger

Kunne man ikke lave en hastighedstest der benytter sig af torrent netværket, på den måde kan man have flere servere og i hele landet, hvor folk forbinder og henter fra.

Jeg var egentlig lidt skeptisk, da jeg først læste dit forslag, men jeg må indrømme, at jeg efter at have tænkt over den lidt tid begynder at synes bedre og bedre om det.

Så vidt jeg kan se, kan man kode en web-baseret torrent-klient baseret på fx https://webtorrent.io/

Hvis man har et antal faste seeders (fx som replacement/supplement til teleselskabernes Ookla-servere), kunne det muligvis hjælpe med at sikre oppetid og kvalitet af speedtesten når vi kommer op i hastighed.

Kan en JavaScript-baseret torrent-klient mon følge med, hvis man skal op på 1 Gbit/s trafik i hver retning?

  • 0
  • 0
#12 Martin Jensen

Jeg har med konsum routere oplevet enheder der havde en mærkelig tilgang til UDP states, så ting der afsøgte med UDP, f.eks. discovery af spilservere - hvor BT var mest udslagsgivende, fik andet UDP til at timeoute/faile. Det gav f.eks. udslag i DNS opslag der fejlede eller var meget langsomme, så internet - oplevelsen blev ødelagt.

Jeg har ikke prøvet UDP* gennem CGN, men det gør jo sikkert ikke noget godt for noget.

  • 1
  • 0
#13 Mads Lahrmann

I bund og grund, så er UDP vel den optimale måde at teste båndbredde på.. TCP's venten på svar mellem hver x pakke kan give ret store udfordringer - i hvert fald ved enkelte streams.. Så spilder man heller ikke tid/data på for mange ack's sendt til afsenderen.

  • Personligt bruger jeg kun ooklas beta da jeg har ret dårlige performancemæssige erfaringer med den flash baserede.. men kan sagtens være det blot er mig?
  • 0
  • 0
#14 Anders Trier Olesen

Selve testen udføres med wget, og her støder vi ind i en begrænsning: Wget henter kun data med 1 TCP-forbindelse, og derved ender trafikken på en enkelt CPU i vores probe-server, som agerer flaskehals.

Alternativt kan "aria2" på en debian-like maskine kan installeres med:

# apt install aria2

Ex for download med 16 forbindelser:

$ aria2c -x 16 http://mirrors.dotsrc.org/speedtest/10GiB

Fra mirrors.dotsrc.org burde der være ret god forbindelse. Vi har 10G netkort i serveren, og 10G forbindelse til DeiC's router der burde være godt forbundet til DIX'en: https://info.net.deic.dk/traffic/1e6421ce053562956073f92eae75caf7.html

Derudover bruger vi Google's BBR algoritme til congestion control, der giver højre thrughput på forbindelser med lidt pakketab. Det har jeg skrevet lidt mere om her: http://anderstrier.dk/2017/09/07/using-googles-bbr-congestion-control-on...

  • 3
  • 0
#15 Jens Jönsson

Derudover bruger vi Google's BBR algoritme til congestion control, der giver højre thrughput på forbindelser med lidt pakketab. Det har jeg skrevet lidt mere om her: http://anderstrier.dk/2017/09/07/using-googles-bbr-congestion-control-on...

Anders, dit blog indlæg viser med alt tydelighed, at en standard opsætning af netværksenheder, aldrig vil performe optimalt.

Jeg har en Stofa fiber hjemme, og er altid blevet downvotet af fiberfanatikerne, som tror at fiber er den hellige gral. Faktisk har jeg længe været irriteret over at kunder på vores trådløse forbindelse har bedre svartider og mere konstant download end jeg har på Stofa fiberen. Jeg satte mig derfor for at se om jeg kunne tune både min Windows, men også min forbindelse, så det kørte lidt bedre. Min EdgeRouter har med SmartQueue (Som i bund og grund er FQ QDISK i Linux, som du også benytter (FQ = FQ_CODEL læs mere her: https://www.bufferbloat.net/projects/)) aktiveret, fået løftet min forbindelse en anelse. Resten er uden tvivl længere ude i systemerne.

Som kunde skal man desværre ikke forvente at ens Internetforbindelse er optimeret, så man får det bedste ud af den. Man skal også kigge på eget udstyr, som f.eks. router osv. Nyeste drivere på netkortet og tuning af parametre på det, kan også gøre en stor forskel.

Det er desværre ikke "bare lige".....

Denne hastighedstest giver dig i øvrigt en Buffer Bloat score.... http://www.dslreports.com/speedtest

Den er ekstrem CPU krævende, så den er uinteressant på en ældre enhed....

  • 0
  • 2
#16 Jens Jönsson

Hvis udsvingene i målingerne på de "ustabile" servere er størst om aftenen, indikerer det en flaskehals i et peering-link

Det er jo bla. et af mange problemer med hastighedstest. For at udføre en troværdig test, så skal man som kunde, som du iøvrigt også nævner, teste på ens udbyders egen server. Når først trafikken har forladt ens udbyders net, så er det jo ude af kontrol (ihvertfald for udbyderen), hvad der reelt sker med pakkerne.

Det fandt jeg for alvor ud af, da jeg skulle lave VPN der forbinder et satellitkonto ude i verden, med hovedkontoret i DK. Jeg har i sin tid lavet det for et par selskaber med flere lokationer ude i verden. Faktisk var tommelfingerreglen, at man ikke skulle bruge det lokale statsselskab, der var blevet privatiseret. Den bedste forbindelse og hul videre ud i verden, fik man stort set altid hos "den frække dreng i klassen". Forskellen kunne være så stor som 200% i båndbredde. Det kunne prisen i øvrigt også....

  • 0
  • 0
#17 Simon Toft

Hvor mange hops er der fra de forskellige? På siden skriver i: "Målingerne skal læses med forbehold for, at det er den målte hastighed mellem en server hos Kviknet og den pågældende server hos Speedtest.net." - Er det så ikke hastigheden mellem en server på jeres net og en server på jeres net? Det er de andre vel ikke?

  • 0
  • 0
#18 Kim Henriksen

Når vi nu begynder at nærme os halve og hele gigabit internet forbindelser.

Det kræver vel, at der er optimeret i afsender/modtager ende for at få den fulde udnyttelse, jævnfør Henrik Kramshøjs gode blog indlæg om tcp tuning her på Version2.

Jeg ville ikke forvente en eller anden random budget Acer consumer bærbar fra Elgiganten med standard Windows + bloatware image performer maksimalt, på et gennemsnitlig dansk wifi netværk.

  • 2
  • 0
#19 Martin Jørgensen

Efter at jeg ramte 800+ Mbps på en speedtest server første tænkte jeg også, hvordan kan jeg teste det i daglig brug. Så fandt jeg ud af at Steam leverer spil op til 1 Gbps, hvilket også hurtigt viste sig at være det sted der bedst udnytter båndbredden hos mig. OBS, andre spilplatforme som UPlay allokerer ikke alt harddiskpladsen først, hvilket ser ud til at sætte en begrænsning af den effektive download hastighed selv med ssd.

  • 0
  • 0
#20 Jens Jönsson

Hvor mange hops er der fra de forskellige? På siden skriver i: "Målingerne skal læses med forbehold for, at det er den målte hastighed mellem en server hos Kviknet og den pågældende server hos Speedtest.net." - Er det så ikke hastigheden mellem en server på jeres net og en server på jeres net? Det er de andre vel ikke?

Det er jo så meget forskelligt, afhængigt af fra hvilken udbyder du tester og til hvilken udbyder speedtest serveren er hostet.

Jeg har sagt det før og gentager gerne. En speedtest er retningsgivende test, ikke en retvisende test....

  • 0
  • 0
#21 Yoel Caspersen Blogger

Hvor mange hops er der fra de forskellige?

AS-hops eller router-hops?

Er det så ikke hastigheden mellem en server på jeres net og en server på jeres net? Det er de andre vel ikke?

Det er korrekt at testen mellem vores probe og vores server sker i vores eget net, mens testen mellem vores probes og resten af serverne sker hen over 1 eller 2 mellemliggende udbyderes netværk, typisk gennem GlobalConnect, som er en af vores transitudbydere.

De københavnske servere på listen er typisk inden for 0,3 - 2 ms RTT mens fx TDC's Århus-server er 5 ms og Telenors Aalborg-server er lidt over 7 ms fra vores probe.

Så testen er alene et udtryk for, hvordan det ser ud, når man måler fra Kviknets netværk, hvilket de fleste af vores kunder må antages at gøre.

Kan man så bruge det til at afgøre, hvilke servere, der er hurtigst, når vi taler de høje hastigheder?

Nej, for det afhænger jo fuldstændig af, hvorfra man måler, og det er heller ikke formålet med denne øvelse.

Men hvis vi skal forholde os til en kundes påstand om, at hastigheden er for lav, er vi nødt til at vide, hvilken server, han har målt den på, for som vores tests viser, er der mange servere, som af forskellige årsager ikke kan følge med på de høje hastigheder.

  • 2
  • 0
#22 Baldur Norddahl

Kviknet, Gigabit og mange andre er medlem af NLNOG Ring netværket. Man kan derfor gentage testen men målt fra mange forskellige udbyderes netværk. Ikke at jeg tror resultatet bliver meget anderledes.

Man vil naturligvis være nødt til at frasortere resultater fra ring noder der ikke har 10G.

  • 1
  • 0
#23 Yoel Caspersen Blogger

Alternativt kan "aria2" på en debian-like maskine kan installeres

Tak for forslaget - men umiddelbart får jeg en fejl, når jeg forsøger at bruge aria2 på en Ookla-server - fx:

aria2c -x 2 -d /dev -o null --allow-overwrite=true --file-allocation=none "http://ookla1.kviknet.dk:8080/download?nocache=x&size=50000000"  
   
01/03 10:51:15 [ERROR] CUID#6 - Download aborted. URI=http://ookla1.kviknet.dk:8080/download?nocache=x&size=50000000  
Exception: [AbstractCommand.cc:398] errorCode=1 URI=http://ookla1.kviknet.dk:8080/download?nocache=x&size=50000000  
  -> [RequestGroup.cc:714] errorCode=1 Download aborted.  
  -> [DefaultBtProgressInfoFile.cc:277] errorCode=1 total length mismatch. expected: 50000000, actual: 10737418240  
   
01/03 10:51:15 [NOTICE] Download GID#44779ee42870d809 not complete: /dev/null

Uden at have undersøgt det nærmere gætter jeg på, det har noget at gøre med, at Ooklas HTTP-server ikke understøtter HTTP range requests, da det ikke er en disk-fil, man henter, men en continuous byte stream.

Kan man få aria2 til at hente den samme fil flere gange, i stedet for at hente forskellige segmenter af filen?

  • 2
  • 0
#24 Martin Jensen

Mikrotik har i deres routere direkte indbygget en del testværktøjer, og modsvarende server-komponenter, så man kan teste mod WAN-IF på routeren, fra et centralt punkt. Man kan så scripte at nedlukke/begrænse LAN siden, så det ikke påvirker, og for øvrigt ikke spiller ind med wifi, hubs, power-line extenders oma; resultaterne er fra et kendt fixpunkt.

Måske man skal se hvad Jeres routere kan?

  • 2
  • 0
#26 Yoel Caspersen Blogger

Måske man skal se hvad Jeres routere kan?

Den har vi faktisk også kigget på - og vores Inteno DG200-routere indeholder en hastighedstest. Problemet er bare, at speedtesten ligger i software og ikke i hardware, og i software kan vi kun opnå ca. 30 Mbit/s throughput før CPU'en er maxet ud.

Dertil kommer, at vi også har kunder, som ikke anvender vores egen router.

  • 2
  • 0
#30 Miki Petersen

Ah, der var han jo

Men som sagt, vi har ikke rigtigt oplevet problemer på vores netværk fra de fleste kunders side, når det kommer til speedtest på 200/200

Der kan være nogle problemer med 500/500, men det viser sig altid at være en computer eller router hos kunden der er problemet

  • 3
  • 0
#31 Miki Petersen

Jeg vil lige tilføje, at det kan være utroligt svært at få en helt normal bruger til at forstå hastighedstest, specielt når man kommer over fast ethernet

Det ser dog ud til at der er en anden holdning efter 100/100

Vi havde flere der havde noget at sige omkring en 95/95 test med lovet 100/100 (gamle fastethenet switche) end kunder der kan måle ~150/150 på en 200/200 forbindelse (eller 400/400 på en 500/500)

I det første tilfælde er der en hurtig forklaring. Den ældste del af vores netværk kan ikke sættes til mere end 100/100 og der er noget tab.

Vi sætte alle andre op hastigheder med ~20% for at kundernes oplevelse er bedre når de laver en speedtest.

Men i de fleste tilfælde er kunderne forstående når de kan måle mindre på de højere "hastigheder".

Jeg føler også at der ikke er forståelse for hvad man rent faktisk har brug for, som en helt almindelig familie der bare streamer og har et par enkelte downloads af større filer.

Glæder mig til at vi alle rammer 1 Gbit som standard

  • 2
  • 0
#32 Kristian Klausen

Kan man få aria2 til at hente den samme fil flere gange, i stedet for at hente forskellige segmenter af filen?

Tvivler ud fra manpage. Men kan du ikke bare lave noget simpelt shell scripting, noget a la:

for i in {1..10}; do  
        (curl -sSf -o /dev/null -w "%{speed_download}\n" "http://ookla1.kviknet.dk:8080/download?nocache=x&size=50000000" >> speed) &  
done  
wait  
awk -F , '{i+=$1} END {print i}' speed

speed_download er "speed_download The average download speed that curl measured for the complete download. Bytes per second." per curl manpage.

  • 0
  • 0
#33 Yoel Caspersen Blogger

Tvivler ud fra manpage. Men kan du ikke bare lave noget simpelt shell scripting, noget a la:

Hvis alle instanser starter præcis samtidig og henter med præcis samme hastighed, så vil det virke. Men hvad sker der, hvis de starter forskudt, eller henter med forskellig hastighed, og derved afslutter forskudt? Så bliver resultatet vel misvisende?

Alternativt skulle man måle afviklingstiden for hele løkken og derigennem beregne den samlede båndbredde, da den hentede datamængde er kendt.

  • 0
  • 0
#34 Kristian Klausen

Men hvad sker der, hvis de starter forskudt, eller henter med forskellig hastighed, og derved afslutter forskudt? Så bliver resultatet vel misvisende?

Der må jeg nok give dit ret.

Alternativt skulle man måle afviklingstiden for hele løkken og derigennem beregne den samlede båndbredde, da den hentede datamængde er kendt.

Det burde kunne fungere uden at være misvisende.

Noget a la det her, som giver bytes/s. Bemærk skift fra speed_download til size_download.

START="$(date +%s)"  
for i in {1..10}; do  
        (curl -sSf -o /dev/null -w "%{size_download}\n" "http://ookla1.kviknet.dk:8080/download?nocache=x&size=50000000" >> downloaded) &  
done  
wait  
END="$(date +%s)"  
TOTAL="$(awk -F , '{i+=$1} END {print i}' downloaded)"  
echo "${TOTAL} / ( ${END} - ${START} )" | bc
  • 0
  • 0
#35 Baldur Norddahl

Jeg har lavet et lille speedtest script i Ammonite:

https://pastebin.com/YiLuzvd8

Eksempel:

baldur@jump1:~/scripts$ ./speedtest.sc -- --periods 10  
Downloading from http://ookla1.kviknet.dk:8080/download?nocache=x&size=500000000 using 4 threads.  
Downloaded 1759502977 bytes in 15453 ms = 910 Mbps.  
Period 1 downloaded 156591844 bytes in 1545 ms = 810 Mbps.  
Period 2 downloaded 180636552 bytes in 1545 ms = 935 Mbps.  
Period 3 downloaded 180711848 bytes in 1545 ms = 935 Mbps.  
Period 4 downloaded 181014480 bytes in 1545 ms = 937 Mbps.  
Period 5 downloaded 180591664 bytes in 1545 ms = 935 Mbps.  
Period 6 downloaded 180774112 bytes in 1545 ms = 936 Mbps.  
Period 7 downloaded 180991312 bytes in 1545 ms = 937 Mbps.  
Period 8 downloaded 180748048 bytes in 1545 ms = 935 Mbps.  
Period 9 downloaded 180761080 bytes in 1545 ms = 935 Mbps.  
Period 10 downloaded 156680881 bytes in 1545 ms = 811 Mbps.
  • 1
  • 0
#36 Kristian Klausen

Jeg føler også at der ikke er forståelse for hvad man rent faktisk har brug for, som en helt almindelig familie der bare streamer og har et par enkelte downloads af større filer.

Folk har nok desværre en forkert opfattelse af hvor meget båndbredde streaming egentlig kræver, muligvis kombineret med noget ringe WiFi. Så de ender med en forkert konklusion, at når de streamer så bliver nettet langsom, hvilket må skyldes en langsom forbindelse. Tror nu heller ikke at alle internetudbyderes kundeservice er helt skarpe på det her område, men de har jo også en interesse i at sælge den dyreste forbindelse.

Der er også de gamere der mener at en forbindelse på flere hundrede megabit er nødvendig for en lavere ping-tid. Svare lidt til at mene at man kommer hurtigere frem på en tom 5-sporet motorvej fremfor en tom 2-sporet motorvej.

Har egentlig bare svært ved at se hvad man skal bruge over 100 megabit til, er min opfattelse at det er de færreste familier der regelmæssigt downloader/uploader store filer. I hvert fald regelmæssigt nok til at de ødede udgifter står mål med den sparede tid.

  • 1
  • 0
#37 Jens Jönsson

Har egentlig bare svært ved at se hvad man skal bruge over 100 megabit til, er min opfattelse at det er de færreste familier der regelmæssigt downloader/uploader store filer. I hvert fald regelmæssigt nok til at de ødede udgifter står mål med den sparede tid.

Pas på hvad du siger, der er nogen der mener noget andet. Men jeg giver dig helt ret. Har meget svært ved at se, hvad man skal bruge > 100 Mbit/s til. Dem der vil købe og betale for det, skal dog være velkommen. Jeg skal ikke forhindre dem.... Problematikken er at der ikke findes nogen som helst tjeneste, som har behov for at levere den hastighed til dig over længere tid. Der hvor jeg oplever at man kan få > 100 Mbit/s igennem, er Steam spil, Bittorrent (nogen gange) og store ISO download, f.eks. hos Microsoft. Men igen, skulle man have det kørende konstant, var problemet nok snarere at man ikke har en stor nok harddisk...

På en messe kørte vi 6 x 4K stream fra Netflix på en 100 Mbit/s forbindelse uden problemer. Der blev brugt ca. 70 Mbit/s i peak, men ikke konstant, så selv en stor familie kan sagtens streame løs....

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen