# curl http://speedtest.tele2.net/1GB.zip -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1024M 100 1024M 0 0 100M 0 0:00:10 0:00:10 --:--:-- 99.0M
Dan ander testje op dezelfde hardware:
# curl http://speedtest.tele2.net/1GB.zip -o 1GB.zip
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1024M 100 1024M 0 0 89.6M 0 0:00:11 0:00:11 --:--:-- 65.8M
Zelfde systeem (wired verbinding, geen wifi), … in het eerste geval meet je de NETWERK snelheid,
in het Tweede geval meet je de snelheid van NETWERK + DISK … . (in mijn geval een 6gbps Sata, met ruim vrije diskruimte)…
Dus test svp ZONDER naar een schijf te schrijven (ten minste als je netwerk snelheden wil meten: -o /dev/null ).
Als je meerder streams parallel wil testen kun je ze allemaal naar /dev/null laten schrijven.
Schijf bandbreedte is niet alleen afhankelijk van de schijf snelheid, maar ook van Filesystem performance, buffering in het File IO systeem, en hoe vol (en ook gefragmenteerd) een filesystem is.
Overigens is testen met iperf3 of netio vele malen beter. Daar is aan beide zijden GEEN filesystem bij betrokken.
curl … -o /dev/null gaat nog wel door de IOhandler van Linux/Unix/… whatever heen.
➜ ~ dd if=/dev/urandom of=test.bin bs=16m count=128
128+0 records in
128+0 records out
2147483648 bytes transferred in 6.442395 secs (333336229 bytes/sec)
Ook al zit het met de disk speed wel goed copy commando’s werken strict.
read from source, write to dest, read from sour, write to dest… until end of source.
En er is geen overlap op programma niveau, mogelijk een beetje op disk cache, maar die ook maar een paar MB.
Dat is ALTIJD slechter dan: read from source, read fro source, read from source… hoe snel je schijf ook is.
In schijf snelheid zit niet alleen ruwe disk speed, maar ook zoeken in de lijst naar vrije blokken (meest al find first) , veel al zoeken in bitmaps. Administratie bijwerken (sycnhroon) wachten to de File bitmap bij gewerkt is op schijf en dan pas data op gaan slaan…
Be denk dat voor elk blok van ~ 4K naar schijf schrijven je mogelijk wel 2-10 maal een IO moet doen. Zelfs SSD vertraagd.
Dus OF= null device = geen allocatie , maar nog wel dummy write() naar het OS met de vele context switches.
Dus (nogmaals) geen write is best… ==> netio of iperf3.
/dev/urandom is nog relatief traag, en beperkt, die geeft na 32 MiB op, gebruik liever /dev/zero als bron van data.
En als je over de buffer size heen gaat (160MiB block) wordt het gelijk trager.
xx ~ # dd if=/dev/urandom of=16m.bin bs=16M count=1
1+0 records gelezen
1+0 records geschreven
16777216 bytes (17 MB, 16 MiB) gekopieerd, 0.0940867 s, 178 MB/s
xx ~ # dd if=/dev/zero of=16m.bin bs=16M count=1
1+0 records gelezen
1+0 records geschreven
16777216 bytes (17 MB, 16 MiB) gekopieerd, 0.0484626 s, 346 MB/s
xx ~ # dd if=/dev/zero of=16m.bin bs=160M count=1
1+0 records gelezen
1+0 records geschreven
167772160 bytes (168 MB, 160 MiB) gekopieerd, 1.91121 s, 87.8 MB/s
xx ~ # dd if=/dev/urandom of=16m.bin bs=160M count=1
0+1 records gelezen
0+1 records geschreven
33554431 bytes (34 MB, 32 MiB) gekopieerd, 0.222726 s, 151 MB/s
Invloed van disk allocatie: (overschrijven van bestaand bestand is sneller dan van een nieuw bestand).
Oke, goed verhaal, maar zoals je in mijn eerdere posts kan zien heb ik OOK iPerf gebruikt, en schrijf ik data direct weg naar /dev/null. Dit is overduidelijk geen probleem met disks.
Het lijkt wel iets beter de afgelopen dagen. Dit is een speedtest met een enkele connectie:
curl:
➜ ~ curl http://speedtest.tele2.net/1GB.zip -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
32 1024M 32 329M 0 0 80.8M 0 0:00:12 0:00:04 0:00:08 80.8M
De rare verschillen tussen download- en upload snelheden hebben onze volle aandacht. Het is een heel lastig probleem omdat we niet zelf de problemen kunnen reproduceren. Maar dat er problemen reëel zijn is ons meer dan duidelijk.
Na inventariseren van de klachten lijken deze zich te beperken tot gigabit aansluitingen op het KPN access-netwerk. We hebben een aantal kandidaat-oorzaken bedacht en zijn die voor zover als we kunnen aan het uitsluiten. Het onderhoud van vannacht is een netwerk-element uitgesloten en we gaan kijken of dit effect heeft. Zo niet dan gaan we verder met het verprutsen van onze nachtrust.
Ook hebben we inmiddels zelf twee privacy-vriendelijke speedtestservers. Door te testen met deze servers kunnen we upstream en peering buiten beschouwing laten. We hebben de servers inmiddels op twee verschillende plekken in het netwerk zitten waardoor we ook weer een aantal elementen kunnen uitsluiten mochten er duidelijke verschillen te zien zijn in resultaten tussen de twee servers.
Die speedtestservers behoeven nog meer werk. Zo hoop ik dat we in de loop van de dag ook HTTP (naast HTTPS) kunnen doen om TLS-overhead weg te werken. Ook zullen we op servers sparse files ter download met curl of wget gaan aanbieden. Ook moeten de servers nog verschillende hostnames voor IPv4, en IPv6 in DNS te krijgen.
Desalniettemin is het al nuttig om speedtests te doen met onze servers. Daarbij zou een packet-trace (packet capture) helemaal handig zijn. We maken deze ook op de speedtest servers van het http(s) verkeer. Mogelijk leveren vergelijkingen tussen de twee kanten van de verbindingen inzage in eventuele oorzaken in de access-netwerken die niet onder ons beheer zijn.
terwijl ik een platte download elders vrolijk doe op ruim 100MByte/sec op m’n 1Gbit Glasvezel.
(nu kan dat natuurlijk wat zeggen over mijn tussenliggende infra die https zou afknijpen etc.etc.).
Maar juist packet captures van de speedtests met rare uitkomsten zijn super interessant. Jitter van 368ms zegt mogelijk iets over buffer-problemen of extreme shaping. Helemaal omdat je ze niet hebt met in dit geval Tele2.
Hier in Hoofddorp ziet het er prima uit, alhoewel de getallen vlak na overstap van xs4all naar freedom beter waren. Resultaten fluctueren met +/- 30 Mbit/s.
Ping / jitter: 5 / 33.38 ms
Down / Up: 928 / 909 Mbit/s
OK, nieuwe test gedaan… (file:pcaptest-09feb22-16u57.speedtest.server2.freedom.nl.pcapng uploaded to cloud ) en de jitter is iig minder.
Lijkt op en in lijn met andere soortgelijke speedtests… Download 118.74 , Upload 206.17
Doorvoer lijkt substantieel minder dan ik plat elders (be)haal. ter verificatie ook maar eentje van xs4all gedaan.
$ wget -O /dev/null http://speedtest.tele2.net/1GB.zip
--2022-02-09 17:14:21-- http://speedtest.tele2.net/1GB.zip
Resolving speedtest.tele2.net (speedtest.tele2.net)... 90.130.70.73, 2a00:800:1010::1
Connecting to speedtest.tele2.net (speedtest.tele2.net)|90.130.70.73|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1,0G) [application/zip]
Saving to: ‘/dev/null’
/dev/null 100%[=====================================================================================================>] 1,00G 96,9MB/s in 10s
2022-02-09 17:14:31 (103 MB/s) - ‘/dev/null’ saved [1073741824/1073741824]
$ curl -o /dev/null http://download.xs4all.nl/test/2gb.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1907M 100 1907M 0 0 107M 0 0:00:17 0:00:17 --:--:-- 106M
Beide speren plat op > 100MByte/sec, daarentegen gaan de speedtests hopeloos slechter op nog geen 15-20% van de platte waarde. Ergens gaat er wmb dus (flink) wat mis ???
Terzijde, hoor je mij vooralsnog niet klagen omdat ik kom van destijds een 50mbit@xs4al en toe letterlijk niet verder kwam (oop op speedtest) dan 4-5MByte/sec.
Nope, alles hier per kabel, zitten wel een paar switches tussen. Het enige dat ik mij, als het al aan mijn spullen ligt, dat dan de “s” in “https” de boosdoener is. Hoewel ik mij dat moeilijk kan voorstellen dat sec TLS (daarvan) de oorzaak is.
In het verleden ook al 's geprobeerd met een rechstreekse PPPoE vanuit een i7/32GB Ubuntu met dezelfde speedtest resultaten. Indertijd dat ik (ooit) nog 500Mbit had van xs4all, had ik trouwens nooit issues. Later heb ik die verbinding kostentechnisch teruggebracht naar 50Mbit, wat sinds Freedom dus weer 1Gbit is.
Zelf heb ik de meeste fiducie in plat - zonder liflaf of protocol - downloaden van een binair bestand.
Het intrigeert wel.
Terzijde, heb ik het niet zo op de of Java/html/browser gecontroleerde testen. Meermalen meegemaakt dat de tussenligende software dan een (te grote) rol gaat spelen. Met Chrome krijg ik dan bv dan het dubbele van de (sws) beroerde snelheid via FireFix.
Dat ziet er al aardig uit op een uitzondering na. Ik heb het idee dat er verbetering zichtbaar is. De iPerf3 met Serverius voer ik vaker uit en is normaal gesproken stabieler en beter.
Vanmiddag had ik een laptop rechtstreeks aan deze pfSense router gekoppeld en heb wat tests gedraaid op de twee speedtest servers van Freedom. Daar bleef upload achter echter kan dat zomaar een andere reden hebben.
Ik moet nog wat meer gerichte tests doen. Heb af en toe nog het idee dat vooral downloads via HTTP of HTTPS traag zijn.
Complexe materie om te troubleshooten, zeker voor Freedom. Zo ontzettend veel factoren in het spel.
Yep, wat zou helpen is om een baseline te hebben of te (ver)krijgen. Wat ik bij jou dan weer niet snap, is jouw trage upload, die bij mij viua die tooling juist weer beter is dan de brakke download.
Met respect voor al die kèkke webtools en deels ook iPerf, lijkt het mij verwarrend om uit te gaan van tools die data verwerken en/of rapporteren. Bij een bedrijf waar ik (ooit) betrokken was, ook al 's meegemaakt dat die (like Dieselgate) de SLA-performance daarop als bewijs ging tunen. Klagende gebruikers werden weggezet als zeurpieten omdat het heilige meettool bewees dat de respons goed was.
Voor mij is het een stuk transparanter om via down/uploads de metingen te doen, zodat er geen (goedbedoelde) shit tussenzit.
