Ik heb ook exact hetzelfde probleem. T-Mobile thuis glasvezel. Net overgestapt van KPN maar de Ping is van 2-3ms naar 12ms gegaan. Regio Hilversum. Je mag mij ook gebruiken als testcase. Alle apparaten zijn net geïnstalleerd door Guidion.

@Niels de Jong 

Dit draadje begint al behoorlijk lang te worden en ik heb derhalve niet alles doorgelezen maar als ik naar je laatste trace kijk lijkt de latency al te ontstaan tussen je router en de eerste hop van t-mobile. Althans, als ik deze vergelijk met een trace vanaf mijn router naar 8.8.8.8.

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1  1-128-178-143.ftth.glasoperator.nl (143.178.128.1)  1.679 ms  1.671 ms  1.652 ms
 2  10.10.80.102 (10.10.80.102)  5.092 ms  5.155 ms  5.051 ms
 3  10.226.4.50 (10.226.4.50)  4.783 ms  4.892 ms  4.817 ms
 4  10.10.80.149 (10.10.80.149)  4.146 ms  4.600 ms  4.371 ms
 5  72.14.209.42 (72.14.209.42)  4.516 ms  4.733 ms  4.402 ms
 6  *  *  *
 7  dns.google (8.8.8.8)  3.932 ms  4.128 ms  216.239.49.12 (216.239.49.12)  5.622 ms

Let wel dat ik een trace doe vanaf m’n router en niet vanaf een client via m’n router. Met dit laatste in acht nemend lijkt er ofwel iets mis te zijn met de link tussen de eerste hop van t-mobile en jouw router, ofwel die zyxel voegt de nodige latency toe. Nu ben ik niet zo van m’n handjes in het vuur steken maar ik gok dat het laatste het geval is.

@Marty_J

Het klopt inderdaad dat de meeste latency ontstaat tussen de Zyxel en de eerstvolgende hop van T-Mobile (OLT). Dit wordt echter niet veroorzaakt door de Zyxel. Als ik mijn eigen router direct op het ONT aansluit dan is het resultaat hetzelfde. En aan het ONT ligt het ook niet want dit is dezelfde als ik bij KPN had waar ik strak 1ms latency had.

Ik zie dat jouw latency naar de eerstvolgende hop (OLT) veel lager is. Als jij je IP traceert via een ip locator, hoeveel afstand zit er dan tussen de aangegeven locatie en jouw daadwerkelijke locatie? Ik kwam eerst uit in Eindhoven en sinds mijn IP veranderd is kom ik uit in Rotterdam. Dit is toch zeker 100km van mij vandaan (zonder in achtneming van hoe de kabels daadwerkelijk lopen, en de onnauwkeurigheid van deze tools). 

Ik vermoed dat de fysieke afstand tussen mijn router/ONT en de eerste hop (OLT) gewoon te groot is.

Dit is ook maar een aanname maar ik denk dat mijn ping naar bijv. 8.8.8.8 onnodig lang en vaak gerouteerd wordt door T-Mobile.

Zie ook uitleg ONT en OLT: https://us.hitrontech.com/learn/what-is-the-difference-between-olt-and-ont/?cn-reloaded=1

Hier opeens uit het niets een verbetering sinds vandaag op XGS-PON icm de Zyxel-T54, voorheen 15ms op WiFi en 11ms bedraad, sinds vandaag 10ms op WiFi en 7ms bedraad.

@Waqqas doe mij ook maar een T54 om te testen, maar dat zal wel weer niet kunnen.

Hier overigens nog geen verbetering en vandaag ook bijzonder veel packetloss.

@Boris al een update?

Hi @Niels de Jong ,

Thanks voor je update en de duidelijke informatie die je al hebt kunnen geven. Ik heb deze informatie samen met onze technische dienst bekeken en omdat we ook een demping zien op de ONT die is aangesloten, gepaard met de latency en packet loss, is er gekozen om een monteur langs te laten komen om de verbinding te bekijken. Het netwerk en route geven daarbij niet direct een ander signaal voor. De monteur is aangestuurd om de demping van de ONT te controleren en daarbij eventueel een ruil in te verwezenlijken. Om deze afspraak te maken, zal je een SMS/e-mail ontvangen om digitaal een afspraak te maken. Wil je ons laten weten hoe het bezoek is verlopen? We horen het graag van je. 

Hi @Jason ,

Ik heb sinds vorige week helaas niets meer vernomen. Kan jij zien of de Guidion monteur de bon goed heeft doorgezet naar KPN?

Hoi @Niels de Jong, zo te zien heeft Guidion het correct doorgezet, maar heeft de operationele afdeling het ticket gesloten omdat de meetgegevens ontbraken. Ik ga dit direct weer heropenen en met spoed onder de aandacht brengen. Geen idee waarom de meetgegevens zoals traceroutes en packet loss niet meegestuurd zijn - sorry voor deze fout: de info staat per slot van rekening in dit topic. 

@Niels de Jong UPDATE: na overleg met de specialisten, hebben we het ticket aangevuld met de juiste info en meteen doorgestuurd. KPN zal het spoedig oppakken en langskomen.

@Jason 

Bedankt voor je update!

@Niels de Jong Netbeheer heeft het onderzoek gesloten met afmelding vanuit KPN, ik zal de informatie zo goed mogelijk parafraseren zodat je inzicht hebt in het hoe en waarom:

Het ping probleem kan niets aan gedaan worden, de waarden die je ervaart, zijn prima in orde. Wat bij een vorige provider gehaald is, hebben wij jammer genoeg geen invloed op. Wat bij T-Mobile gehaald wordt, is naar onze maatstaven prima in orde. Mocht je nog erg veel hinder ondervinden van packet loss, dan ontvangen wij graag meer uitgebreide data zodat we dit kunnen onderzoeken. Het kan natuurlijk best zijn dat verkeer via Eindhoven gaat zoals je aangeeft, hier hebben wij echter geen directe invloed op.

Indien je nog packetloss-info kunt doorzetten, heel graag, dan pakken Boris en ik het weer verder op voor je. Wij zien net zo graag als jij dat hier toch een oplossing voor komt, ook al wordt aangegeven dat dit dan niet direct via ons kan gaan - er zijn mijns inziens altijd oplossingen, maar dan moeten we het creatiever aanpakken.

Hi @Jason ,

Helaas, maar dat had ik al verwacht. Wat betreft de packetloss lever ik graag nog wat info aan. Ik ben echter op vakantie tot dinsdag dus real time info kan ik niet aanleveren. Alleen monitoring over het verleden kan ik op afstand inzien:

Wat opvalt is dat de packetloss alleen optreedt op bepaalde momenten van de dag. Dit is overigens erger geworden na het wisselen van het ONT.

@Jason @Boris 

Packetloss is nu de hele dag door. Verbinding is zelfs 2x weggevallen voor een minuut.

Hi @Niels de Jong,

Thanks voor je terugkoppeling en duidelijke weergave van de packetloss. Ik heb deze direct bij een collega van de technische dienst neergelegd en zal je op de hoogte houden van het onderzoek wat door deze collega wordt gestart. We houden contact!

Hi @Boris,

Ik heb de Zyxel weer uit mijn netwerk gehaald en ik gebruik nu een Fortigate als router direct op het ONT. Ik heb hier een VLAN interface met VLAN 300 op aangemaakt voor internet en dit lijkt nu stukken beter te werken. Ik houd even in de gaten of er nog steeds sprake is van packetloss en laat het je weten.

Hoi @Niels de Jong,

Thanks voor je update! Ook vanaf mijn kant; ik heb de verbinding samen met met onze technische dienst voor je gemonitord en zie, eigenlijk zoals verwacht, weinig van de packet loss in terug. Ik ben wel erg benieuwd hoe de situatie is wanneer je nu weer je eigen modem hebt aangesloten.

Storing is inmiddels opgelost.

Zie hier. Er is geen invloed van andere devices op het netwerk, alleen mijn pc, direct verbonden, is aangesloten op de router.

Met wifi, kan bij het niet gebruiken van QoS, het uitschakelen van QoS(of het correct configureren voor prioriteiten) helpen.

Ook accepteren dat wifi nu eenmaal gevoeliger is voor invloeden van buitenaf en altijd zal onderdoen aan kabel, als bekabelt stabiel blijft.

Ook de WIFI functionaliteit van de modem verplaatsen naar een dedicated-accespoint kan positief werken, als er gewerkt word.

Ik ben mij bewust van het feit dat er meer latency op WiFi is. Daar gaat het mij ook niet om. Het is meer als vergelijking bedoelt dat dit zowel bekabeld als met WiFi hoger is dan voorheen.

@Niels de Jong ik had niet goed gelezen, dat het om beide ging. 

Maar de grootste teller lijkt hem in je afbeelding tussen je device en modem te liggen (<1ms 9ms). 

QoS kan, hoe pakketjes(hoe vaak ze over de kop gaan/bijgehouden worden) vereenvoudigen door het uit te zetten. Mogelijk een kleine tune om je modem te ontlasten.

Hier zelf positieve resultaten mee gehaald met speedtests. Meten is weten.

Hi @Niels de Jong ,

Ik ben benieuwd waarom je de tracert specifiek naar de DNS server van Google laat lopen. Is dat de ingestelde DHCP setting op het moment? Wanneer je de tracert bijvoorbeeld laat lopen naar een ander ip, krijg je daarbij nog dezelfde resultaten? 

@Boris je kunt in de tracert lezen dat de stappen tussen device en modem tijd kost(wat @Niels de Jong beweert sneller te hebben gehad). Dit is inrelevant met de eindbestemming, want als je eindbestemming veranderd veranderd de route tussen device en modem niet. Enkel veranderd nadat de tracert je eigen T-Mobile IP verlaat(je modem/T-Mobile verlaat).

Google DNS is best logisch, gezien Google snelle infrastructuur heeft en veel mensen het IP van Google DNS makkelijk kunnen onthouden.

Tracert vind plaats nadat de DNS geresolved is. Dus welke instellingen in de modem voor DNS zijn, zouden niet uit moeten maken(meende ik).

@Niels de Jong beweert dat zijn modem sneller functioneerde en vraagt hier tips hoe dit in ms sneller te kunnen laten 'modemmen' als ik goed begrijp.

Nee. De eerste hop die je in de tracert ziet is gelijk mijn modem. Oftewel <1ms tussen mijn pc en modem. De hop daarna is 9/10ms van mijn modem naar de Optical Line Terminal (OLT) van T-Mobile die dus schijnbaar in omgeving Eindhoven zit. Hier zit de grootste vertraging in. 

Tevens is QoS bij mij standaard uitgeschakeld.