Legg inn din hastighet og buffer test her

[eriktar76]

Er litt nysgjerrig på hvordan det står til med hasighet og bufferbloat der ute.  Tror ofte det er latency/buffer problemer heller enn hastighetsproblemer folk opplever når de klager på "tregt internet". Kunne folk gjort en test hjemme hos seg selv og postet resultatet her sammen med kort beskrivelse av setup?

 

Testsiden:

http://www.dslreports.com/speedtest

 

Mitt resultat:

http://www.dslreports.com/speedtest/7755199

Telenor 4G, Dlink 966, iMac, trådløst til router

 

Kollega:

http://www.dslreports.com/speedtest/7755359

Telenor VDSL, Zyxel 8702, Macbook Air, Trådløst til router

 

[hberg1]

nå glemte jeg å slå internet security og en del extensjons som ligger og kjører, men her er min test
http://www.dslreports.com/speedtest/7761828

 

trådløst til router

Endret 23. desember 2016 av hberg1

[tingo]

Get via kabel(-TV), Bredbånd M (75 / 15), kablet til firewall (FreeBSD + ipfw) som er koblet til Get-modemet.

Resultat : http://www.dslreports.com/speedtest/7763825

[fomlepung]

Har 60/20 VDSL fra NGT men bruker mitt egen routermodem (Asus DSL-AC68U) siden routerne som NGT sender ut er noe skikkelig søppel.

Tilkoblet via kabel til router.

Her er mitt resultat:http://www.dslreports.com/speedtest/7764693

Endret 23. desember 2016 av fomlepung

[ChrisCo]

Vikenfiber (Altibox) 300/300Mbps, WiFi mot Ubiquiti AC PRO koblet til Cisco 4948 L3 switch, koblet til Cisco 3845 router.

 

Resultat: http://www.dslreports.com/speedtest/7764891

[Leo_]

60/60 fiber fra Canal Digital.

Modem - CD sin Zyxel P8702N - Asus RT-N12D1 - Stasjonærmaskin

[Rim]

CD 60/60. Trådløst til kablet AirTies, Asus RT-AC66U med Merlin-build. http://www.dslreports.com/speedtest/8036871

[eriktar76]

ChrisCo, Litt overrasket over latency du fikk der 140ms når linja er fyllt opp.  Sammenlign det med Rim sin latency som holder seg på 20-30ms ved makset ut linje.  Klart, dette inntreffer kun når linja er fyllt opp, hvilket sikkert skjer skjelden når man har 250Mbit å ta av.  Men det betyr at det sitter et par store buffere et sted som sikkert kunne vært trimmet litt for mer optimal ytelse.

 

Klar over det er litt sten i glasshus med mine 900ms latency.

[RRhoads]

Jeg har Eidsiva Fiber, 100/100. Kablet til router, så kablet til Zyxel hussentral.

 

Jeg var egentlig fornøyd, men etter å ha sett dette, er jeg ikke så sikker. hehe

 

 

 

Edit: Testet flere ganger, og da gikk det bedre.

Endret 2. januar 2017 av RRhoads

[ChrisCo]

Kan nok hende det er routeren min som ikke klarer helt å skyfle unna alt. Ser på counteren på interfacet mitt ved speedtester, at jeg får input error's og overrun's. Dette skyldes vanligvis at bufferen i routeren, som er makset(!), ikke klarer å dytte all trafikk fort nok videre.

 

Er dog ikke merkbart annet enn på statestikk.

[eriktar76]

RRhoads, ikke så galt det der.  Litt buffring, men neppe noe som oppleves som plagsomt.

[handprint]

[Dr Norwege]

Super VDSL fra Ngt http://www.dslreports.com/speedtest/9424755 kablet rett i ruter

[Slitenkæll]

[LMH1]

 

 

Asus RT-AC88U VPN server.

Det er nok routeren som begrenset hastigheten her på grunn av cpu hastighet.

Har kabel\fiber hele veien.

Endret 1. februar 2017 av LMH1

[Big_JT]

[Chris93]

[Mr D]

[K-van]

[marsboer]

Selv lynraske fiberlinjer trenger litt moderne traffic shaping for å yte på sitt beste. Her er resultatet på min 500/500 Canal Digital fiberlinje uten noen form for traffic shaping i min Debian Linux firewall:

 

http://www.dslreports.com/speedtest/10872436

 

Det ser jo helt greit ut dette, bortsett fra at jeg ikke klarer å fylle pipen skikkelig på upload-siden.

 

Hva med å aktivere fq_codel + HTB på upload:

http://www.dslreports.com/speedtest/10872253

 

Da fylles pipen veldig bra opp på upload-siden men download ser fremdeles litt rufsete ut.

 

Hva om jeg i tillegg aktiverer fq_codel + HTB på upload på interfacet mot kjerneswitch, som da blir downstream for internettrafikken:

http://www.dslreports.com/speedtest/10874658

 

Episk! Full fairness, full throughput og så godt som null latencyvariasjon i begge retninger, nær sagt uansett påtrykk (utover DDoS som man selvsagt ikke kan gjøre noe med)

 

Jeg kjørte den ideelle løsningen med shaping på upload på henholdsvis LAN og WAN i en dedikert WAN-gateway, men man kan alternativt gå for reserveløsningen som er shaping på upload på WAN, og shaping på upload på et IFB-interface som får trafikken fra WAN-interfacet, men da må man ta høyde for dobbeltelling av IPSec-trafikk osv så det er bare en nødløsning. Den siste muligheten, som også er den tradisjonelle, er shaping på upload og ren ingress policing på downstream, dvs ren rate limiting uten noen avansert køhåndtering og fairness. 

 

Merk at vanlige embedded enheter ikke klarer å kjøre shaping effektivt i flere hundre mbit/s, mens det er null problem for selv en svak PC.

 

Det er mye å sette seg inn i når det kommer til traffic shaping og policing, så jeg har laget et script som jeg benytter som tar seg av det meste for den som skulle være interessert: https://github.com/hkbakke/tc-gen

 

Jeg kjørte kun

tc-gen.sh -i <WAN_IF> -u 520M
tc-gen.sh -i <CORE_IF> -u 520M

som post-up for det enkelte interface i interfaces-fila og scriptet tar seg av alt det vanskelige.

 

Endret 22. februar 2017 av marsboer