De trage downloads op de RTX5090 zijn opgelost: er stond energiebesparing aan op de netwerkkaart. Download ging van 82 naar circa 400 Mbps, latency van 45,6 naar 3,3 ms.
Maar tijdens het meten kwam een groter probleem boven water. Elke machine in huis haalt bijna 2 Gbps upload maar blijft op 300 tot 700 Mbps download steken. De oorzaak zit niet in je PC's en niet in je lijn, maar in je UDM-Pro: die inspecteert al het binnenkomende verkeer met IDS/IPS en loopt daarbij tegen zijn processorgrens aan. Op een 4 Gbit-abonnement laat je daar het meeste liggen.
Je meldde dat downloads structureel laag aanvoelden. In plaats van te gokken heb ik vergeleken: de RTX5080 hangt aan dezelfde lijn, dus als die wél snel is ligt het aan de PC. Dat was zo.
| Meting | Download | Upload | Latency | Jitter |
|---|---|---|---|---|
| RTX5090 vóór | 82 Mbps | 355 Mbps | 45,62 ms | 7,02 ms |
| RTX5090 na de fix | 409 Mbps | 1.627 Mbps | 3,25 ms | 0,24 ms |
| RTX5080 ter vergelijking | 511 Mbps | 756 Mbps | 11,99 ms | 8,27 ms |
Op de netwerkkaart van de 5090 stond Power Saving Mode aan, op de 5080 stond die uit. Die instelling laat de ethernet-link telkens in slaapstand zakken en weer wakker worden. Het gevolg is precies wat we maten: sterk verhoogde latency en een instortende download, terwijl upload er minder last van heeft.
Dat de latency na het uitzetten van 45,6 naar 3,3 ms dook, en de jitter van 7,02 naar 0,08 ms, is het sluitende bewijs. Dat is geen meetruis, dat is een link die niet meer in slaap valt.
Power Saving Mode uitgezet en adapter herstart (link weer op 2,5 Gbps)Windows mag deze kaart uitschakelen uitgezetGemeten met de officiële Ookla speedtest, tegen dezelfde server (KPN Amstelveen), strikt één machine tegelijk zodat ze elkaar niet in de weg zitten.
| Machine | Verbinding | Download | Upload | Latency |
|---|---|---|---|---|
| M5 Max | kabel, 2.500Base-T | 632 Mbps | 2.019 Mbps | 3,40 ms |
| Mac mini | kabel, USB 2,5G-adapter | 684 Mbps | 1.765 Mbps | 3,79 ms |
| RTX5090 | kabel, 2.500Base-T | 297 Mbps | 1.996 Mbps | 3,41 ms |
| RTX5080 | kabel, 2.500Base-T | 314 Mbps | 1.503 Mbps | 3,36 ms |
| M4 Pro | wifi | 389 Mbps | 514 Mbps | 7,73 ms |
Het patroon springt eruit en het geldt voor élke bekabelde machine, ongeacht besturingssysteem: upload rond de 1,5 tot 2 Gbps, download tussen 300 en 700 Mbps. Je 2,5 Gbit-uplink naar de woonkamer wordt in de upload-richting dus keurig volgemaakt. In de download-richting blijft er twee derde ongebruikt.
Omdat dit alle machines treft, kan het niet aan een PC liggen. Het zit ervóór.
Op de router draaien deze processen:
/usr/sbin/dpi-flow-stats Deep Packet Inspection /usr/bin/ubnt-idsips-daemon IDS/IPS-daemon suricata 27,9% CPU, 27 min CPU-tijd in 1,5 uur draaitijd load average: 3.25, 4.11, 6.78 op 4 cores
Een load van 6,78 op 4 cores betekent dat de router tijdens de downloadtests 170% overbelast was. Suricata inspecteert al het verkeer dat je netwerk binnenkomt, en dat gebeurt in software. Daar loopt de processor van de UDM-Pro op vast.
Dit verklaart ook meteen waarom juist de download lijdt en de upload niet: inspectie wordt vooral toegepast op inkomend verkeer.
eth9 met 10 Gbps SFP+, ruim voldoende voor 4 Gbit.ppp0 staan 0 fouten en 0 verworpen pakketten over 169 GB ontvangen verkeer. Lokaal meet ik 0,38 ms naar de gaming-PC.De grootste winst zit in het uitzetten of beperken van IDS/IPS en DPI op de UDM-Pro. Verwachting: je download springt van circa 400 Mbps naar ruim boven de 1 Gbps.
De afweging is echt een afweging: je levert er inbraakdetectie voor in. Tussenvormen zijn mogelijk, bijvoorbeeld alleen detectie in plaats van preventie, of inspectie beperken tot bepaalde netwerken. Ik heb hier bewust niets aan veranderd, want dit is een beveiligingsinstelling van je hele netwerk. Zeg het maar, dan zet ik het om en meet ik direct het verschil.
Structureel geldt: een UDM-Pro haalt met inspectie aan simpelweg geen 4 Gbit. Wil je beide, dan is een zwaardere gateway nodig.
De mini is niet traag, hij haalt 684 down en 1.765 up. Een eerdere meting van 5 Mbps was vervuild doordat er tegelijk andere tests liepen; die heb ik verworpen.
en8, een USB 2,5G-adapter, op 2.500Base-T. De ingebouwde poort en0 is niet aangesloten. Dat is prima: die USB-adapter is sneller dan de ingebouwde 1 Gbit-poort.389 down en 514 up over wifi, met 7,73 ms latency. Netjes voor draadloos, maar minder dan de helft van wat de bekabelde machines halen. Zodra je hem op de kabel zet, gaat hij mee omhoog.
Zijn firewall staat SSH alleen toe op het profiel Private, terwijl zijn ethernetverbinding als Public geclassificeerd is. Daardoor is hij lokaal niet bereikbaar en loopt al het beheerverkeer via Tailscale. Niet dringend, maar wel een verbeterpunt. Op jouw woord open ik poort 22 uitsluitend voor je eigen subnet.
Je vroeg terecht of het niet slimmer is om thuis het LAN te gebruiken in plaats van Tailscale. Dat scheelt inderdaad, vooral bij bulk-verkeer zoals de nachtelijke backup. Vanochtend zat je M5 zelfs op een ander segment, waardoor verkeer naar de mini via de relay in Amsterdam liep. Dat verklaart waarom die backup van 171 GB er een uur over deed.
In ~/.ssh/config staat nu per machine een pad dat automatisch kiest: eerst het LAN-adres, en alleen als dat niet bereikbaar is via Tailscale. Hetzelfde commando werkt dus thuis én onderweg.
| Alias | LAN-adres | Terugval | Huidig pad |
|---|---|---|---|
macmini | 192.168.2.154 | Tailscale | LAN ✓ |
m4 | 192.168.2.161 | Tailscale | LAN ✓ |
rtx5080 | 192.168.2.226 | Tailscale | LAN ✓ |
rtx5090 | 192.168.2.34 | Tailscale | Tailscale (firewall) |
De backup is na de wijziging getest: restic bereikt het repo gewoon en loopt nu over de kabel. Van de oude config staat een back-up onder ~/.ssh/config.bak-20260721-150243.
Power Saving Mode uit, adapter herstart, kaart mag niet meer uitgeschakeld worden