Beantwoord

Download snelheid single stream heel traag.

3 maanden geleden
June 23, 2026
15 reacties
110 Bekeken

HAPV2
is een Master Poster

Single-stream download structureel traag op 100/100 glasvezel — multi-stream wél vol

Ik loop tegen een hardnekkig probleem aan en heb het inmiddels behoorlijk dichtgetimmerd, maar kom er met de provider nog niet helemaal uit. Misschien herkent iemand dit of kan een moderator meekijken.

Kort samengevat

Single-stream download (gewone bestandsdownload, file-copy, VPN, RDP) haalt maar ~2 tot 18 Mbps met honderden TCP-retransmissies.
Single-stream upload haalt smetteloos ~105 Mbps (0 retransmissies).
Multi-stream download (Ookla-speedtest, browser met meerdere verbindingen) haalt wél gewoon ~99 Mbps en verbergt het probleem.
Gemeten 17% packet loss in de download-richting via een UDP-test.

Kortom: alles wat één TCP-verbinding gebruikt is onbruikbaar traag, terwijl een speedtest "groen" is.

Setup

Glasvezel 100/100 Mbit
Modem/gateway: Zyxel EX5601-T1 (firmware V5.70(ACEA.0)T56C_b29)
Glasvezel komt binnen op een los ONT/media-kastje, dat via ethernet naar de WAN-poort van de Zyxel gaat
Getest bekabeld, wifi uitgeschakeld

Wat ik al heb uitgesloten (eigen kant)

Zyxel WAN-poort: 1000 Mbps / Full Duplex (correct)
Zyxel WAN-statistieken: 0 verzend-/ontvangst-errors, 0 drops
Bekabelde LAN-poorten: 0 errors
Identiek beeld op kabel én wifi
Identiek met provider-DNS én publieke DNS (8.8.8.8)
Modem CPU/geheugen rustig (2% / 24%)

Metingen

HTTP single-stream (curl, Tele2 1GB testfile)

Average Dload 255–550 KB/s  (~2–4,4 Mbps)

iperf3 single-stream download (reverse), publieke servers in Amsterdam

Clouvider:  18,1 Mbps, 395 retransmissies / 15 sec
NovoServe:  11,2 Mbps, 314 retransmissies / 15 sec

iperf3 single-stream UPLOAD (zelfde server, ter vergelijking)

105 Mbps, 0 retransmissies  ← smetteloos

iperf3 UDP download (20 Mbps aangeboden, reverse) — expliciete loss

20.0 Mbits/sec   jitter 4,66 ms   1032/6111 verloren = 17% packet loss

Jitter laag, maar harde packet drops → geen bufferbloat, wel verlies.

Ookla speedtest (multi-stream, referentie)

Download 99 Mbps   Upload 103 Mbps
Ping idle 5 ms / onder download-load 38 ms

Ping 8.8.8.8 (60 pakketten, tijdens download)

Latency stabiel 4–6 ms (geen oplopende latency = geen bufferbloat)
Packet loss 1/60 = 1%

Single- vs multi-stream naast elkaar

Test	Methode	Streams	Download
Tele2	HTTP	1	~2–4,4 Mbps
NovoServe	iperf3	1	11,2 Mbps
Clouvider	iperf3	1	18,1 Mbps
Ookla	multi	meerdere	99 Mbps
Upload	iperf3	1	105 Mbps, 0 retr

Mijn vermoeden

Richtingsgebonden packet loss in de download-richting, buiten mijn eigen apparatuur. Upload is perfect, download verliest pakketten — over meerdere onafhankelijke servers en zowel via HTTP als iperf3. Multi-stream verbergt het omdat parallelle verbindingen het verlies uitsmeren.

Lijkt me iets in het toegangsnetwerk: congestie op het segment, een download-rate-policy, of iets op de glasvezelaansluiting/OLT-poort.

Vragen

Heeft iemand dit eerder gezien (single-stream download stuk, multi-stream + upload prima)?
Is dit een bekend patroon bij congestie op een gedeeld segment, of eerder een OLT-/aansluitprobleem?
Welke gegevens kan ik nog aanleveren om het sneller op te laten lossen?

Alle ruwe output heb ik bewaard en kan ik delen. Alvast bedankt voor het meedenken.

Beste antwoord door HAPV2

Update: het is opgelost! 🎉

Single-stream download loopt weer helemaal vol. De metingen ter bevestiging (Linux-host, bekabeld):

Single-stream download (TCP, reverse):

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -t 15
[  5]   0.00-15.00  sec   188 MBytes   105 Mbits/sec   receiver   (53 retr)

UDP download, -b 90M (was eerder 17% loss):

iperf3 -c ams.speedtest.clouvider.net -p 5202 -R -b 90M -u -t 15
[  5]   0.00-15.00  sec   161 MBytes  90.1 Mbits/sec  0.014 ms  215/116852 (0.18%)  receiver

Van die 215 verloren datagrams zaten er 215 in de eerste seconde (connectie-opbouw) — daarna 0% loss, elke seconde. Waar het eerder 16 Mbps single-stream met ~415 retransmissies en 17% UDP-loss was, is het nu 105 Mbps met minimale loss. Precies zoals een gezonde 100/100 lijn hoort te presteren.

Gezien het tijdsbeeld (probleem begon 2-4 weken geleden, nu opeens weg) vermoed ik dat er iets aan de aansluiting of op het segment is rechtgezet.

@rvk01 heel erg bedankt voor het grondige meedenken en de goede testsuggesties, dat heeft enorm geholpen om alles systematisch af te pellen. Toppie!

Bekijk origineel

Cheyenne van Odido
Moderator | Internet + TV
3 maanden geleden
June 25, 2026

Hi @HAPV2, dank voor deze duidelijke uitleg! Super dat je dit allemaal in een topic hebt gestort. @rvk01 en @Waqqas, kunnen jullie toevallig eens meedenken? Heel erg bedankt!

Neem alvast een kijkje in onze Wiki: https://community.odido.nl/knowledge-base

rvk01
3 maanden geleden
June 25, 2026

@HAPV2 Kun je eens doorgeven naar welke server je precies getest hebt met iperf3 en wat de totale output is. Volgens mij zijn de retries daarbij n.l. redelijk normaal (zeker in upload mode). iperf3 begint n.l. heel erg hoog en komt dan de beperking van de internetlijn tegen. Daarna worden de packetjes kleiner en zou de snelheid moeten stabiliseren. Daarom vindt ik het raar dat jij geen retries hebt zonder de -R (dus in upload) mode.

$ iperf3 -c ams.speedtest.clouvider.net
Connecting to host ams.speedtest.clouvider.net, port 5201
[  5] local 192.168.2.21 port 50620 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  96.9 MBytes   812 Mbits/sec    3    608 KBytes
[  5]   1.00-2.00   sec   111 MBytes   931 Mbits/sec    0    734 KBytes
[  5]   2.00-3.00   sec  95.4 MBytes   800 Mbits/sec  619    305 KBytes
[  5]   3.00-4.00   sec  61.8 MBytes   518 Mbits/sec   55    313 KBytes
[  5]   4.00-5.00   sec  60.6 MBytes   508 Mbits/sec   71    324 KBytes
[  5]   5.00-6.00   sec  60.9 MBytes   511 Mbits/sec   64    329 KBytes
[  5]   6.00-7.00   sec  61.9 MBytes   519 Mbits/sec   59    339 KBytes
[  5]   7.00-8.00   sec  59.8 MBytes   501 Mbits/sec   56    349 KBytes
[  5]   8.00-9.00   sec  61.8 MBytes   518 Mbits/sec   60    359 KBytes
[  5]   9.00-10.00  sec  61.5 MBytes   516 Mbits/sec   77    368 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   731 MBytes   613 Mbits/sec  1064            sender
[  5]   0.00-10.04  sec   728 MBytes   609 Mbits/sec                  receiver

Je kunt ook -b 90M of -b 95M erachter zetten om die retries naar de 0 te krijgen. Gaat het dan beter?

Je forceert de remote server dan naar een bepaalde snelheid, wat misschien kan resulteren in een meer stabiele download.

Als ik dat b.v. met die upload van mij doe gaat ie wel richting die 0 retries.

 $ iperf3 -c ams.speedtest.clouvider.net -b 450M
Connecting to host ams.speedtest.clouvider.net, port 5201
[  5] local 192.168.2.21 port 48612 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  53.8 MBytes   451 Mbits/sec    3    779 KBytes
[  5]   1.00-2.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   2.00-3.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   3.00-4.00   sec  53.8 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   4.00-5.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   5.00-6.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   6.00-7.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   7.00-8.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   8.00-9.00   sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
[  5]   9.00-10.00  sec  53.6 MBytes   450 Mbits/sec    0    779 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   536 MBytes   450 Mbits/sec    3            sender
[  5]   0.00-10.03  sec   536 MBytes   449 Mbits/sec                  receiver

Maar ik ben dus wel benieuwd naar het commando dat je gebruikt voor upload die 0 retries geeft (en ook naar de andere commando’s en outputs).

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Bedankt voor het meedenken @rvk01, en goede tip met de `-b` test! Hieronder de volledige outputs. Getest naar ams.speedtest.clouvider.net, bekabeld, wifi uit, 100/100 lijn.

**1. Download met -b 90M cap (jouw voorgestelde test):**

```
iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 90M -t 15
Reverse mode, remote host is sending
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 2.65 MBytes 22.1 Mbits/sec
[ 4] 1.00-2.00 sec 1.48 MBytes 12.4 Mbits/sec
[ 4] 2.00-3.00 sec 2.05 MBytes 17.2 Mbits/sec
[ 4] 3.00-4.00 sec 2.09 MBytes 17.6 Mbits/sec
[ 4] 4.00-5.00 sec 1.86 MBytes 15.6 Mbits/sec
[ 4] 5.00-6.00 sec 2.10 MBytes 17.6 Mbits/sec
[ 4] 6.00-7.00 sec 1.85 MBytes 15.5 Mbits/sec
[ 4] 7.00-8.00 sec 1.93 MBytes 16.2 Mbits/sec
[ 4] 8.00-9.00 sec 2.34 MBytes 19.6 Mbits/sec
[ 4] 9.00-10.00 sec 2.04 MBytes 17.1 Mbits/sec
[ 4] 10.00-11.00 sec 1.96 MBytes 16.5 Mbits/sec
[ 4] 11.00-12.00 sec 1.43 MBytes 11.9 Mbits/sec
[ 4] 12.00-13.01 sec 1.83 MBytes 15.3 Mbits/sec
[ 4] 13.01-14.00 sec 1.84 MBytes 15.6 Mbits/sec
[ 4] 14.00-15.00 sec 2.24 MBytes 18.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-15.00 sec 30.0 MBytes 16.8 Mbits/sec 439 sender
[ 4] 0.00-15.00 sec 29.8 MBytes 16.7 Mbits/sec receiver
```

**2. Upload (zonder -R), het commando dat je vroeg:**
```
iperf3 -c ams.speedtest.clouvider.net -p 5201 -t 15
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 12.6 MBytes 105 Mbits/sec
[ 4] 1.01-2.00 sec 12.6 MBytes 107 Mbits/sec
[ 4] 2.00-3.01 sec 12.6 MBytes 105 Mbits/sec
[ 4] 3.01-4.01 sec 12.6 MBytes 106 Mbits/sec
[ 4] 4.01-5.00 sec 12.6 MBytes 106 Mbits/sec
[ 4] 5.00-6.01 sec 12.5 MBytes 104 Mbits/sec
[ 4] 6.01-7.01 sec 12.5 MBytes 105 Mbits/sec
[ 4] 7.01-8.01 sec 12.2 MBytes 102 Mbits/sec
[ 4] 8.01-9.00 sec 12.9 MBytes 109 Mbits/sec
[ 4] 9.00-10.01 sec 12.4 MBytes 104 Mbits/sec
[ 4] 10.01-11.01 sec 12.9 MBytes 108 Mbits/sec
[ 4] 11.01-12.01 sec 12.4 MBytes 104 Mbits/sec
[ 4] 12.01-13.00 sec 12.5 MBytes 105 Mbits/sec
[ 4] 13.00-14.00 sec 12.5 MBytes 105 Mbits/sec
[ 4] 14.00-15.01 sec 12.5 MBytes 104 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-15.01 sec 188 MBytes 105 Mbits/sec sender
[ 4] 0.00-15.01 sec 188 MBytes 105 Mbits/sec receiver
```
(Mijn iperf-build toont in upload-mode geen Retr-kolom, vandaar dat die hier ontbreekt — niet dat er per se 0 zijn. In download-mode toont 'ie de Retr wél, zie hierboven.)

**Mijn interpretatie:**
Bij de -b 90M download vraag ik de server om 90 Mbps te sturen, dus ruim onder mijn lijnlimiet van 100 Mbit. Er is dan geen overshoot tegen de lijn meer, en tóch kom ik niet boven ~16-17 Mbps en blijven de retries rond de 430. Als het puur TCP dat tegen de lijnlimiet aanloopt was (zoals bij jouw 1Gbit-lijn), zou de cap het juist moeten gladstrijken — bij mij doet 'ie niks. Dat wijst op echte packet loss in de download-richting, niet op overshoot.

Klopt ook met een UDP-test van eerder: 17% loss richting mij (1032/6111 datagrams), terwijl upload smetteloos vol loopt.

Goede kanttekening trouwens over die Retr-kolom in upload — mijn build laat die simpelweg niet zien in forward-mode. Als je een specifiek commando wilt dat de Retr/Cwnd in upload wél toont (bv. met --get-server-output of een nieuwere build) hou ik me aanbevolen. Alle ruwe output heb ik bewaard.

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Correctie/aanvulling op mezelf: ik kwam erachter dat iperf3 op Windows de Retr-kolom helemaal niet kan vullen — Windows TCP info wordt niet ondersteund (zie esnet/iperf discussion #1957). De 435 retransmits die ik in download (reverse) zie komen van de Linux-server aan de andere kant; de upload toont geen Retr simpelweg omdat mijn Windows-client de sender is en die de info niet kan leveren. Ik kan dus niet hard zeggen dat upload "0 retransmits" heeft — alleen dat de throughput daar wél vol loopt (105 Mbps vlak). Het echte loss-bewijs zit in de UDP-test: 17% loss richting mij. Wilde dit even rechtzetten.

Update + zelfcorrectie. Ik kwam erachter dat iperf3 op Windows de Retr-kolom helemaal niet kan vullen — Windows TCP info wordt niet ondersteund (zie esnet/iperf discussion #1957). Mijn eerdere "upload 0 retries" was dus een meetartefact, niet de werkelijkheid. Om dat recht te zetten heb ik de tests opnieuw gedraaid vanaf een Linux-host (192.168.1.90) op dezelfde Odido-lijn, waar de Retr-kolom wél in beide richtingen werkt. Getest naar ams.speedtest.clouvider.net, volledige output hieronder.

**Upload (geen -R):**
```
iperf3 -c ams.speedtest.clouvider.net -p 5202 -t 15
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 15.8 MBytes 132 Mbits/sec 1459 50.9 KBytes
[ 5] 1.00-2.00 sec 13.8 MBytes 115 Mbits/sec 49 49.5 KBytes
[ 5] 2.00-3.00 sec 12.4 MBytes 104 Mbits/sec 38 56.6 KBytes
[ 5] 3.00-4.00 sec 12.4 MBytes 104 Mbits/sec 48 53.7 KBytes
[ 5] 4.00-5.00 sec 12.4 MBytes 104 Mbits/sec 61 56.6 KBytes
[ 5] 5.00-6.00 sec 12.4 MBytes 104 Mbits/sec 55 56.6 KBytes
[ 5] 6.00-7.00 sec 12.2 MBytes 103 Mbits/sec 57 65.0 KBytes
[ 5] 7.00-8.00 sec 12.4 MBytes 104 Mbits/sec 50 50.9 KBytes
[ 5] 8.00-9.00 sec 12.4 MBytes 104 Mbits/sec 41 74.9 KBytes
[ 5] 9.00-10.00 sec 12.2 MBytes 103 Mbits/sec 43 50.9 KBytes
[ 5] 10.00-11.00 sec 12.4 MBytes 104 Mbits/sec 38 53.7 KBytes
[ 5] 11.00-12.00 sec 12.4 MBytes 104 Mbits/sec 58 52.3 KBytes
[ 5] 12.00-13.00 sec 13.6 MBytes 114 Mbits/sec 47 50.9 KBytes
[ 5] 13.00-14.00 sec 12.2 MBytes 103 Mbits/sec 27 50.9 KBytes
[ 5] 14.00-15.00 sec 12.4 MBytes 104 Mbits/sec 48 53.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 0.00-15.00 sec 191 MBytes 107 Mbits/sec 2119 sender
[ 5] 0.00-15.04 sec 188 MBytes 105 Mbits/sec receiver
```
Dus je had gelijk @rvk01: er zijn wél retransmits in upload. Het patroon is alleen gezond — 1459 in de eerste seconde (TCP zoekt agressief de lijnlimiet op), daarna zakt het naar ~40-60/sec en blijft de doorvoer stabiel vol op ~104 Mbps. De retries doen de snelheid hier geen pijn.

**Download (-R):**
```
iperf3 -c ams.speedtest.clouvider.net -p 5202 -R -t 15
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 5] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 2.00-3.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 5] 3.00-4.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 5] 4.00-5.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 5] 5.00-6.00 sec 1.62 MBytes 13.6 Mbits/sec
[ 5] 6.00-7.00 sec 2.38 MBytes 19.9 Mbits/sec
[ 5] 7.00-8.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 5] 8.00-9.00 sec 2.25 MBytes 18.9 Mbits/sec
[ 5] 9.00-10.00 sec 2.12 MBytes 17.8 Mbits/sec
[ 5] 10.00-11.00 sec 2.25 MBytes 18.9 Mbits/sec
[ 5] 11.00-12.00 sec 2.38 MBytes 19.9 Mbits/sec
[ 5] 12.00-13.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 5] 13.00-14.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 5] 14.00-15.00 sec 1.75 MBytes 14.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 0.00-15.04 sec 29.1 MBytes 16.2 Mbits/sec 415 sender
[ 5] 0.00-15.00 sec 28.9 MBytes 16.1 Mbits/sec receiver
```

**Download met -b 90M cap:**
```
iperf3 -c ams.speedtest.clouvider.net -p 5202 -R -b 90M -t 15
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 5] 1.00-2.00 sec 1.62 MBytes 13.6 Mbits/sec
[ 5] 2.00-3.00 sec 2.00 MBytes 16.8 Mbits/sec
[ 5] 3.00-4.00 sec 2.25 MBytes 18.9 Mbits/sec
[ 5] 4.00-5.00 sec 2.12 MBytes 17.8 Mbits/sec
[ 5] 5.00-6.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 5] 6.00-7.00 sec 2.38 MBytes 19.9 Mbits/sec
[ 5] 7.00-8.00 sec 1.62 MBytes 13.6 Mbits/sec
[ 5] 8.00-9.00 sec 1.88 MBytes 15.7 Mbits/sec
[ 5] 9.00-10.00 sec 1.62 MBytes 13.6 Mbits/sec
[ 5] 10.00-11.00 sec 2.38 MBytes 19.9 Mbits/sec
[ 5] 11.00-12.00 sec 2.38 MBytes 19.9 Mbits/sec
[ 5] 12.00-13.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 5] 13.00-14.00 sec 1.75 MBytes 14.7 Mbits/sec
[ 5] 14.00-15.00 sec 2.12 MBytes 17.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 0.00-15.04 sec 29.9 MBytes 16.7 Mbits/sec 416 sender
[ 5] 0.00-15.00 sec 29.8 MBytes 16.6 Mbits/sec receiver
```

Het verschil zit 'm dus niet in "wel of geen retransmits", maar in het gedrag:
- Upload: burst aan retries bij de start, daarna stabiliseert het en haalt 107 Mbps (lijn vol).
- Download: doorvoer komt nooit boven ~16 Mbps en herstelt niet.
- De -b 90M cap (ruim onder mijn 100 Mbit lijn) verandert daar niks aan — 16,6 Mbps. Als het puur overshoot tegen de lijnlimiet was, zou de cap dit juist moeten gladstrijken.

Klopt ook met de UDP-test van eerder: 17% packet loss in de download-richting (1032/6111 datagrams). En dit is nu gemeten vanaf een Linux-host, dus los van de Windows-client en de TCP-info-beperking.

Kortom: richtingsgebonden packet loss in de download-richting die single-stream onbruikbaar maakt, terwijl upload netjes vol loopt. Multi-stream verbergt het. Benieuwd of dit een bekend beeld is bij congestie op een gedeeld segment of eerder iets op de aansluiting/OLT.

rvk01
3 maanden geleden
June 25, 2026

Je kunt met iperf3 ook meerdere streams tegelijk testen met b.v. -P 10 voor 10 streams parallel.

Zit je op een Linux machine?

Ik heb dit getest op een Raspberry Pi met $ iperf3 --version 3.18 (cJSON 1.7.15)

Ervaar je dit op 1 machine of op alle machines?

Zou het een MTU of TCP buffer-window probleem kunnen zijn?

Het is in ieder geval wel duidelijk dat die download inderdaad beperkt is tot 18Mbps en daardoor die retries

Mijn snelheid is dus 500/500 (geen 1Gbps). En hier gaat de -R eigenlijk altijd wel goed met minimale retries (omdat de ontvangende kant, ik, dat niet ziet). Zelfs met 990Mbps (wat ver boven mijn snelheid is) valt ie netjes en vrij snel terug naar 500 download.

pi@:~ $ iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 90M -t 15
Connecting to host ams.speedtest.clouvider.net, port 5201
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.2.21 port 47412 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  11.0 MBytes  92.2 Mbits/sec
[  5]   1.00-2.00   sec  10.8 MBytes  90.2 Mbits/sec
[  5]   2.00-3.00   sec  10.8 MBytes  90.2 Mbits/sec
[  5]   3.00-4.00   sec  10.6 MBytes  89.1 Mbits/sec
[  5]   4.00-5.00   sec  10.8 MBytes  90.1 Mbits/sec
[  5]   5.00-6.00   sec  10.8 MBytes  90.2 Mbits/sec
[  5]   6.00-7.00   sec  10.8 MBytes  90.1 Mbits/sec
[  5]   7.00-8.00   sec  10.8 MBytes  90.2 Mbits/sec
[  5]   8.00-9.00   sec  10.8 MBytes  90.2 Mbits/sec
[  5]   9.00-10.00  sec  10.8 MBytes  90.1 Mbits/sec
[  5]  10.00-11.00  sec  10.6 MBytes  89.2 Mbits/sec
[  5]  11.00-12.00  sec  10.8 MBytes  90.2 Mbits/sec
[  5]  12.00-13.00  sec  10.8 MBytes  90.2 Mbits/sec
[  5]  13.00-14.00  sec  10.8 MBytes  90.1 Mbits/sec
[  5]  14.00-15.00  sec  10.8 MBytes  90.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.03  sec   161 MBytes  90.0 Mbits/sec    1            sender
[  5]   0.00-15.00  sec   161 MBytes  90.2 Mbits/sec                  receiver

iperf Done.
pi@:~ $ iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 990M -t 15
Connecting to host ams.speedtest.clouvider.net, port 5201
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.2.21 port 42892 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  54.1 MBytes   454 Mbits/sec
[  5]   1.00-2.00   sec  60.1 MBytes   504 Mbits/sec
[  5]   2.00-3.00   sec  60.0 MBytes   503 Mbits/sec
[  5]   3.00-4.00   sec  60.2 MBytes   505 Mbits/sec
[  5]   4.00-5.00   sec  60.1 MBytes   504 Mbits/sec
[  5]   5.00-6.00   sec  60.1 MBytes   504 Mbits/sec
[  5]   6.00-7.00   sec  60.1 MBytes   504 Mbits/sec
[  5]   7.00-8.00   sec  60.2 MBytes   505 Mbits/sec
[  5]   8.00-9.00   sec  60.1 MBytes   504 Mbits/sec
[  5]   9.00-10.00  sec  60.1 MBytes   504 Mbits/sec
[  5]  10.00-11.00  sec  60.2 MBytes   505 Mbits/sec
[  5]  11.00-12.00  sec  60.1 MBytes   504 Mbits/sec
[  5]  12.00-13.00  sec  60.1 MBytes   504 Mbits/sec
[  5]  13.00-14.00  sec  60.2 MBytes   505 Mbits/sec
[  5]  14.00-15.00  sec  60.1 MBytes   504 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.03  sec   899 MBytes   502 Mbits/sec    0            sender
[  5]   0.00-15.00  sec   896 MBytes   501 Mbits/sec                  receiver

iperf Done.

Met de UDP test kun je inderdaad zien hoeveel er verloren gaat. Dat zijn overigens geen dropped packages maar gewoon packages die niet aankomen omdat de snelheid niet zo hoog ligt voor 1 stream. Als ik bv -M 990M doe, dan heb ik ook 48% verlies (omdat mijn lijn maar 500 is)

pi@:~ $ iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 90M -u
Connecting to host ams.speedtest.clouvider.net, port 5201
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.2.21 port 43532 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  10.9 MBytes  91.0 Mbits/sec  0.006 ms  160/8027 (2%)
[  5]   1.00-2.00   sec  10.7 MBytes  90.0 Mbits/sec  0.008 ms  0/7769 (0%)
[  5]   2.00-3.00   sec  10.7 MBytes  90.1 Mbits/sec  0.012 ms  0/7769 (0%)
[  5]   3.00-4.00   sec  10.7 MBytes  89.9 Mbits/sec  0.006 ms  0/7770 (0%)
[  5]   4.00-5.00   sec  10.7 MBytes  90.0 Mbits/sec  0.005 ms  0/7769 (0%)
[  5]   5.00-6.00   sec  10.7 MBytes  90.0 Mbits/sec  0.006 ms  0/7770 (0%)
[  5]   6.00-7.00   sec  10.7 MBytes  90.0 Mbits/sec  0.012 ms  0/7769 (0%)
[  5]   7.00-8.00   sec  10.7 MBytes  90.0 Mbits/sec  0.011 ms  0/7769 (0%)
[  5]   8.00-9.00   sec  10.7 MBytes  90.1 Mbits/sec  0.006 ms  0/7770 (0%)
[  5]   9.00-10.00  sec  10.7 MBytes  89.9 Mbits/sec  0.018 ms  0/7769 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec   108 MBytes  90.0 Mbits/sec  0.000 ms  0/0 (0%)  sender
[  5]   0.00-10.00  sec   107 MBytes  90.1 Mbits/sec  0.018 ms  160/77951 (0.21%)  receiver

iperf Done.
pi@:~ $ iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 990M -u
Connecting to host ams.speedtest.clouvider.net, port 5201
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.2.21 port 39349 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  61.3 MBytes   514 Mbits/sec  0.027 ms  41654/86063 (48%)
[  5]   1.00-2.00   sec  61.1 MBytes   513 Mbits/sec  0.023 ms  41176/85444 (48%)
[  5]   2.00-3.00   sec  61.2 MBytes   513 Mbits/sec  0.025 ms  41188/85473 (48%)
[  5]   3.00-4.00   sec  61.1 MBytes   513 Mbits/sec  0.026 ms  41218/85490 (48%)
[  5]   4.00-5.00   sec  61.1 MBytes   513 Mbits/sec  0.027 ms  41170/85446 (48%)
[  5]   5.00-6.00   sec  61.1 MBytes   513 Mbits/sec  0.029 ms  41202/85475 (48%)
[  5]   6.00-7.00   sec  61.1 MBytes   512 Mbits/sec  0.025 ms  41215/85435 (48%)
[  5]   7.00-8.00   sec  61.2 MBytes   513 Mbits/sec  0.025 ms  41193/85480 (48%)
[  5]   8.00-9.00   sec  61.1 MBytes   513 Mbits/sec  0.027 ms  41203/85485 (48%)
[  5]   9.00-10.00  sec  61.1 MBytes   513 Mbits/sec  0.025 ms  41150/85429 (48%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.07  sec  1.16 GBytes   990 Mbits/sec  0.000 ms  0/0 (0%)  sender
[  5]   0.00-10.00  sec   612 MBytes   513 Mbits/sec  0.025 ms  412369/855220 (48%)  receiver

iperf Done.

Dus dit zou bij jou 0 verlies geven.

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 15M -u

en dit zou de snelheid van 105 Mbps moeten kunnen halen

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 15M -u -P 7

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Goede vervolgtests @rvk01 — en ze geven volgens mij precies de kern. Beide gedraaid vanaf de Linux-host (Home Assistant, 192.168.1.90) op dezelfde Odido-lijn. Volledige output hieronder.

Even vooraf op je punten:

Eén machine of alle: het is op alle machines op deze lijn identiek (Windows-laptop, Linux-host), dus niet client-specifiek.
MTU / TCP-window: MTU heb ik eerder symmetrisch gemeten op 1388 (geen blackhole). En de UDP-tests hieronder laten zien dat het ook los van TCP-window speelt.
Jouw observatie "download beperkt tot ~18 Mbps en daardoor de retries" klopt — maar de oorzaak is omgekeerd: niet de retries beperken de download, de packet loss beperkt 'm en veroorzaakt de retries.

1. Single-stream UDP, -b 15M (jouw voorgestelde test):

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 15M -u
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.1.90 port 37930 connected to 194.127.172.176 port 5201
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  1.82 MBytes  15.3 Mbits/sec  0.046 ms  29/1347 (2.2%)
[  5]   1.00-2.00   sec  1.75 MBytes  14.7 Mbits/sec  0.045 ms  27/1295 (2.1%)
[  5]   2.00-3.00   sec  1.75 MBytes  14.7 Mbits/sec  0.072 ms  29/1295 (2.2%)
[  5]   3.00-4.00   sec  1.76 MBytes  14.7 Mbits/sec  0.041 ms  22/1295 (1.7%)
[  5]   4.00-5.00   sec  1.75 MBytes  14.7 Mbits/sec  0.027 ms  27/1295 (2.1%)
[  5]   5.00-6.00   sec  1.76 MBytes  14.8 Mbits/sec  0.049 ms  21/1295 (1.6%)
[  5]   6.00-7.00   sec  1.75 MBytes  14.7 Mbits/sec  0.053 ms  30/1295 (2.3%)
[  5]   7.00-8.00   sec  1.75 MBytes  14.7 Mbits/sec  0.038 ms  25/1294 (1.9%)
[  5]   8.00-9.00   sec  1.76 MBytes  14.8 Mbits/sec  0.045 ms  17/1294 (1.3%)
[  5]   9.00-10.00  sec  1.75 MBytes  14.7 Mbits/sec  0.050 ms  29/1296 (2.2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.05  sec  18.0 MBytes  15.0 Mbits/sec  0.000 ms  0/0 (0%)  sender
[  5]   0.00-10.00  sec  17.6 MBytes  14.8 Mbits/sec  0.050 ms  256/13001 (2%)  receiver

Jij voorspelde 0% verlies bij 15M. Bij mij is het 2% — terwijl 15 Mbps op mijn 100 Mbit-lijn ruim onder de capaciteit zit. Bij jou is 90M nog maar 0,21% loss; bij mij is zelfs 15M al 2%. Dáár zit het verschil tussen onze lijnen.

2. Multi-stream UDP, -b 15M -P 7 (= 105M aggregate):

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 15M -u -P 7
Reverse mode, remote host ams.speedtest.clouvider.net is sending
[  5] local 192.168.1.90 port 53416 connected to 194.127.172.176 port 5201
[  7] local 192.168.1.90 port 33390 connected to 194.127.172.176 port 5201
[  9] local 192.168.1.90 port 35998 connected to 194.127.172.176 port 5201
[ 11] local 192.168.1.90 port 38907 connected to 194.127.172.176 port 5201
[ 13] local 192.168.1.90 port 55404 connected to 194.127.172.176 port 5201
[ 15] local 192.168.1.90 port 39334 connected to 194.127.172.176 port 5201
[ 17] local 192.168.1.90 port 42992 connected to 194.127.172.176 port 5201
[SUM]   0.00-1.00   sec  12.3 MBytes   103 Mbits/sec  0.060 ms  180/9086 (2%)
[SUM]   1.00-2.00   sec  12.3 MBytes   103 Mbits/sec  0.061 ms  172/9065 (1.9%)
[SUM]   2.00-3.00   sec  12.3 MBytes   103 Mbits/sec  0.044 ms  177/9064 (2%)
[SUM]   3.00-4.00   sec  12.3 MBytes   103 Mbits/sec  0.061 ms  183/9066 (2%)
[SUM]   4.00-5.00   sec  12.2 MBytes   103 Mbits/sec  0.102 ms  187/9056 (2.1%)
[SUM]   5.00-6.00   sec  12.3 MBytes   103 Mbits/sec  0.116 ms  178/9074 (2%)
[SUM]   6.00-7.00   sec  12.3 MBytes   103 Mbits/sec  0.049 ms  172/9057 (1.9%)
[SUM]   7.00-8.00   sec  12.2 MBytes   103 Mbits/sec  0.102 ms  203/9065 (2.2%)
[SUM]   8.00-9.00   sec  12.3 MBytes   103 Mbits/sec  0.063 ms  182/9060 (2%)
[SUM]   9.00-10.00  sec  12.3 MBytes   103 Mbits/sec  0.094 ms  195/9067 (2.2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.099 ms  272/12952 (2.1%)  receiver
[  7]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.067 ms  252/12950 (1.9%)  receiver
[  9]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.087 ms  272/12951 (2.1%)  receiver
[ 11]   0.00-10.00  sec  17.6 MBytes  14.7 Mbits/sec  0.082 ms  239/12951 (1.8%)  receiver
[ 13]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.112 ms  274/12952 (2.1%)  receiver
[ 15]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.096 ms  264/12952 (2%)  receiver
[ 17]   0.00-10.00  sec  17.5 MBytes  14.7 Mbits/sec  0.112 ms  256/12952 (2%)  receiver
[SUM]   0.00-10.01  sec   125 MBytes   105 Mbits/sec  0.000 ms  0/0 (0%)  sender
[SUM]   0.00-10.00  sec   123 MBytes   103 Mbits/sec  0.094 ms  1829/90660 (2%)  receiver

En dit is volgens mij het bewijsstuk: met 7 streams haalt de lijn keurig de volle 103-105 Mbps — de capaciteit is er dus gewoon. Máár de packet loss blijft 2%, óók nu de lijn vol loopt. Elke individuele stream verliest ~2%, het totaal ook (1829/90660).

Conclusie: de 2% loss is er bij elke snelheid (15M single, 15M×7 aggregate), het is geen overvraging van de lijn. Bij multi-stream maakt die 2% niet uit — de streams vullen elkaars gaten en de lijn loopt vol. Bij single-stream is diezelfde 2% dodelijk — één TCP-stream halveert zijn window bij elke loss en komt over deze ~25 ms latency nooit boven ~16 Mbps.

Dat verklaart eindelijk het hele beeld: speedtest/multi-stream is "groen" (105 Mbps), maar elke single-stream transfer (file-copy, VPN, RDP, git clone) is onbruikbaar traag — niet door gebrek aan bandbreedte, maar door structurele packet loss die alleen single-stream TCP echt raakt.

De vraag wordt dan: waar komt die ~2% download-loss vandaan, gegeven dat upload smetteloos vol loopt en mijn eigen apparatuur (Zyxel WAN 0 drops, bekabeld, wifi uit) schoon is? Lijkt me iets in het toegangsnetwerk richting mij.

rvk01
3 maanden geleden
June 25, 2026

Eén machine of alle: het is op alle machines op deze lijn identiek (Windows-laptop, Linux-host), dus niet client-specifiek.
MTU / TCP-window: MTU heb ik eerder symmetrisch gemeten op 1388 (geen blackhole). En de UDP-tests hieronder laten zien dat het ook los van TCP-window speelt.

Nee, MTU is het dan ook niet. En als het op alle machines is zal het ook de TCP window-buffer ook niet zijn. Wat bedoel je met “op deze lijn”. Zit er een switch tussen?

1. Single-stream UDP, -b 15M (jouw voorgestelde test):

Die 15M was even een inschatting van mij van hoeveel dus maximaal te halen zou zijn met 1 stream. Dat zou dus misschien 14M of zelfs 13M moeten zijn. Alles daarboven gaat pakketjes verliezen. Doe de testen nog maar eens met 13M.

Maar…. die pakketjes verliezen moet je niet zien als echte packetloss. Het is gewoon dat de onderliggende netwerkstack tot die snelheid aankan en alles daarboven dropt. Dat zag je met de 990M test bij mijn 500/500 lijn. Daar had ik ook 48% pakketjes verlies. Maar mijn lijn is verder prima in orde (voor 500Mbps). Dus jouw download lijn is eigenlijk maar 13Mbps of 14Mbps voor 1 stream.

Even een andere gedachte… ik vroeg al of je er een switch tussen had zitten? Maar nu begin ik me ook af te vragen of de kabel goed is. Je gaf al aan dat de WAN poort 1000M/Full aangaf op de Zyxel. Wat geeft de LAN poort aan? Bij een 100Mbps verbinding is het n.l. zo dat 2 aders dedicated download en 2 aders dedicated upload zijn. Dan zouden de download aders misschien slecht kunnen zijn (of stekker slecht geknepen). Zou je dit eens met een korte voorgeknepen kabel direct op de Zyxel poort uit kunnen testen (of is dat lastig met de opstelling)?

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Dank voor het blijven meedenken @rvk01, top dat je zo grondig bent. Laat me je punten langslopen, want ik denk dat ik ze kan afvinken.

Netwerkopstelling (je vroeg of er een switch tussen zit):

Normaal: glasvezel → ONT → (kabel van de provider) → router → in-wall bekabeling met keystones → een gemanagede switch → NAS / werkplek / Linux-host.

Maar: ik heb vandaag mijn laptop rechtstreeks op een LAN-poort van de router gehangen — dus switch, in-wall bekabeling en keystones er allemaal tussenuit. Probleem bleef identiek. De switch en de vaste bekabeling vallen daarmee af. (En de meting via de Linux-host liep juist wél via die switch, ook identiek — dus de switch voegt aantoonbaar niks toe.)

Kabel / stekker:

Mijn eigen kabels zijn allemaal kant-en-klare cat6 patchkabels, geen zelf-geknepen exemplaren (ik monteer overal keystones). Het is materiaal van het werk waar we alles mee aansluiten — ik werk 27 jaar in de techniek en heb genoeg kabels gemaakt en met een kabeltester doorgemeten.

Eén kabel die ik niet zelf gecontroleerd heb is de kabel die de provider tussen het ONT en de WAN-poort van de router geleverd heeft. Die ga ik nog vervangen door een eigen geteste kabel om 'm uit te sluiten. Al verwacht ik daar weinig van: mijn upload loopt over diezelfde kabel smetteloos vol (105 Mbps, 0 loss), en de WAN-poort draait 1000M/Full — een kabel die selectief alleen de download sloopt maar upload perfect laat, op een gigabit-link, lijkt me technisch onwaarschijnlijk. Maar ik test het.

Belangrijker nog: het probleem is identiek over meerdere kabels en meerdere machines aan de LAN-kant, dus één slechte stekker daar verklaart het niet.

Aderparen-theorie (2 dedicated download / 2 upload):

Die geldt alleen bij een 100M-link. Mijn poorten draaien allemaal 1000M/Full (zowel WAN als de LAN-poort waar de laptop op zit). Bij gigabit worden alle vier de aderparen bidirectioneel gebruikt — er zijn dus geen aparte "download-aders" die slecht kunnen zijn. Die hypothese vervalt daarmee op een gigabit-link.

Over "het is gewoon je max van ~13M":

Hier wil ik vriendelijk tegenin gaan, want volgens mij is dit net de denkfout. Jouw 48% verlies bij -b 990M ontstond doordat je bijna het dubbele van je 500-lijn vroeg — de helft moet dan wel sneuvelen, dat is overvraging. Logisch.

Maar bij mij is het geen overvraging: ik vraag 15M op een 100 Mbit-lijn, met 85% van de lijn ongebruikt, en verlies toch 2%. Op een gezonde lijn hoort 15 Mbps single-stream met nul verlies door te komen — jouw lijn doet 90M nog met 0,21%. "Mijn download is gewoon een 13M single-stream lijn" is geen verklaring, het is het probleem zelf: een 100 Mbit glasvezellijn die single-stream maar 13-16 Mbps haalt door constante loss, terwijl upload smetteloos vol loopt.

Ik draai de test graag nog met -b 13M zoals je vroeg, maar mijn verwachting is dat ook daar loss in zit — want de loss is er al bij 15M ruim onder de lijn.

Waarom dit voor mij zo'n probleem is: vrijwel al mijn werk gaat over één TCP-verbinding. Ik werk veel via VPN, en een VPN-tunnel is één stream — net als een SMB file-copy, RDP, of een git clone. Dat is precies waar die ~13-16 Mbps single-stream pijn doet: download via de VPN is echt dramatisch traag, terwijl een speedtest "gewoon 100" laat zien. De multi-stream/aggregate cijfers zijn voor mijn dagelijkse gebruik dus niet representatief — het is juist het single-stream gedrag dat telt, en dat is stuk.

En misschien wel het belangrijkste: dit probleem is niet altijd zo geweest. Toen ik hier net zat werkte het gewoon goed — het is pas zo'n 2 à 4 weken geleden begonnen. Mijn opstelling, kabels en apparatuur zijn in die tijd niet veranderd. Een probleem dat plotseling ontstaat op een ongewijzigde opstelling wijst er voor mij sterk op dat er iets buiten mijn eigen netwerk is veranderd — aan de aansluiting of in het toegangsnetwerk. Als het de bekabeling of opstelling was, had ik het immers vanaf het begin gehad.

Het sluitende punt aan mijn kant: de WAN-interface van mijn router toont 0 errors en 0 drops (verzonden én ontvangen), bekabelde LAN-poorten ook 0. De pakketten die in de iperf-test verloren gaan, bereiken mijn router dus niet eens — ze sneuvelen vóór de WAN-interface, oftewel in het netwerk richting mij.

Kortom: switch, bekabeling, kabels en poorten aan mijn kant zijn afgedekt, het is bron-onafhankelijk en richtingsgebonden (download stuk, upload perfect). Het gaat me puur om het single-stream gedrag, want dáár draait mijn werk op. Daarom blijft mijn vermoeden bij het toegangsnetwerk richting mij.

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Nog even de -b 13M test gedraaid die je voorstelde @rvk01 — om te checken of de loss onder een bepaalde drempel verdwijnt:

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 13M -u
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  1.59 MBytes  13.3 Mbits/sec  0.094 ms  20/1169 (1.7%)
[  5]   1.00-2.00   sec  1.51 MBytes  12.7 Mbits/sec  0.080 ms  30/1122 (2.7%)
[  5]   2.00-3.00   sec  1.53 MBytes  12.9 Mbits/sec  0.114 ms  12/1122 (1.1%)
[  5]   3.00-4.00   sec  1.53 MBytes  12.8 Mbits/sec  0.078 ms  17/1122 (1.5%)
[  5]   4.00-5.00   sec  1.52 MBytes  12.7 Mbits/sec  0.063 ms  22/1123 (2%)
[  5]   5.00-6.00   sec  1.52 MBytes  12.7 Mbits/sec  0.052 ms  23/1122 (2%)
[  5]   6.00-7.00   sec  1.52 MBytes  12.8 Mbits/sec  0.059 ms  21/1122 (1.9%)
[  5]   7.00-8.00   sec  1.52 MBytes  12.8 Mbits/sec  0.062 ms  19/1122 (1.7%)
[  5]   8.00-9.00   sec  1.53 MBytes  12.8 Mbits/sec  0.060 ms  15/1123 (1.3%)
[  5]   9.00-10.00  sec  1.52 MBytes  12.7 Mbits/sec  0.045 ms  23/1122 (2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-10.00  sec  15.3 MBytes  12.8 Mbits/sec  0.045 ms  202/11269 (1.8%)  receiver

Ook bij 13M nog steeds 1,8% loss. Er is dus geen drempel waaronder het verlies verdwijnt — 15M gaf 2%, 13M geeft 1,8%, allebei ruim onder mijn lijncapaciteit. Het is dus geen overvraging (zoals jouw 48% bij 990M op een 500-lijn), maar constante packet loss die er bij elke snelheid is. Als 13M echt mijn "schone max" was, zou ik daar 0% moeten zien in plaats van 1,8%.

rvk01
3 maanden geleden
June 25, 2026

... ik werk 27 jaar in de techniek en heb genoeg kabels gemaakt en met een kabeltester doorgemeten.

Op zich kan een kabel wel slecht zijn en toch nog door de kabel tester komen (tenzij je echt een professionele kabel tester hebt 😉). Maar met een korte kabel op de router is dat in ieder geval ook uitgesloten.

Eén kabel die ik niet zelf gecontroleerd heb is de kabel die de provider tussen het ONT en de WAN-poort van de router geleverd heeft.

Ook een voorgeknepen kabel dus verwacht hier ook niet zozeer een probleem (maar testen kan geen kwaad).

Aderparen-theorie (2 dedicated download / 2 upload):

Die geldt alleen bij een 100M-link. Mijn poorten draaien allemaal 1000M/Full (zowel WAN als de LAN-poort waar de laptop op zit).

Ja, daarom noemde ik ook de link snelheid van de LAN poort. Als die toevallig 100M zou zijn, zou een ader beschadiging nog een mogelijkheid zijn. Bij 1000M/Full kan het theoretisch nog wel maar is die kans astronomisch kleiner.

Ik draai de test graag nog met -b 13M zoals je vroeg, maar mijn verwachting is dat ook daar loss in zit — want de loss is er al bij 15M ruim onder de lijn.

Daar ben ik nog wel benieuwd naar ja. Het was niet zozeer om aan te geven dat de lijn bij 13M of 15M goed is, maar meer om het minimum (of eigenlijk maximum) van die ene stream te bepalen. Als 13M 0 loss heeft, dan weet je dus dat 15M teveel is en 13M goed. Maar uiteraard zou 95M (of zelfs niets opgeven) gewoon goed moeten zijn. Want je moet met 1 stream gewoon de snelheid kunnen halen.

Dan kunnen ze wel zeggen "op, de speedtest is goed" maar zoals je zelf al aangeeft... er zijn ook toepassingen waarbij je met 1 stream gewoon de max niet kunnen halen.

Dan komen we toch wel richting het punt waarbij de technische dienst van Odido en echte behoorlijke lijn meting moet gaan doen denk ik.

@Odido @Cheyenne van Odido ?

HAPV2
Auteur
is een Master Poster
3 maanden geleden
June 25, 2026

Precies, daar zijn we het helemaal over eens — met 1 stream zou ik gewoon de snelheid moeten kunnen halen, en dat lukt niet. Onze posts kruisten elkaar; ik had de -b 13M test die je vroeg al gedraaid:

iperf3 -c ams.speedtest.clouvider.net -p 5201 -R -b 13M -u
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  1.59 MBytes  13.3 Mbits/sec  0.094 ms  20/1169 (1.7%)
[  5]   1.00-2.00   sec  1.51 MBytes  12.7 Mbits/sec  0.080 ms  30/1122 (2.7%)
[  5]   2.00-3.00   sec  1.53 MBytes  12.9 Mbits/sec  0.114 ms  12/1122 (1.1%)
[  5]   3.00-4.00   sec  1.53 MBytes  12.8 Mbits/sec  0.078 ms  17/1122 (1.5%)
[  5]   4.00-5.00   sec  1.52 MBytes  12.7 Mbits/sec  0.063 ms  22/1123 (2%)
[  5]   5.00-6.00   sec  1.52 MBytes  12.7 Mbits/sec  0.052 ms  23/1122 (2%)
[  5]   6.00-7.00   sec  1.52 MBytes  12.8 Mbits/sec  0.059 ms  21/1122 (1.9%)
[  5]   7.00-8.00   sec  1.52 MBytes  12.8 Mbits/sec  0.062 ms  19/1122 (1.7%)
[  5]   8.00-9.00   sec  1.53 MBytes  12.8 Mbits/sec  0.060 ms  15/1123 (1.3%)
[  5]   9.00-10.00  sec  1.52 MBytes  12.7 Mbits/sec  0.045 ms  23/1122 (2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   0.00-10.00  sec  15.3 MBytes  12.8 Mbits/sec  0.045 ms  202/11269 (1.8%)  receiver

Ook bij 13M nog steeds 1,8% loss. Er is dus geen drempel waaronder het verlies verdwijnt — 15M gaf 2%, 13M geeft 1,8%, allebei ruim onder mijn lijncapaciteit. Geen overvraging dus, maar constante loss bij elke snelheid. Als 13M echt mijn "schone max" was, zou ik daar 0% moeten zien.

Over de aderparen, om die laatste theoretische mogelijkheid ook dicht te timmeren: bij gigabit valt de link juist terug naar 100M zodra één aderpaar niet goed functioneert. 1000BASE-T heeft alle vier de paren nodig en gebruikt ze bidirectioneel (met echo-cancellation) — je kunt dus niet op 1000M blijven draaien met een defect paar dat selectief alleen de download sloopt. Of alle vier de paren zijn gezond en je haalt 1000M/Full, of de link zakt naar 100M. Mijn link staat stabiel op 1000M/Full.

En de praktijkbevestiging daarbij: intern haal ik gewoon volle gigabit-snelheid naar mijn NAS en andere apparatuur, over exact dezelfde bekabeling, poorten en keystones. Als daar een ader- of kabelprobleem zat, zou ik dat bij die interne transfers net zo goed merken — maar intern loopt het vol door. Het probleem is dus uitsluitend zichtbaar op verkeer dat van buiten binnenkomt, niet op intern verkeer over dezelfde infrastructuur.

Daarmee is de bekabeling/poort-kant wat mij betreft afgedekt. Eens met je dat dit richting een echte lijnmeting door de technische dienst moet — dank voor het grondige meedenken, het heeft mooi geholpen om alles aan mijn kant af te pellen.

HAPV2
Auteur
is een Master Poster
3 maanden geleden
July 6, 2026

Is er nog meer informatie nodig of kunnen jullie Odido support inschakelen??

Nora van Odido
Moderator | Internet + TV
3 maanden geleden
July 7, 2026

Hi @HAPV2, ik wil graag de verbinding aan onze kant voor je uitlezen! Ik heb je zojuist een privébericht gestuurd via ons Moderator account om je gegevens te verifiëren. Zodra de verificatie gedaan is, praten we verder in dit topic. Dit doen we zodat er altijd een collega voor je klaarstaat. Ik zie je privébericht graag tegemoet!

Ongevraagde privéberichten worden niet beantwoord. Neem snel een kijkje in onze handige Wiki: https://community.odido.nl/knowledge-base.

HAPV2
Auteur
is een Master Poster
Antwoord
2 maanden geleden
August 11, 2026