Traag ladende sites in de avond; hoge packet loss

Wij hebben hier ook last van, kan iemand ook naar het volgende topic kijken???

@LvN23  Welcome to the club.t

Zelfde probleem bij ons. Odido schuift het de hele tijd op modem. Of ze weten het gewoon niet.
Mijn vermoeden is dat hun netwerk het niet aankan. Ik heb helaas nog geen oplossingen gezien in dit forum… :-(

Ik heb het ook af en toe overdag, maar 's avonds is het extreem, en ook elke avond. Soms meer storing, soms wat minder.

Hi @LvN23, goed dat je hiervoor aan de bel trekt.

We zien inderdaad dat meerdere klanten op het KPN Netwerk hier last van hebben. Zou je voor mij het Zyxel modem willen aansluiten en de testen kunnen doen en screenshots kunnen delen? Laat het Zyxel modem een tijdje aangesloten, dan kan ik een lijnmeting voor je doen waarop te zien is dat het Zyxel modem aangesloten is. Alvast bedankt! 

Hoi Tommie,

De laatste dagen druk geweest in de avond dus niet kunnen checken; vanavond lijkt het eigenlijk al de hele tijd stabiel (zowel met als zonder Zyxel getest). Zodra ik weer problemen zie zal ik de Zyxel er weer tussen zetten en een seintje geven.

Status nu (UK endpoint):

Zijn er toevallig wat zaken in het Odido-netwerk gewijzigd dat ik er nu opeens geen last meer van heb? Dank

Hey @LvN23, ik weet niet of er iets gewijzigd is maar dit ziet er een stuk beter uit. Houd het inderdaad in de gaten, hopelijk blijft het zo! 

Ok dat was van korte duur, vanavond is het weer raak. Zowel met eigen router als met jullie Zyxel.

Bekabeld getest:

Server in Georgia:

Server in UK:
 

Wanneer dit optreedt gaat het browsen ook traag. Het is wel minder frequent dan het eerder was komt dus nog steeds voor. Ik heb de Zyxel teruggeplaatst en m'n eigen setup er met dubbel nat erachter gezet zodat jullie een lijnmeting kunnen doen. Zouden jullie die dan wel zeg omstreeks 20:30 kunnen schedulen? Zoals aangegeven heb ik overdag nergens last van.

Gezien de vele meldingen hier tav Odido icm KPN WBA hoop ik dat het capaciteitsprobleem snel gevonden wordt. Ik las iets over 30 november in een andere topic, is die datum voor mij ook relevant?

Gisteren en vandaag ook weer last van; rond 20:30 is het vaak eenvoudig te constateren.

gisteren:

vandaag:
 

Hey @LvN23, 30 november gaat over een specifieke wijkcentrale. Het lijkt me sterk dat dit de dichtsbijzijnde servers zijn. Zou je een twee commands willen uitvoeren in CMD en de pingresults hier met mij willen delen? Alvast bedankt!

Open CMD en typ: Ping -n 50 1.1.1.1 & Ping -n 50 8.8.8.8

Hey Tommie,

ping -n 50 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=6ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=6ms TTL=59
Reply from 8.8.8.8: bytes=32 time=6ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=7ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=10ms TTL=59
Reply from 8.8.8.8: bytes=32 time=8ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59
Reply from 8.8.8.8: bytes=32 time=9ms TTL=59

Ping statistics for 8.8.8.8:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 10ms, Average = 8ms

ping -n 50 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=7ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=7ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=7ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=6ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=12ms TTL=58
Reply from 1.1.1.1: bytes=32 time=27ms TTL=58
Reply from 1.1.1.1: bytes=32 time=10ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=7ms TTL=58
Reply from 1.1.1.1: bytes=32 time=7ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=9ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=8ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58

Ping statistics for 1.1.1.1:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 27ms, Average = 9ms

Daar lijkt weinig mis mee hoewel 27ms voor glasvezel eigenlijk niet zou moeten mogen.

Op hetzelfde moment browsen is echter super traag, zie hier wat voorbeeldjes van een "inprivate” edge zonder plugins, met netwerk tab open en "disable cache” geselecteerd:

nu.nl (na meer dan 60 secs nog niet volledige geladen):

community.odido.nl (na ~32 secs geladen):

Zie bijv request naar 'solvedTopics’ dat meer dan 14 secs duurt.

Ik heb ook nog een 'ping’ geprobeerd met wat grotere buffer size (dus grotere pakketjes), daar lijkt er wel vertraging waarneembaar:

ping -n 10 -l 1024 1.1.1.1

Pinging 1.1.1.1 with 1024 bytes of data:
Reply from 1.1.1.1: bytes=1024 time=7ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=8ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=9ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=10ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=9ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=10ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=1610ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=589ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=8ms TTL=58
Reply from 1.1.1.1: bytes=1024 time=10ms TTL=58

Ping statistics for 1.1.1.1:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 7ms, Maximum = 1610ms, Average = 227ms

Zoals eerder aangegeven

• Bekabeld getest. Het is echter ook merkbaar op bijvoorbeeld tablet of telefoon, dus niet device specifiek.
• Zyxel is aangesloten zodat jullie lijnmeting kunnen doen. Zowel met  de Zyxel als met (uitsluitend) mijn eigen router ervaar ik dezelfde problemen.
• Dit speelt _uitsluitend_ in de avond, dus zeg 19u -  23u
• Ik heb hiervoor een jaar bij KPN gezeten (zelfde glasvezel, zelfde netwerkspullen/kabels, zelfde ONT (Genexis XGS-PON) en daar had ik _nooit_ problemen).

Hopelijk helpt dit de oorzaak te vinden

Bespaar je de moeite en zeg zo snel als mogelijk op. Hier (net als vele anderen) exact dezelfde soort problemen gehad. Odido laat je door twintig hoepels springen met pingtests, modem reset etc. Dat gaat allemaal geen zier helpen; het zit niet bij jou thuis, maar in het netwerk.

Zelf na veel gezeik overgestapt naar KPN en sindsdien strakke pingtijden ook in de avond. Zelfde XGS-PON, zelfde (eigen) router, alles gelijk. Dus het ligt echt niet aan je spullen thuis.

Succes!

Hey @LvN23, bedankt voor alle testen. Ik heb alle informatie debundeld en doorgezet in een ticket. Hopelijk is het voldoende voor de techneuten om het te kunnen onderzoeken en hopelijk ook oplossen. Wordt vervolgd! 

Hey Tommie,

Dank voor het doorzetten van het ticket naar de techneuten. Ik heb afgelopen dinsdag (28/11) een mail gekregen dat er binnen 3 werkdagen terugkoppeling zou komen:

Helaas niks vernomen, zou jij kunnen kijken hoe het ermee staat?

De situatie is onveranderd, zo niet slechter geworden. Er zijn momenten in de avond dat er haast niet te browsen valt, alles is traag en dien vaak "te F5en” om een pagina geheel geladen te krijgen.

Edit:

Hier nog een paar testjes ter onderbouwing:

• Recente test van packetlosstest.com met UK endpoint:

• Ik heb smokeping als container op m'n (bekabelde) NAS gezet, deze pingt nu 8.8.8.8
  • Laatste 3 uur

    

  • Laatste 30 uur

    

     

Hopelijk helpt dit het probleem op te lossen. Alvast bedankt!

Hey @LvN23, ik ben direct voor je gaan kijken maar het ticket staat nog open. Ik heb de nieuwe screenshot toegevoegd! 

Beste @Tommie van Odido ,

Kreeg zojuist onderstaande mail:

Met alle info die ik in dit draadje al gegeven heb lijkt me dit niet de meest logische keus, zou je voor mij kunnen ophelderen waarom Guidion nu ingeschakeld wordt? Zijn er technische details uit het onderzoek die hier aanleiding toe geven? Zo ja welke? Wat wordt/is de specifieke opdracht van/voor Guidion?

Inmiddels mail van Guidio gehad en afspraak met guidion gepland, voor transparantie hier de opdracht voor Guidion:

Hier zelf aan toegevoegd:

Je hebt maar 255 tekens om wat toe te voegen...

Nu maar hopen dat de "demping die niet in order is” de oorzaak is.

Hey @LvN23, bedankt voor de update. Kan je me op de hoogte houden? Ik ben erg benieuwd! 

Guidion monteur vanochtend langsgeweest, "u had wifi problemen toch?” was het bij binnenkomst. We zijn toen samen door deze post gegaan en hij heeft een aantal zaken onderzocht (modem, ONT inclusief herregistratie (al had ik dat hier op het forum al eerder aangevraagd), speedtest). Zijn conclusie was dat het niet aan het klantdomein ligt  en dit gaat hij ook zo communiceren. Doordat de problemen zich voornamelijk ‘s avonds voordoen kon volgens hem de demping kan daar niet de oorzaak van zijn.

De overigens erg vriendelijk Guidion medewerker gaat dit nu doorgeven aan KPN zodat zij een lijnmeting kunnen doen. Paar vragen:

• Is dit niet al gedaan gezien de dempingwaarde opmerking etc?
• Is dit de correcte vervolgstap?
• Hij gaf aan dat  KPN lijnmeting kan worden uitgevoerd ook als ik alleen mijn eigen apparatuur aangesloten heb, niet perse de Zxyel nodig dus. Is dit correct of kan ik deze beter aangesloten laten.
• Op welke termijn kan zo'n lijnmeting gedaan worden en wanneer hoor ik uitslag? Het begint zo langzamerhand best vervelend te worden in de avond (understatement)…

Bedankt!

Hey @LvN23, bedankt voor de update.

Ik zie het ticket nog niet terug van Guidion, hier kan vaak wat tijd overheen gaan en dan zetten ze alles in 1x door.  Om antwoord te geven op je vragen:

• Is dit niet al gedaan gezien de dempingwaarde opmerking etc? KPN NetwerkNL kan wat meer zien dan wij dat kunnen. Dus hopelijk kunnen ze de oorzaak dan ook vinden.
• Is dit de correcte vervolgstap? Als de monteur alles goed doorzet zeker!
• Hij gaf aan dat  KPN lijnmeting kan worden uitgevoerd ook als ik alleen mijn eigen apparatuur aangesloten heb, niet perse de Zxyel nodig dus. Is dit correct of kan ik deze beter aangesloten laten. KPN NetwerkNL kan dat doen maar ik weet niet of het eerst langs onze Back Office nog moet voordat het naar KPN NetwerkNL kan. Voor nu, laat het nog meer staan alsjeblieft.
• Op welke termijn kan zo'n lijnmeting gedaan worden en wanneer hoor ik uitslag? Het begint zo langzamerhand best vervelend te worden in de avond (understatement) Dit is een lastige omdat het een lastig probleem is. Het zal goed onderzocht moeten worden maar dit kan lang duren.

Dank Tommie, ik zal de zyxel aangesloten laten.

Hierbij de werkbon van Guidion:

Onderlijning door mij aangebracht. Het tijdswindow waarin de problemen zich voordoen lijkt op een kleine miscommunicatie, in werkelijkheid is dat meer "de avonduren” zeg 18-23u. Hopelijk kan KPN Netwerk snel aan de slag, houd me svp op de hoogte. Dank!

Ontving vandaag tegen het middaguur onderstaande mail:

Tot op heden nog geen SMS en/of mail met link ontvangen helaas. Duurt dat altijd een poosje of gaat er wat mis?

Hi @LvN23, meestal duurt het een dag of drie tot KPN NetwerkNL het opgepakt heeft. Hopelijk kunnen zij dit eindelijk voor je oplossen! 

Hoi Tommie, we zijn inmiddels 3 werkdagen verder en waar ik al bang voor was is werkelijkheid: ik heb nog steeds geen mail en/of sms binnen om uberhaupt een afspraak te maken. Zou jij kunnen kijken waar het mis gaat...

@LvN23 Wegens de drukte, kan het soms langer duren. Ik ga er vanuit dat KPN begin volgende week contact met je opneemt. Mocht je niks horen, trek dan hier aan de bel!

Hoi! Zou iemand een update kunnen geven van het verloop van het huidige onderzoek? Ik heb zelf nog niks vernomen (dus ook geen mail of sms). Hartelijk dank.

Hier nog een paar testen van momenten waarop het niet vooruit te branden was:

 

Hey @LvN23, KPN NetwerkNL heeft het ticket niet willen oppakken omdat het ONT nog niet vervangen is. Daarom hebben we zojuist een nieuw ONT opgestuurd en Guidion aangestuurd om dit te installeren en te testen. Je ontvangt hier spoedig een bericht over om een afspraak in te plannen met de monteur.