Skip to main content
Vraag

Hoge in-game latency (hitreg problemen) op glasvezel vergeleken met ADSL en Ziggo

  • June 24, 2026
  • 1 reactie
  • 16 keer bekeken

Beste KPN Community en moderators,

Ik wil melden dat ik al jaren een probleem heb met KPN glasvezel. Ik ben nu verhuisd naar een ander huis. Op mijn oude adres had ik altijd al vertraging op de glasvezel.

Toen ik naar mijn nieuwe adres verhuisde, had ik eerst KPN ADSL. Die was perfect. Ik kreeg weliswaar alleen 10 Mbps binnen, maar ik kon gewoon normaal gamen (Call of Duty). Mijn kogels registreerden daar normaal (goede hitreg). Via een traceroute zag ik dat Hop 2 eindigde op *.fixed.kpn.net. Hier had ik geen vertraging op ADSL.

Nu heb ik op dit nieuwe adres sinds 2 maanden glasvezel en het is heel slecht. Bij een traceroute zie ik dat Hop 2 nu eindigt op *.static.kpn.net, en daar heb ik wel erg veel vertraging. Zelfs als ik hier mijn Ziggo aansluit op de coax-kabel, kan ik gewoon normaal gamen. Door deze vertraging heb ik speciaal een EdgeRouter 4 en een MikroTik router aangeschaft voor een betere bufferbloat, om te kijken of ik normaal kan spelen op fiber, maar de vertraging gaat niet weg.

Er is een monteur langs geweest en die heeft de SC-connector in de wijkcentrale en ook bij mij thuis gepoetst. Ik krijg de snelheid wel binnen, maar de latency blijft er. Dit is bij alle games die ik speel, dus het is geen service-probleem van de game zelf. Ik merk het ook op de PS5.

Ik bel de klantenservice, maar hun weten niks. Ze zeggen alleen dat je de snelheid binnenkrijgt of ze kijken via hun tablet en zeggen dat alles gewoon goed is. Maar ik weet wat ik voel tijdens het gamen. Vooral nu ik KPN glasvezel vergelijk tegenover Ziggo coax; coax is gewoon 10x beter dan de fiber.

1 reactie

rvk01
Slimmerik
  • June 24, 2026

traceroutes zeggen helemaal niets hierbij. De gameservers reageren gewoon zelden (99,9% niet) op ICMP (ping) berichten en daardoor zal je traceroute ook niet doorlopen. Het enige waar je traceroute soms voor kunt gebruiken is het pad naar de server en of reactietijden naar het eindpunt ophogen... maar de tussenhops zelf hoeven individueel niet te luisteren naar ICMP berichten (die mogen b.v. i.v.m. ratelimiting ook 50-100% van de ICMP antwoorden droppen). Dat wil niet betekenen dat je verkeer niet aankomt op de doelserver (eindhop).

Soms kun je i.p.v. met ICMP ook testen met TCP om een traceroute te voltooien (in ieder geval op Linux).

Welke server heb je gebruikt voor je traceroute en hoe ben je daaraan gekomen? En wat is de ping naar die server (waarschijnlijk 100% loss omdat ie ook niet naar ICMP luistert). Het kan uiteraard wel zijn dat de peering naar die server niet optimaal is (dat kan voorkomen) maar dan hebben ze wel je doelserver nodig om dat uit te zoeken. Het heeft in ieder geval niets te maken met die *.fixed.kpn.net.

Â