Cloudflare introduceert gedetailleerde speedtest

Cloudflare heeft een uitgebreide speedtest beschikbaar gesteld. Via de site krijgen gebruikers inzicht in de download- en upoadsnelheid, latency en jitter van hun verbinding. Resultaten zijn per onderdeel te bekijken en te exporteren als csv-bestand.

De speedtest van Cloudflare bestaat uit diverse onderdelen en de resultaten zijn afzonderlijk te bekijken. Zo worden er pakketjes van 10kB, 100kB, 1MB, 25MB en 100MB gedownload en in tabellen is zichtbaar hoe snel dat gaat. Volgens Cloudflare zijn de kleine downloads representatief voor bijvoorbeeld het inladen van css-stylesheets en json-blobs. De grotere downloads moeten inzicht geven in de maximale bandbreedte van de verbinding.

Naast latency meet de test ook jitter. Daarmee wordt aangegeven hoe stabiel de latency is. Gebruikers kunnen via de site bij alle resultaten doorklikken om uitgebreide rapportages te zien per onderdeel. Ook is het mogelijk om alle resultaten te exporteren in csv-formaat. De broncode is in te zien op GitHub.

Cloudflare zegt de speedtest online te zetten zodat mensen die nu door de coronacrisis thuiswerken, kunnen kijken hoe hun internetverbinding presteert. Volgens de dienst worden meetgegevens geanonimiseerd verzameld en alleen gebruikt voor het verbeteren van eigen diensten van Cloudflare.

Update: de speedtest geeft momenteel geen resultaten voor de uploadsnelheid. Cloudflare heeft die test tijdelijk uitgeschakeld vanwege onverwachte resultaten.

Reacties (63)

[Rmg]

Jammer dat de test nogal browser afhankelijk is. Ik meet niet de prestaties van mijn internetverbinding maar van mijn browser+hardware+internetverbinding. Dat is ook interessant, maar niet echt duidelijk aangegeven.

[NielsFL]

Wat ook gek is: zonder VPN blijf ik steken op 886Mbps. Met VPN haal ik 927Mbps. Je zou denken dat de overhead en omleiding die het VPN veroorzaakt de boel vertragen. Maar kennelijk is de interconnectie tussen T-Mobile en Cloudflare zodanig slecht dat VPN tot een verbetering leid.

[r0y89]

Routering van T-Mobile (Thuis Glas) is echt bagger. Ik heb vaak last van packetloss richting verschillende partijen. Wanneer ik overschakel naar mijn failover (Ziggo) heb ik helemaal geen packetloss naar dezelfde bestemming.

[Blizz]

Leidde T-Mobile niet stiekem om via Duitsland afgelopen jaar? Zijn ze misschien weer stiekem begonnen?

nieuws: T-Mobile blijft internet via Duitsland routeren, toezichthouder bekij...

[bas1286]

Ook relevant:
nieuws: T-Mobile: terugzetten routering naar AMS-IX gebeurt in komende nachten

[Anoniem: 951889]

Of t-mobile doet stiekem aan traffic shaping...

[Countess]

Goed ingerichte traffic shaping is juist gunstig voor de consument.

Het kan bijvoorbeeld latency gevoelig verkeer voorrang geven zonder dat het effect heeft op de bandbreedte van het bulk verkeer.

[CathodioN]

Dat kan komen door compressie op de VPN verbinding. Er wordt dan CPU kracht gebuikt aan beide zijden om de data te comprimeren waardoor je per tijdseenheid meer data kunt verzenden. De gebruikte CPU cycles worden niet gemeten in de test, dus kan dat de resultaten vertekenen.

[-weenie-]

Ik hoop dat ze incompressable data verzenden. Of dat zou wel moeten.

ps; Hier haal ik zo'n 80-90Mbit minder dan bij speedtest.net

[Reactie gewijzigd door -weenie- op 22 juli 2024 18:14]

[zerotje]

Kun je dat niet gewoon ff testen met een tracert commando in cmd.exe?
Hoeveel en via welke hops beland T-Mobile bij Cloudflare.
Hoeveel en via welke hops beland je VPN bij Cloudflare.
(Niet al je hops zijn pingbaar, je zult ongetwijfeld ******* zien. Maar het einddoel is pingbaar.)

[Reactie gewijzigd door zerotje op 22 juli 2024 18:14]

[lenwar]

Dat kan prima als je VPN ingebouwde compressie heeft naast de encryptie. Het ligt er dan puur aan, wat voor soort data Cloudflare aanbiedt. Als zij bestanden aanbieden met allen nullen als inhoud, dan is dat heel goed te comprimeren, waardoor je dus relatief veel data binnenhaalt. Je ziet hier dus een mooi verschil tussen bandbreedte en snelheid.

[zerotje]

Als je die factoren wilt beperken...
Probeer "IPERF"...
Vergt wel enige ICT kennis.

[Core2016]

Dat valt ook wel mee, Firewall poortje open zetten en run de 'serverkant' met -s en de client met -c ip.o.i.d. Dan heb je al een heel goed beeld.

[lenwar]

Klopt, maar als je je winterverbinding wil meten moet je dat vanaf je modem doen naar het apparaat waar de modem mee praat, en niet van een apparaat in het netwerk. Die waarde is echter weer helemaal niet interessant voor de gebruiker. Voor de gebruiker is wat cloudflare (of één van die anderen) meten interessanter, namelijk een applicatieve meting. (dus met overhead van je browser, gebruikte procollen (ethernet/tcp/http/etc), enz.)

Er wordt ook geen onderscheid gemaakt tussen bandbreedte en snelheid. Die twee hebben uiteraard een sterke correlatie, maar zijn zeker niet hetzelfde. (iets met de semicorrecte analogie met 5 autos met 100km/u rijden op één strook of vijf stroken).

[diondokter]

Het berekend alles op basis van de milliseconden. Niet super precies dus. De 10kB test duurt bij mij 0ms, dus de snelheid is blijkbaar NaN (not a number).
Ook de 100kB switcht tussen 3ms en 4ms, dus nu lijkt het dat mijn snelheid met bijna 70Mbit schommelt.

Gedetailleerd? Sure. Erg precies? Niet echt.

[Cergorach]

Dat niet alleen, maar het geeft ook een niet realistisch beeld. Ik zie bv. doodleuk 732Mbps op de pagina staan op een 500/500 connectie, ik weet uit ervaring dat dit niet een correct beeld is van de downloadsnelheid. Het 100MB bestandje geeft een beter beeld van ~541Mbps als max downloadsnelheid.

Wat ik me afvraag is wat het nut is van deze pagina indeling en de kleinere packages?

[Louw Post]

De 100MB test is bij mij ook niet echt accuraat. Deze geeft nu mooi 657Mbit aan, op een 1Gbit verbinding. Dan is de test van speedtest.net toch wel wat beter.

[xFeverr]

Ach... ik heb volgens de tool 2.59Gbps. Als dat echt zo is dan is Ziggo plots wel heel snel geworden

Voor de duidelijkheid, ik heb 250/25.

[webster]

Hier ook: 1.99Gbps volgens Cloudflare terwijl ik 250Mbps heb.

[Themperror]

omgekeerd hier, 140Mb/s terwijl ik 500 heb, (op telefoon haal ik 350..), https://fast.com/ geeft wel men goede snelheid aan (~530/~540)

[Core2016]

En dat vind ik nu heel erg raar. Moet er eens een screenshot van maken. Maar als ik van mijn oma's (50/50) glas abbo "telfort/kpn nu?" een vpn naar mijn Tmobile connectie opzet, meld speedtest.net op haar verbinding 50/400 ofzo. En dat doet het. Want een vm terug halen gaat erg rap. Er is dus meer aan de hand. Het lijkt haast alsof het in de wijk kast meteen naar haar gaat zonder cap. Wat nog meer raar is, het betreft de upload alleen. En alleen als ze op de vpn naar mij zit. Ik kan het ook niet anders testen dus? iemand die dat wel weet? Mijn cap is 750/750. Waar komt die 400 dan vandaan?

[Reactie gewijzigd door Core2016 op 22 juli 2024 18:14]

[lenwar]

Hoe weet je dat? Omdat het resultaat is wat jij verwacht/wilt dat het is? We hebben bij zowel Cloudflare als speedtest.net geen inzicht hoe er daadwerkelijk getest wordt. Is het een platte datastroom in udp/tcp? is het http/https/nntp/whatever?

Onder aan de streep is het enige dat van belang is toch je daadwerkelijke snelheid die je haalt met surfen/downloaden?

[diondokter]

De kleinere packages zouden denk ik een beter beeld moeten geven van het downloaden van webpagina's enzo. Wel een beetje raar omdat latency daar een veel grotere rol speelt. Bijna al het andere verkeer zijn vaak grotere bestanden of streams.

[zerotje]

Je mag ook lekker over je 500/500 heen knallen hoor, ze stellen een burst value in per lijn.
Je word daarna "teruggestuurd" naar je abonnementswaarde.

Dat zie je ook wel bij speedtest.net, helemaal aan het begin van je test.
Ervan uitgaand dat je niet bij een rukserver test, waar er genoeg van zijn bij speedtest.net

[klepje]

De product manager van Cloudflare heeft aangegeven dat ze wat issues hebben gezien sinds de release van de tool. Mede daardoor hebben ze het meten van de upload snelheid ook tijdelijk uitgezet:

https://news.ycombinator.com/item?id=23315860

[Henk Poley]

Hah, cool. Deze speedtest merkt dat 1MB bestanden onder de limiet zitten waarop XS4ALL's traffic shaping inschakelt. Die komen met max. snelheid van m'n VDSL2 lijn binnen. Over de lange duur heen wordt die dan weer naar beneden gedrukt. Ik gok dat ze PIE op 100ms hebben staan, want daar blijft 1MB net onder.

Vanwege PIE geeft DSLReports ook zo'n belabberde bufferbloat aan, pieken van 250-500ms . Lekker fijn video bellen tijdend een up-/download . Zoveel jaren na fq_codel (2012) en CAKE (2018) zou je toch verwachten dat de grote jongens (Cisco, Juniper, F5, etc.) zoiets in hardware switches en routers hebben zitten?

Dat gelijktijdig testen van latency tijdens up-/downloads, dat doet deze Cloudflare test helaas niet.

Wel curieus dat de 10KB en 100KB test niet zo snel gaan. Misschien hebben ze een dealtje met XS4ALL dat ze voorkeur krijgen op de max. snelheid? Wat overigens niet mag volgens netwerk neutraliteit (tenzij iedereen het voordeel krijgt).

[Reactie gewijzigd door Henk Poley op 22 juli 2024 18:14]

[Tweakod3x]

Beetje rare test. De resultaten van mijn download-test zijn 5 keer zo hoog als mijn werkelijke verbinding. Dat komt vooral omdat de 1MB check uitkomt op 500 Mbps, terwijl ik een 100/100 verbinding heb....

[Henk Poley]

Waarschijnlijk kan je lijn fysiek 500mbit/s. En wordt bij je provider een beetje in de gaten gehouden of je binnen de 100mbit blijft. Bij legacy methoden zoals PIE, wat ingebakken zit de meeste grote routers en switches gaat dat per 100ms. Blijf je daar binnen dan kan je tot de maximale snelheid van je lijn.

Zie ook mijn andere commentaar hier.

[Martinspire]

Dat moet alleen. De mbit/s geeft al aan dat het per seconde is. Als een pakketje 0,005 seconde nodig heeft, dan is de overige 0,995 seconde toch maar een inschatting.

[Tha Render_2]

"gedetailleerde speedtest" maar hij meet niet de upload snelheid? Terwijl upload net belangrijker wordt, webcam streamen tijdens video calls bijvoorbeeld, bestanden sharen die je lokaal bewerkt hebt, etc...

[klepje]

Ze hebben het tijdelijk uit gezet omdat ze wat issues zagen met de upload snelheden die eruit voort kwamen, zie hier de reactie van de product manager van Cloudflare: https://news.ycombinator.com/item?id=23315860

[Tenebris]

Toen ik het gisteravond probeerde kreeg ik wel upload te zien, nu niet meer

[Hans C]

In de toelichting op de site staat wel een heel verhaal over de upload.

[XiniX88]

Sorry, maar waar zie je dit staan. Op de blog gekeken en daar zie ik niets over uitschakelen upload alsmede in de About pagina van de website van de speedtest.

[tostyijzer]

Heeft dit niet nagenoeg dezelfde functie als https://sourceforge.net/speedtest/ ?
Ik ben blij dat bedrijven hun speedtest uitbreiden naar een analysetool. Voorheen kon je heel hoog scoren op een speedtest maar was de verbinding in praktijk niet zo goed als de test deed vermoeden. Pagina's reageerde langzaam of foutmeldingen bij het videobellen. Dit geeft je als helpdeksmedewerker iets meer zekerheid bij het testen van de verbinding van een collega.

[MN-Power]

Ja, alleen komt mijn snelheid bij Speedtest bijna altijd te laag uit de bus. Al jaren(tientallen). In de tijd dat ik nog 250Mbit had zat hij er al onder terwijl downloaden(bijvoorbeeld Steam) voor of na dat moment gewoon met 33MB/s ging. Nu met 500Mbit hetzelfde:

Net weer even getest. Cloudflare zegt 489Mbit(komt goed overeen met mijn ervaringen), Speedtest 328Mbit. Veel en veel te laag.Upload zegt overigens 39.44, dus dat klopt wél aardig bij Speedtest.

EDIT: Ik bedoelde Speedtest.net(te snel gelezen) Die jij noemt begint net iets onder de 500 en komt aan het eind met 748, dat is weer (veel) teveel van het goede ook is de latency veel hoger dan de 2 anderen. Al met al lijkt die van Couldflare het beste overeen te komen met mijn daadwerkelijke ervaringen.

[Reactie gewijzigd door MN-Power op 22 juli 2024 18:14]

[tostyijzer]

Ik heb bij sourceforge idd ook een hogere latency. Ik ging er vanuit dat dit kwam omdat ze een beter palet aan scenario's (of servers op verschillende plekken) testen. Cloudflare zit spreekwoordelijk om de hoek en geeft misschien daardoor wel betere resultaten.

[MN-Power]

Speedtest.net(die andere dus) zit dichterbij dan Cloudflare(Groningen vs Amsterdam) en daar is al duidelijk verschil qua latency
(latency, download, upload)
Speedtest.net(Groningen): 13ms 328Mbps 39Mbps
Cloudflare: 18ms 489Mbps nvt

SourceFourge Speedtest(Locatie onbekend): 26ms 748Mbps(!!!) 48Mbps

Ik heb even van server geswapped bij Speedtest.net. Zwolle doet 507Mbps bij 17ms latency. Die server in Groningen kan het dus niet aan

[Reactie gewijzigd door MN-Power op 22 juli 2024 18:14]

[Core2016]

Serverius test ik ook wel eens. Die is ook wel redelijk oprecht goed accuraat.

[AnguishedOne]

net even naar gekeken, resultaten lijken op wat ik zou verwachten als je met iets als ookla test alleen is de latency nogal aan de hoge kant gemiddeld 3 tot 4x meer dan Ookla
weet niet of daar een verklaring voor is maar ziet er verder prima uit.

[Hans C]

Bij mij gaat hij standaard naar Engeland?

[pietje63]

Zit je wellicht op VPN van je werk?

[NielsFL]

Niet per se. Ik zie het hier ook: hij ziet dat ik in Amsterdam zit maar kiest toch voor een speedtest server in Engeland. Zet ik IPv6 aan, dan kiest hij wel Amsterdam.

Kennelijk is de server selectie niet afhankelijk van je daadwerkelijke lokatie. Ook voeren ze geen pings uit naar diverse servers zoals sommige andere speedtests dat doen.

Ik vermoed dat Cloudflare informatie uit hun CDN gebruikt om een server te selecteren die bewezen snel is voor jouw IP range of ASN.

[Hans C]

Ik heb inderdaad geen VPN aanstaan, zoals NielsFL ook aangeeft. Mijn lijn gaat van Landhorst (NL) naar Londen.

[Reactie gewijzigd door Hans C op 22 juli 2024 18:14]

[GertMenkel]

De statistische gegevens van de speedtest zijn interessant en geven een goede indicatie van hoe betrouwbaar de test is, maar ik meer op de test van Cloudflare toch meer dan 10% minder dan die van Netflix (fast.com).

De test geeft een nuttige indicatie van je internetsnelheid als het neerkomt op browsen (afbeeldingen downloaden van een paar hosts en een paar MB aan css en javascript hooguit zorgen er in combinatie met de TCP slow start voor dat je niet je volledige lijnsnelheid haalt bij het bezoeken van sites) maar het zegt niet veel over de internetprestaties als het neerkomt op video's, streams en grote bestanden.

Zoals altijd moet je zulke tests in context zien maar ik vind deze wat verwarrend met de manier waarop ze zichzelf presenteren.