Heel interessant.
Ik ben er inmiddels achter dat ik (gigabit) met 1 connectie tot 200 Mbit/s kom. Zet ik er meer open dan kom ik inderdaad verder. Zelfde verhaal dus.
Het lijkt heel erg bron afhankelijk te zijn, bijv. speedtest van de ene source is sneller (qua download) dan een heel andere.
Als ik download vanaf een server (middels ssh/curl) van server van waar ik werk, download ik met een whopping 2.5mbyte/s (collega die nog op xs4all zit (straat achter mij, en nog even wacht met overstap naar freedom nu wij dit weten) download met 60mbyte/.
Een curl van transip gaat iets sneller ~20-25mbyte/s.
Ik ben erg benieuwd waar wat fout gaatā¦
Zit nu toevallig even op Wi-Fi met een MacBook Pro. Dit is een Wi-Fi 6, 5 GHz UniFi systeem. AP op 1 meter.
Als ik in macOS een download start loopt hij strak rond de 200 Mbit/s.
curl http://speedtest4.tele2.net/50GB.zip -o 50GB.zip
Draai ik dit commando nog een paar keer op hetzelfde moment (met een unieke filename voor de output), dan ga ik richting 400+ Mbit/s. Trek Wi-Fi vol.
Ja, als je gigabit afneemt is het wel een dingetje.
Bij Xs4all nam je een 500Mbit en kreeg je 524Mbit. Bij de laatste verbeterslag van de KPN ging dat naar 500 minus de overheadā¦die bewuste 5% zal ik maar schrijven.
De KPN doet op het WBA, het afknijpen van de upload en Freedom knijpt de download.
Cambrium connectie:
# 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.
Met disk speed zit het wel goed 
ā ~ 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).
~ # 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, 0.556951 s, 301 MB/s
1 like
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.
En als je op ethernet zit, hardwired dus?
Misschien moet dit topic maar worden samengevoegd met:
Het lijkt bij mij ook echt alleen op de downstreams fout te gaan. Zoals ik in het andere topic ook zeg, iets met QoS ofzo?
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
SCP:
1gb.bin 59% 607MB 46.2MB/s 00:09 ETA
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.
De speedtestserver zijn te vinden via: https://speedtest.freedom.nl
Packet traces kun je eventueel uploaden via:
6 likes
Jullie hebben mij ook benaderd om te assisteren met tests (gigabit, KPN) en dat is echt top.
Ik ga vanavond voor jullie aan de slag.
Hoewel momenteel alles eigenlijk goed lijkt te werken heb ik toch een baseline test gedaan:
- Server 1: https://speedtest.freedom.nl/results/?id=01FVETR043NZMSPYMYDNT528Q6
- Server 2: https://speedtest.freedom.nl/results/?id=01FVETVP2WD2AC1W0ZSD2PA5WV
Van allebei heb ik ook ongefilterde .pcapās geupload. Als ik weer een keer problemen heb zal ik hetzelfde doen!
server1 https://speedtest.freedom.nl/results/?id=01FVEXZFZD76PZMS2EE1QV5T92
server2 https://speedtest.freedom.nl/results/?id=01FVEY12FF6K60QJNFHXMYHQZ8
āalle filesā heb ik uploaded naar Nextcloud (is een andere url die ik al had gekregen van freedom helpdesk)
Hoe werkt die cap eigenlijk? Ik heb een 200/200 abo, maar zie ook grote verschillen in up- en download:
Ik krijg heel vreemde cijfers die niet stroken met wat ik elders kan wegtrekken.
Voorbeeld: https://speedtest.freedom.nl/results/?id=01FVF6X1M43WMKJTZXC8VHV9BK
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.).
$ wget -O /dev/null http://speedtest.tele2.net/1GB.zip
--2022-02-09 13:22:30-- 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 111MB/s in 9,9s
2022-02-09 13:22:40 (104 MB/s) - ā/dev/nullā saved [1073741824/1073741824]
Het lijkt mij sws handiger om bij speedtest, de overhead t.a.v. protocollen sws buiten het (af)schot te laten.
Zulke sparse file downloads komen er ook op.
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
$ wget -O /dev/null http://speedtest.tele2.net/1GB.zip
...
/dev/null 100%[===================>] 1,00G 94,0MB/s in 10s