Ik heb al geruime tijd last van lag spikes, traag laden van paginas en moeite met bufferen bij streamen.
Als ik ping testen uitvoer dan zijn er veel en enorme hoge spikes te zien met uitzonderingen van enkele secondes. Zie bijlage. Dit probleem doet zich alleen voor met bekabeld internet, op de wifi is dit probleem niet aan de orde. Ik heb meerdere poorten van de T-56 geprobeerd en allemaal zelfde probleem.
Ik heb al gelezen dat het waarschijnlijk door het type modem komt. Mijn vraag is daarom ook aan odido of zij mij kan helpen aan mogelijk een andere modem, of een andere oplossing.
Alvast dank voor alle reacties!
Beste antwoord door Cheyenne van Odido
Hi @Tim12071986, dank! Goed dat je dit deelt, dat is niet prettig. Ik zou het modem kunnen swappen naar de T54, maar liever ontvang ik een volledige speed en pingtest met een laptop/pc bedraad volgens onze norm zodat ik een onderzoek kan starten:
Volg alle stappen alsjeblieft zorgvuldig, graag de screenshots in het topic delen in plaats van naar onze e-mail. Een aanvraag met ontbrekende stappen kunnen we niet in behandeling nemen.
Pingtest
De computer of laptop dient bekabeld aangesloten te zijn op het modem, een speedtest van een tv of spelcomputer kunnen wij niet gebruiken.
Zorg ervoor dat alleen de computer of laptop aangesloten is op het modem. Koppel alle andere apparaten los.
Specificaties van het gebruikte modem/router tijdens de problemen en uitvoeren van de test (In het geval van eigen modem)?:
Speelt het probleem de hele dag door of alleen op bepaalde momenten van de dag?:
Is het apparaat (de betreffende client) aangesloten op de 2.5 Gbit/s Lan poort of een 1 Gbit/s Lan poort?:
Deel de resultaten van een ping test naar 8.8.8.8, alleen een screenshot van de Ping statistics is genoeg.
Ping 8.8.8.8
Windows command prompt; ping -n 1000 8.8.8.8
Linux/Mac terminal; ping -c 1000 8.8.8.8
Deel de resultaten van een ping naar de first hop, dit is het tweede adres wat je ziet in een traceroute. Alleen een screenshot van de Ping statistics is genoeg.
Vind de first hop (de tweede regel, geel omlijnd op de screenshot)
Hi @Tim12071986, dank! Goed dat je dit deelt, dat is niet prettig. Ik zou het modem kunnen swappen naar de T54, maar liever ontvang ik een volledige speed en pingtest met een laptop/pc bedraad volgens onze norm zodat ik een onderzoek kan starten:
Volg alle stappen alsjeblieft zorgvuldig, graag de screenshots in het topic delen in plaats van naar onze e-mail. Een aanvraag met ontbrekende stappen kunnen we niet in behandeling nemen.
Pingtest
De computer of laptop dient bekabeld aangesloten te zijn op het modem, een speedtest van een tv of spelcomputer kunnen wij niet gebruiken.
Zorg ervoor dat alleen de computer of laptop aangesloten is op het modem. Koppel alle andere apparaten los.
Specificaties van het gebruikte modem/router tijdens de problemen en uitvoeren van de test (In het geval van eigen modem)?:
Speelt het probleem de hele dag door of alleen op bepaalde momenten van de dag?:
Is het apparaat (de betreffende client) aangesloten op de 2.5 Gbit/s Lan poort of een 1 Gbit/s Lan poort?:
Deel de resultaten van een ping test naar 8.8.8.8, alleen een screenshot van de Ping statistics is genoeg.
Ping 8.8.8.8
Windows command prompt; ping -n 1000 8.8.8.8
Linux/Mac terminal; ping -c 1000 8.8.8.8
Deel de resultaten van een ping naar de first hop, dit is het tweede adres wat je ziet in een traceroute. Alleen een screenshot van de Ping statistics is genoeg.
Vind de first hop (de tweede regel, geel omlijnd op de screenshot)
Problemen komen en gaat zo blijkt uit analyse van de laatste weken. Het ene moment wel, andere moment nergens last van. Er zijn geen andere apparaten aangesloten op het netwerk. Pingen naar 8.8.8.8 ziet er goed uit, maar ping tests op andere websites dus niet. Vandaag ook tijdens een online race een connection loss gehad en helaas de race niet kunnen uitrijden.
Ik ben het zat en zal op korte termijn overstappen naar een andere provider waar ik een andere modem zal ontvangen die hopelijk wat minder last heeft van lag spikes/bufferbloat en trage respons 🤔
Als ik ping testen uitvoer dan zijn er veel en enorme hoge spikes te zien met uitzonderingen van enkele secondes. Zie bijlage. Dit probleem doet zich alleen voor met bekabeld internet, op de wifi is dit probleem niet aan de orde.
Als het probleem alleen bij bekabelde verbindingen voorkomt, en niet bij WiFi. Dikke kans dat je slechte kabels gebruikt van inferieure goedkope “Chinese” makelij.
Bijv. kabels waarbij de kerndraden bestaan uit “aluminium” met een dun laagje koper er overheen.
Bedankt voor de tip, ik heb 2 van de 3 wand aansluitingen zelf bekabeld met kwaliteit kabels. De kabel waar ik op werk was al getrokken vanuit de bouw (nieuwbouw 2024). Zal eens kijken of dit mogelijk van inferieure kwaliteit is. Zou me trouwens niets verbazen en zou tevens teleurstellend zijn vanuit de aannemer. Ik kom hier op terug.
Zal tevens kijken als wanneer ik problemen ervaar de andere wand aansluitingen wel goed functioneren en hiermee dus op een andere manier bekabeling met elkaar vergelijken.
Zou er ondanks het gebruik van de juiste kabel, althans dan neem ik aan, toch iets mis kunnen zijn met de bekabeling?
Zeker. Bijv. door het gebruik van niet de juiste type stekkertjes. Je hebt kabels met één stugge kerndraad, en met iets van zeven dunnere kerndraadjes per ader bij “soepele” kabel.
Voor één stugge kerndraad heb je stekkertjes nodig die “per ader” een vorkje om de kerndraad klemt. Voor soepel samengestelde draad, stekkertjes “als mesjes” door de kern van de ader heen gaan.
Er zijn ook combinaties mogelijk, stekkertjes die voor beide typen gebruikt kunnen worden.
Als stekkertjes niet goed aangeknepen zijn, kan het contact niet optimaal zijn. Zeker als de kunststof ommanteling van kabel niet op de juiste lengte was verwijderd. De klemming van de “trekontlasting” van de “mantel” van de kabel, buiten het stekkertje valt. En de trekontlasting puur op de kerndraadjes met die “vorkjes of mesjes” in het stekkertje aankomt. Dan kan het snel zijn gedaan met een goede verbinding.
Extreem voorbeeld (wat echt gewoon voorkomt bij gebruikers): 🤣
Stekkertjes (en poortjes) kunnen vervuilen / corroderen. Door stekkertjes een paar keer uit- en in een poortje te schuiven, schrapen de contacten langs elkaar. En kan een verminderd contact weer “vol contact betekenen”. Eventueel van stekkertjes de langwerpige contact “streepjes” en poortjes met een wattenstaafje schoonmaken, waarvan de tip is bevochtigd met “contactspray” waardoor contacten van mogelijk een microscopisch dunne corrosie laag / aangekoekt vuil wordt ontdaan.
Doormeten van kabels. De enig juiste wijze in controle of kabels / connecties voldoen is doormeten. LET OP !! Van die goedkope kabeltesters van pakweg € 10,- met van die ledlampjes voldoen NIET. Zoals vergelijkbaar met deze:
Die meten alleen als draadjes verkeerd zijn aangesloten, of er een onderbreking is van draadjes.
Maar die meten NIET de demping van het signaal (teveel verlies van het signaal → CCA ), en of er interferentie is (“overspraak”), tussen de draadkernen onderling, door te weinig “twisting”, per draadpaar van de kerndraden.
Een beetje fatsoenlijke kabeltester die dat meet kost al snel een aantal honderden Euro's. (“Fluke” zelfs meer dan € 1000 - € 1500). Dat is niet haalbaar voor een thuisgebruiker.
Maar kabel test mogelijkheden / utility van een “managed switch” voldoen ook prima. (Er zijn zelfs gebruikers die de aanschaf van zo'n managed switch al de moetje waard vonden, alleen al om de mogelijkheden om een “goede test” te kunnen uitvoeren.
Zoals beschreven / meer uitgelegd in mijn laatste verwijzing van mijn vorige reactie.
Bijvoorbeeld een fout gevonden op “0 meter” betekent doorgaans een slecht stekkertje.
Zelf kom ik zeer regelmatig kabels tegen die NIET VOLDOEN. (Ik schat zeker wel bij 20-25% van alle kabels die bij apparaten zelf worden bijgesloten. Als het al niet meer is). Bedenk verder ook dat statistisch gezien meer “foute” kabel wordt verkocht door kabelboeren (CCA), dan goede kwaliteit kabels. Want de meeste gebruikers zijn nou eenmaal “zuunig”.
Maar houd ook in de gaten de interferentie “in en om je huis”. Vanuit diezelfde verwijzing, meer naar onderen en verder in die reactie:
Aanvulling (2023):
Andere bronnen van interferentie die vaak over het hoofd worden gezien en oorzaak kunnen zijn van onbegrepen storingen:
Tim12071986 schreef:
Het gekke is dat mijn verbinding de ene keer super goed is (6ms pings en super snelle respons van websites). Gisteravond daarintegen, ping spikes tot wel 8000ms en websites die soms pas na bijna 10seconden laden.
Ofwel ”onbegrepen storingen”. Situatie kan net “op een kantelpunt” zitten dat connecties net wel voldoen, of juist de andere kant opslaat, door temperatuur (krimpen / uitzetten), of vochtigheidsgraad.
Of misschien juist door het verplaatsen van een stekkerdoos met stroom adapters bij het stofzuigen. Die erna vlak langs (niet afgeschermde) UTP kabel aanschuift.
De meest storingen zijn onder te brengen in de hiervoor beschreven problematiek. 🤓
Maar uiteraard kunnen er ook andere oorzaken aan ten grondslag liggen bij storingen. Een gedegen analyse is aan te bevelen / gewenst. Voordat men conclusies trekt. Echter bij “géén probleem” bij WiFi, maar wel bij bekabelde verbindingen. Ligt het “voor de hand” om eerst eens naar die kabels en kabelverbindingen te kijken. 😎
Dit zijn mijn bevindingen tijdens een onderzoek van een uur waarin er constant zeer hoge lag spikes waren ( getest met https://www.meter.net/ping-test/) en trage respons op diverse websites op mijn PC:
- andere WCD geprobeerd in huis met werk laptop (vpn), geen probleem
- kabel van WCD naar pc vervangen, zelfde probleem
- werk laptop aangesloten op aansluiting van PC, geen probleem!
Volgens mij is de bekabeling dus uitgesloten en zit het probleem mogelijk in de pc zelf!
Want waarom heb ik geen heb ik op de laptop geen problemen en op de pc wel, gebruikmakend van dezelfde aansluiting op het zelfde moment?
Is het de vpn of is het wat anders?
En waarom meet ik via CMD pings naar Google wel lage respons en tegelijkertijd lagspikes meet via meter.net en ervaar ik trage respons op verschillende websites?
Ik ben geen expert op dit gebied, maar mijn hypothese is dat het mogelijk te maken heeft met een ongelukkig gekozen DNS server op mijn pc. Dus ik heb nu de DNS en alternatieve DNS ingesteld op resp. 8.8.8.8 en 8.8.4.4.
Ook merkte ik op dat bij de netwerkadapter properties ISP IPv4 wel stond aangevinkt en IPv6 niet. Deze heb ik ook maar aangevinkt en ook ingesteld op de DNS servers van Google.
Zouden deze twee aanpassingen het probleem wellicht oplossen? Heb bovenstaande op een ander moment gedaan dus weet niet zeker of dit de oplossing is, dat zal de tijd leren..
Maar snijdt dit hout? Of zijn er nog andere oorzaken te bedenken? Want het vreemde blijft wel dat genoemde problemen kunnen komen en gaan..
- andere WCD geprobeerd in huis met werk laptop (vpn), geen probleem
- kabel van WCD naar pc vervangen, zelfde probleem
Kwartje moest even vallen, met wat je bedoelde met “WCD”, en van daaruit de situatie. Maar als Wand-Contact-Doos van je ethernet structuur in je huis, “kan ik het plaatsen”. 😃
Tim12071986 schreef:
- werk laptop aangesloten op aansluiting van PC, geen probleem!
Volgens mij is de bekabeling dus uitgesloten en zit het probleem mogelijk in de pc zelf!
Als je met een werk laptop geen probleem hebt, en met een PC WEL. Zou daar ook een probleem in kunnen zitten ?
Heb hier een oude laptop, waarvan de accu zo slecht is, dat “ondanks” opgeladen, ik absoluut de power-adapter in mijn laptop moet steken om nog een “beetje” redelijke interconnectie te hebben.
Een 2.5 Gb naar ethernet adapter trekt net teveel vermogen, en valt dan uit. (Led-lampje van de connectie gaat uit). Een andere 1 Gb adapter, houdt het beter uit. Andere “nieuwe” laptop hier, “vliegt”.
VPN-verbinding volgt wellicht een andere route via internet, met andere internet knooppunten. (Eerst “via via” naar een VPN-punt toe, vandaar weer “via via” verder naar de eindbestemming). Tests naar een website als https://www.meter.net/ping-test/ heb je IMO niet zoveel aan, want je weet niet welke route de afgelegde weg naar die website neemt, en tussenliggende knooppunten voor die spikes kunnen zorgen. (De website mogelijk zelf ook??).
Mogelijk krijg je wat meer inzicht als je een trace tooltje op je PC installeert. Die laat alle tussenliggende knooppunten zien, en die punten waar vertragingen zitten.
Ook merkte ik op dat bij de netwerkadapter properties ISP IPv4 wel stond aangevinkt en IPv6 niet. Deze heb ik ook maar aangevinkt en ook ingesteld op de DNS servers van Google.
Odido werkt op dit moment nog alleen met IPv4. Men zou van plan zijn, IPv6 gedurende dit jaar stapsgewijs (per regio) te implementeren? Als het functioneel is, zou je dat in de eerste plaats al in de router moeten hebben geactiveerd.
Zolang het nog niet wordt ondersteund heeft het niet zoveel zin dat in te schakelen. “Als” het actief is, en op alle niveaus functioneel, kun je dat testen via bijv.
Ik begrijp de opmerking over de oude en nieuwe laptop niet helemaal, maar het punt dat ik wilde maken is dat ik volgens mij inmiddels MOET concluderen dat het aan mijn pc ligt toch? Of de route die mijn internet verbinding vanaf mijn pc maakt.
Waarom zou de laptop anders wèl een stabiele verbinding hebben op het zelfde poort en op het zelfde moment? En waarom levert pingen naar Google/Cloudflare wel een lage respons, maar tegelijkertijd last van mega traag laden van websites en lagspikes op de eerder beschreven ping test website? Lijkt mij dus geen hardware probleem, maar iets in de software en of instellingen van de hardware?
Helaas heb ik te weinig verstand van alle mogelijke oorzaken, maar mijn hypothese is nu dat het in de DNS keuze ligt. Dit heb ik daarom aangepast, wat volgens mij sowieso een goed idee is en geen kwaad kan. Tot nu toe heb ik een snelle en stabiele verbinding, maar zekerheid heb ik nog niet gezien het wisselende karakter van dit probleem.
Als ik weer problemen ervaar zal ik ping plotter eens proberen om te onderzoeken waar de vertragingen zitten, goed idee.
Als ik via mijn telefoon, die aangesloten is op de wifi, IPv6 test/check websites open lijkt het erop dat dit is ingesteld/ondersteund.
Ik begrijp de opmerking over de oude en nieuwe laptop niet helemaal,
Van oude laptops kan accu capaciteit zodanig verslechterd zijn dat de stroombehoefte niet goed meer kan worden bijgehouden. Processen / onderdelen die veel vermogen vragen gaan daar onder lijden. Die worden dan ofwel "terug gedraaid” of in sommige gevallen zelfs helemaal uitgeschakeld. Zoals bijv. in mijn situatie een terugnemende internet snelheid.
Pingen betreft een eenvoudige test met minimale data tot aan de “voordeur” van een web-adres. Maar het zegt niets over de capaciteit “achter” de voordeur. Een website op een server met te weinig capaciteit om “vele honderden of duizenden” bezoekers te verwerken kan alsnog erg traag zijn.
Ik heb je een aantal opties en tools aangereikt, waarmee je meer inzicht kunt krijgen in wat en waar je eventuele bottlenecks kunt tegenkomen. Maak er gebruik van.
Tim12071986 schreef:
Als ik via mijn telefoon, die aangesloten is op de wifi, IPv6 test/check websites open lijkt het erop dat dit is ingesteld/ondersteund.
Van een mobiele telefoon zou je dan wel de “data” moeten uitschakelen. Anders test je wellicht alsnog via het mobiele netwerk, en niet via je vaste internetverbinding. -
Hierbij een update. Vergeet even alles wat ik hierboven heb geschreven, door slechte tming/toeval heb ik denk verkeerde conclusies getrokken.
De situatie is nu alsvolgt, op ALLE bedrade verbindingen van mijn router (dus niet alleen de aansluiting van mijn PC) ondervind ik op willekeurige momenten internet problemen. Het probleem kan er uren niet zijn, en uit het niets voor lange tijd aanhouden en weer weggaan.
De problemen die ik ervaar: mega traag (of niet) laden van webpagina's, lag spikes van enkele secondes (!), package loss en disconnects bij online gamen.
Ik heb inmiddels een aantal metingen verricht met pingplotter en meet hier ook de hoge lag spikes en package loss. Op basis van de resultaten en de ‘common internet problems’ te lezen op de website van pingplotter, trek ik de conclusie dat het probleem toch in de hardware (kabels/modem/router) moet zitten. Omdat ik op alle hops dezelfde lagspikes en package loss meet tegelijkertijd.
Ik heb gemeten naar google, twitter en pingplotter. Vreemd genoeg zie ik bij de meting naar google geen package loss op het ip adres van de modem, maar bij de test naar twitter en pingplotter weer wel.
Hoe moet ik deze resultaten nu interpreteren en wat kan ik, of ODIDO hier aan doen?
Hieronder de resultaten met aan het eind een meting van vandaag waarbij ik geen problemen ervaar.
Het grootste probleem begint al in je eigen thuis netwerk. Dat is de langste horizontale rode balk bovenaan, als variatie in de respons over ruim 1400 pings. (Hoe langzamer, hoe donkerder de kleur van die balkjes en verder naar rechts uitlopen).
Ofwel de traagste respons van alle gemeten tussenpunten. Terwijl dat eigenlijk de kortste balk / snelste tijden zou moeten opleveren. Het is ten slotte slechts een verbinding tussen je PC en de modem/router.
De traagste reactie bij het eerste plaatje van alle gemeten pings = boven 2100 miliseconden Ofwel ruim 2 seconden.
Waar ping pakketjes bovendien al verloren gaan.
Een server ergens onderweg - hop nummer 13, is ook langzaam. Lijkt me de eerste server aan de andere kant van de Oceaan (USA) ?
Er zijn servers / tussenpunten die helemaal niet reageren (géén data - 100% loss). Maar dat is gewoon de uitschakeling van de functie om überhaupt op pings te reageren. Die servers sturen data en andere ping pakketjes wel gewoon door, naar navolgende servers, (en terug) en reageren op het aantal pings (counts) wat je in eerste instantie hebt verstuurd.
Echter heeft je slechte (bekabelde) thuisnetwerk als eerste start / basis een zodanig effect. Dat terugkomende ping reacties van pingplotter zelf niet meer goed worden verwerkt. Vandaar de fel rode balkjes helemaal onderaan. Ofwel werkelijk data-loss.
Dat pings naar PingPlotter zelf in jou situatie het meeste problemen geeft. Is omdat die server in Amerika is gelegen. En in die traagheid reeds bij jezelf thuis er bovenop, de uitlezing tussendoor door servers misschien al is “afgekapt”, om erop te reageren?
Pings naar Google is naar datacenter van Google zelf ergens in Nederland. (En mogelijk in in die test bij jou situatie een “goed” moment tussendoor ??)
Ter vergelijk twee testen die ik hier zelf ook heb gedaan met Pingplotter. Met twee verschillende laptops - zelfde USB naar ethernet adapter, en zelfde kabel. Over een tijdspanne van pakweg 10 minuten. (In de grafische weergave helemaal onderaan wordt niet meer dan 10 minuten weergegeven).
“Traagste” tijd = 130 milliseconden. De gemiddelde ping tijd binnen het thuisnetwerk zelf bedraag 1.4 milliseconden.
Andere laptop: “Traagste” tijd = 150 milliseconden. De gemiddelde ping tijd binnen het thuisnetwerk zelf bedraag nu 2.5 milliseconden
De grafische weergave van connectie (over en weer) met USA lijkt hierbij goed en stabiel. -
Bij een paar servers / HOPs met meer variatie in respons, loopt de telling soms nog net wat achter, op de server / HOP die erna komt, en diens respons al heeft terug gegeven.
Bij één HOP, begon de telling weer opnieuw, waarbij ervoor, géén fouten waren vastgesteld. Bijvoorbeeld bij HOP 8.
In de respons van de Google server zelf, zit weinig variatie in de snelheid. Ofwel een strakke en stabiele respons. (Tussen 8.4 en pakweg 9 milliseconde). -
Ik kan volgen wat je beschrijft, echter vraag ik mij af of het probleem nu in mijn eigen netwerk zit of net daarbuiten. De gemiddelde EN maximale respons tijd naar mijn router/modem (192.168.1.1) is in alle gevallen hooguit 2ms. Echter wel in 2vd3 testen een hoog percentage package loss. Bij de test naar Google zie je bij hop 1 zeer snelle respons zonder package loss, en daarna beginnen de rode balkjes pas.
Hoe moet ik dat nu zien? Als ik kijk naar responstijden lijken de vertragingen te ontstaan na de eerste hop, toch?
De gemiddelde EN maximale respons tijd naar mijn router/modem (192.168.1.1) is in alle gevallen hooguit 2ms. Echter wel in 2vd3 testen een hoog percentage package loss.
Een snelle “gemiddelde” respons is niet waar het echt om gaat, maar om het hoge percentage package loss. Reeds in je eigen netwerk. Waardoor je uitschieters krijgt van boven de 2 seconden respons. Al meteen in je eigen netwerk.
En krijg je “opstoppingen” van data. Bij verbindingen verder weg (met ook weer vertragingen) gaat dat dan teveel parten spelen, zodat zelfs bij het eindpunt de pakketten niet meer worden verwerkt / verloren gaan. (Die fel rode blokjes bij de laatste HOP bij verbindingen verder weg).
Het is dus zaak om te beginnen om je eigen thuisnetwerk alles na te lopen, zoals ik dat in het begin heb aangegeven, in het controleren van bekabeling.
Het heeft natuurlijk weinig zin de “schuld” van problemen bij een ander te leggen. Als je eigen netwerk al niet deugt. Dat moet eerst op orde zijn.
Vergelijk het met de snelweg A2. Van Eindhoven naar Amsterdam. Als je meteen in Eindhoven waar je zou starten al in de file staat staat met 1400 auto's. En kop/staart botsingen hebt, vallen er al meteen auto's uit. Na een redelijke onderbreking (niet veel schade en verzekeringspapieren zijn ingevuld), gaan die auto's weer op weg. En komen ze in Utrecht weer in een file te staan met ook weer kop/staart botsingen. Grote kans dat bij het eindpunt in Amsterdam überhaupt niet alle auto's meer aankomen. Die vanuit Eindhoven wel zijn vertrokken.
Bij een kortere route, alleen van Eindhoven naar Den Bosch. Met ook kop/staart botsingen meteen al bij de start in Eindhoven, maar na een kort oponthoud toch weer op weg. Met als resultaat dat alle 1400 auto's van de “start” daar ook in Den Bosch nog aankomen, is veel groter.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
Wij gebruiken cookies om uw bezoekers ervaring te verbeteren en te personaliseren. Ga je akkoord, of ga je door op de website dan ga je akkoord met ons cookiebeleid. Meer informatie.
We maken gebruik van 3 verschillende soorten cookies. Je kunt kiezen welke cookies je wilt accepteren. We hebben basiscookies nodig om deze site te laten werken, daarom moet je ten minste deze selecteren. Meer informatie.
