Sinds ik begin dit jaar weer terug ben bij T-Mobile heb ik last van allemaal rare problemen.
Het begon al bij de installatie van de monteur, tijdens het verwijderen van het TN kastje van KPN door de monteur was de glasvezel kabel losgeschoten uit de FTU.
Nu ligt het allemaal een beetje op elkaar, volgens de monteur geen probleem (wat ik al raar vond sinds glasvezel erg gevoelig is volgens mij) het was pas een probleem als ik weer van provider zou veranderen volgens hem.
Dit zou ik graag ten eerste gerepareerd willen hebben.
Voorbeeld foto van het internet, deze kabel is losgeschoten en hangt er nu een beetje los in.
Toen der tijd woonde ik op dat moment niet meer thuis (Ouders huis) maar nu ben ik weer terug en lopen we tegen de volgende problemen aan.
Slechte verbinding/routing naar gameservers (Valorant,Counterstrike,Etc.)
Packet loss
Vaak bufferen van Video en trage verbinding
Soms als iemand ons belt en we nemen op valt de verbinding opeens weg en lijkt het modem opnieuw op te starten. (dit is wel al een tijdje niet meer gebeurd)
Ik heb wat onderzoek gedaan en ik kwam het volgende tegen, via het Valorant support werd mij aangeraden om de volgende servers te pingen en tracen en daar kwam de slechte verbinding naar voren. Helaas is het moeilijk om CS.GO servers te pingen omdat deze IP's verborgen zijn maar neem aan dat daar precies dezelfde problemen zijn.
Als u de aansluiting niet vertrouwd plaats hier een paar foto,s.
Dan kunnen we mee kijken.
Ben je wel zeker dat de glasvezel verbindingen schoon zijn.
Dat snap ik. De blauwe kant is dus ook beschadigd geraakt tijdens de installatie van de monteur tijdens het verwijderen van het kpn nt module maar kon daar niet zo snel een foto van vinden op het internet.
Foto plaatsen wordt moeilijk want ik zit er liever niet zelf aan voor dat ik straks helemaal geen internet meer heb.
Hoi @famverkerk
Reparatie van een FTU moet door de netbeheerder gebeuren. In dit geval is dat toevallig ook KPN. Op het KPN forum schreef je al dat je weer naar hen gaat overstappen. Als dat zo is sla je twee vliegen in 1 klap. Indien niet, dan zal er vast wel een proces zijn om de FTU reparatie aan de netbeheerder door te geven.
Dan nog even naar de log die je plaatst. Als de verbinding al een probleem zou zijn, dan verwacht je dat ook de eerste hops in jouw tracert een slechts performance geven. Daar is dus geen sprake van en zou je op basis hiervan niet echt een negatieve conclusie kunnen trekken. Dat er wellicht wat routing in het core netwerk naar deze servers kan worden geoptimaliseerd staat daar los van.
Wat is het resultaat van een bekabelde speedtest?
Hoi @famverkerk
Reparatie van een FTU moet door de netbeheerder gebeuren. In dit geval is dat toevallig ook KPN. Op het KPN forum schreef je al dat je weer naar hen gaat overstappen. Als dat zo is sla je twee vliegen in 1 klap. Indien niet, dan zal er vast wel een proces zijn om de FTU reparatie aan de netbeheerder door te geven.
Dan nog even naar de log die je plaatst. Als de verbinding al een probleem zou zijn, dan verwacht je dat ook de eerste hops in jouw tracert een slechts performance geven. Daar is dus geen sprake van en zou je op basis hiervan niet echt een negatieve conclusie kunnen trekken. Dat er wellicht wat routing in het core netwerk naar deze servers kan worden geoptimaliseerd staat daar los van.
Wat is het resultaat van een bekabelde speedtest?
Dat is een oude post, ik was niet van plan over te stappen mits dit niet opgelost wordt natuurlijk want dit is geen doen.
Met de snelheden zijn geen probleem het is puur de stabiliteit van de verbinding.
Packetloss, slechte routing, buffering van videos.
Waar kan ik terecht voor reparatie aan het FTU dan? Want het is gebeurd tijdens de installatie van een tmobile monteur.
Hoi @famverkerk,
Routing is niet iets waar de glasvezel bij jou wat mee te maken heeft. Packetloss naar een gameserver ook niet. De snapshot die je stuurde laat niets van een lokaal probleem zien. Als de verbinding slecht is zal een speedtest dit ook laten zien. Let wel op dat je test volgens het T-mobile protocol.
Hoi @famverkerk,
Routing is niet iets waar de glasvezel bij jou wat mee te maken heeft. Packetloss naar een gameserver ook niet. De snapshot die je stuurde laat niets van een lokaal probleem zien. Als de verbinding slecht is zal een speedtest dit ook laten zien. Let wel op dat je test volgens het T-mobile protocol.
Ik zal de speedtest uitvoeren via het T-Mobile protocol, maar waar komt die packet loss dan vandaan?
En waarom krijg ik Request time-outs als ik naar de gameserver van riot ping?
"Each row starts with a row number—you can ignore that. Next to each row number is the Round Trip Time (RTT) in milliseconds—the amount of time it took for your packet (network data) to go from your computer to the endpoint of that hop. Each hop is attempted 3 times, which is why there are 3 values for each row.
Some of the rows, however, may look like this:
If you see an asterisk (*) in place of an RTT, then a packet was not returned within the expected timeframe. You might not have to worry if you only see one or two asterisks on a hop, but if you have 3 like in the example above followed by Request timed out, you may have a network issue. Here are a couple of common ones and what you can do:
The destination’s firewall or security is blocking the request. In this case, you'll want to reach out to your ISP for further help on what may be causing the issue (be sure to show them your Tracert log!).
There could be a problem on the network path between you and Riot's servers. This may also be the issue if your log shows increased latency (higher millisecond values) on a middle hop, which then increases steadily for subsequent hops. If that's the case, you might want to contact your ISP for help and show them your Tracert log.”
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Hey @famverkerk, bedankt voor het delen van alle tracerts en pings!
Ik zet dit graag voor je door naar onze techneuten, zij zullen dit dan grondig gaan onderzoeken. Zou je alleen nog 1.1.1.1/8.8.8.8 kunnen pingen zoals @Shilka benoemt? Dan kan ik alle screenshots meesturen in het ticket!
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Bedankt voor je antwoord, ja ook packetloss naar 1.1.1.1 zie screenshot hieronder.
Hey @famverkerk, bedankt voor het delen van alle tracerts en pings!
Ik zet dit graag voor je door naar onze techneuten, zij zullen dit dan grondig gaan onderzoeken. Zou je alleen nog 1.1.1.1/8.8.8.8 kunnen pingen zoals @Shilka benoemt? Dan kan ik alle screenshots meesturen in het ticket!
Zie bericht hierboven bedankt!
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Bedankt voor je antwoord, ja ook packetloss naar 1.1.1.1 zie screenshot hieronder.
Heb je deze testen allemaal bekabeld of via Wifi gedaan? Je hebt al veel packet loss naar het modem toe. Dat zou 0% moeten zijn.
Kun je het ook testen door in Command Prompt/Windows PowerShell eens te doen
ping -n 50 1.1.1.1.
en dan te kijken wat de resultaten zijn.
Als dat ook packetloss aangeeft is er inderdaad iets aan de hand, een echt verloren packet zou namelijk helemaal niet op de eindbestemming aan moeten komen (net zoals je daar bij de gameservers ook last van had) en dus ook op de 1.1.1.1 regel packetloss aan moeten geven.
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Bedankt voor je antwoord, ja ook packetloss naar 1.1.1.1 zie screenshot hieronder.
Heb je deze testen allemaal bekabeld of via Wifi gedaan? Je hebt al veel packet loss naar het modem toe. Dat zou 0% moeten zijn.
Inderdaad. Als er wel bekabeld is aangesloten is er misschien gewoon een slecht contact in de kabel waardoor de pc soms op wifi overgaat? Zou een mogelijke verklaring kunnen zijn.
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Bedankt voor je antwoord, ja ook packetloss naar 1.1.1.1 zie screenshot hieronder.
Heb je deze testen allemaal bekabeld of via Wifi gedaan? Je hebt al veel packet loss naar het modem toe. Dat zou 0% moeten zijn.
Sommige testen waren via wifi, hier allemaal via de kabel direct op het modem aangesloten:
Die packetloss op de 10.10.12.61 is inderdaad packetloss die er niet moet zijn, wat je pings naar de gameservers ook al aangeven. De *** request time outs met 100% packetloss kun je negeren, dat zijn gewoon hops die geen pings toestaan. Heb je ook packetloss als je bijvoorbeeld naar 1.1.1.1 of 8.8.8.8 pingt?
Bedankt voor je antwoord, ja ook packetloss naar 1.1.1.1 zie screenshot hieronder.
Heb je deze testen allemaal bekabeld of via Wifi gedaan? Je hebt al veel packet loss naar het modem toe. Dat zou 0% moeten zijn.
Inderdaad. Als er wel bekabeld is aangesloten is er misschien gewoon een slecht contact in de kabel waardoor de pc soms op wifi overgaat? Zou een mogelijke verklaring kunnen zijn.
Zie bericht hierboven, alles via de kabel getest direct op het modem.
PC heeft geen wifi dus kan niet overgaan op de wifi.
Dan zou je eens een andere kabel naar de router moeten gebruiken. Of zit er toevallig nog een switch o.i.d. tussen.
Dan zou je eens een andere kabel naar de router moeten gebruiken. Of zit er toevallig nog een switch o.i.d. tussen.
Andere kabel zelfde resultaten, nee er zit geen switch tussen. de PC is direct op het Zyxel modem aangesloten.
Blijft de vraag waarom er packetloss zit naar de router..Mischien eens een andere poort op de router proberen? En een andere PC om ook de ethernet poort daarop uit te sluiten?
Kun je het ook testen door in Command Prompt/Windows PowerShell eens te doen
ping -n 50 1.1.1.1.
en dan te kijken wat de resultaten zijn.
Zou je bovenstaande kunnen doen, want je screenshot geeft geen packetloss op 1.1.1.1 aan. De screenshot geeft aan dat al je packets op 1.1.1.1 zijn aangekomen;
Als je packetloss hebt zou die op eindbestemming zichtbaar moeten zijn. Dat je via wifi (die mist wel eens wat maar dat komt met een retry wel goed) of hops niet altijd ping reply krijgt kan ook komen doordat een server voorrang geeft aan data verkeer over pings (hij heeft het gewoon druk) of door firewalls. Vandaar de vraag om een meervoudige ping naar eindbestemming.
Ik wil dit toch eens in 'gewone mensen taal’ uitleggen. Ik heb vroeger bij een grote online gaming community gezeten met eigen server rental dus ik zal het zo makkelijk mogelijk te beschrijven. Je moet kijken naar packetloss bij de eindbestemming en niet zo zeer naar onderweg (alhoewel dit bij problemen wel weer indicatief kan zijn waar eventueel een probleem zit)
Je data wordt verstuurd in pakketjes (packets). Die packets komen onderweg naar eindbestemming met regelmaat niet aan, en dit kan gebeuren bij elk stapje van apparaat naar modem naar server en de volgende server etc.. Dit is echter geen probleem want van elke packet wordt gecontroleerd of deze aankomt, en lukt dit niet, dan wordt hij gewoon opnieuw verzonden. Die werking is gewoon ingebouwd in hoe data verzonden wordt.
Wifi verliest veel meer packets dan een bekabelde verbinding (want meer kans op verstoring door electrische apparaten, wifi van buren etc), maar geen probleem die worden dan opnieuw verzonden en na een herkansing, of meerdere komen die packets wel aan bij het modem. Echter kost dit opnieuw verzenden van de packets natuurlijk wel extra tijd, vandaar dat je ping bij wifi slechter is dan bij bekabeld. Je ziet dan ook bij de wifi test wel packet loss naar het modem, en bij bekabeld niet, maar zo als gezegd, die verloren packets komen na een paar keer opnieuw verzenden wel aan.
Ook de bekabelde route verder naar eindbestemming verliest wel eens een packet, want ze gaan langs servers die het soms een beetje druk hebben, en ook bij kabels zit er wel eens een kinkje in die tot verlies van een packet kan leiden. Maar ook die verloren packets worden dan gewoon weer opnieuw verstuurd, net zo lang tot ze wel aankomen.
Dit is allemaal normaal. Het wordt pas een probleem als:
Je packets komen niet aan op eindbestemming. oftewel, ondanks al die poging van meerdere schakels onderweg om de verloren packets opnieuw te versturen komt je data toch niet allemaal aan. Dan is er dus inderdaad een probleem dat opgelost dient te worden.
Speciaal voor gamers een probleem; de ping naar eindbestemming wordt te hoog (latency). De packets komen onderweg bij individuele stapjes zo vaak niet aan en moeten zo vaak opnieuw verstuurd worden dat het gewoon veel te lang gaat duren voordat de packets eindelijk succesvol bij eindbestemming aankomen. Voor sommige games nog steeds geen probleem, maar bij bijvoorbeeld shooters wel, zeker als een fractie van een seconde bepaald wie wie neerschiet.
Oftewel, als je voor packetloss test, test je voornamelijk of er packetloss is bij de -eindbestemming-, want DAT is problematisch. (Enige) packetloss onderweg hoort erbij, maar kan dus opgevangen worden (tenzij je de ping in de traces erg ziet omhooggaan, maar dat is hier dus niet het geval).
Als er nu ook sprake is van packetloss op eindbestemming, dan kan een expert een blik werpen op de traces, maar dat is van een specialiteit met zoveel mogelijke oorzaken (voor ons als leek erg moeilijk te interpreteren) dat ik ook op dat punt moet afhaken.
Ik hoop dat ik het zo redelijk heb uitgelegd?
Ik wil dit toch eens in 'gewone mensen taal’ uitleggen. Ik heb vroeger bij een grote online gaming community gezeten met eigen server rental dus ik zal het zo makkelijk mogelijk te beschrijven. Je moet kijken naar packetloss bij de eindbestemming en niet zo zeer naar onderweg (alhoewel dit bij problemen wel weer indicatief kan zijn waar eventueel een probleem zit)
Je data wordt verstuurd in pakketjes (packets). Die packets komen onderweg naar eindbestemming met regelmaat niet aan, en dit kan gebeuren bij elk stapje van apparaat naar modem naar server en de volgende server etc.. Dit is echter geen probleem want van elke packet wordt gecontroleerd of deze aankomt, en lukt dit niet, dan wordt hij gewoon opnieuw verzonden. Die werking is gewoon ingebouwd in hoe data verzonden wordt.
Wifi verliest veel meer packets dan een bekabelde verbinding (want meer kans op verstoring door electrische apparaten, wifi van buren etc), maar geen probleem die worden dan opnieuw verzonden en na een herkansing, of meerdere komen die packets wel aan bij het modem. Echter kost dit opnieuw verzenden van de packets natuurlijk wel extra tijd, vandaar dat je ping bij wifi slechter is dan bij bekabeld. Je ziet dan ook bij de wifi test wel packet loss naar het modem, en bij bekabeld niet, maar zo als gezegd, die verloren packets komen na een paar keer opnieuw verzenden wel aan.
Ook de bekabelde route verder naar eindbestemming verliest wel eens een packet, want ze gaan langs servers die het soms een beetje druk hebben, en ook bij kabels zit er wel eens een kinkje in die tot verlies van een packet kan leiden. Maar ook die verloren packets worden dan gewoon weer opnieuw verstuurd, net zo lang tot ze wel aankomen.
Dit is allemaal normaal. Het wordt pas een probleem als:
Je packets komen niet aan op eindbestemming. oftewel, ondanks al die poging van meerdere schakels onderweg om de verloren packets opnieuw te versturen komt je data toch niet allemaal aan. Dan is er dus inderdaad een probleem dat opgelost dient te worden.
Speciaal voor gamers een probleem; de ping naar eindbestemming wordt te hoog (latency). De packets komen onderweg bij individuele stapjes zo vaak niet aan en moeten zo vaak opnieuw verstuurd worden dat het gewoon veel te lang gaat duren voordat de packets eindelijk succesvol bij eindbestemming aankomen. Voor sommige games nog steeds geen probleem, maar bij bijvoorbeeld shooters wel, zeker als een fractie van een seconde bepaald wie wie neerschiet.
Oftewel, als je voor packetloss test, test je voornamelijk of er packetloss is bij de -eindbestemming-, want DAT is problematisch. (Enige) packetloss onderweg hoort erbij, maar kan dus opgevangen worden (tenzij je de ping in de traces erg ziet omhooggaan, maar dat is hier dus niet het geval).
Als er nu ook sprake is van packetloss op eindbestemming, dan kan een expert een blik werpen op de traces, maar dat is van een specialiteit met zoveel mogelijke oorzaken (voor ons als leek erg moeilijk te interpreteren) dat ik ook op dat punt moet afhaken.
Ik hoop dat ik het zo redelijk heb uitgelegd?
Bedankt voor je heldere uitleg, als ik de ping -n 50 1.1.1.1. command uitvoer komen alle pakketjes inderdaad aan.
Toch blijf ik dus problemen houden (vooral in shooters) waar enemies mij eerder zien of als ik dood ga ik een stukje terug geplaatst word. of dat ik soms vooruit/achteruit teleporteer dan waar ik zelf op m'n scherm bevindt. allemaal bekabeld natuurlijk, ik game niet over de wifi.
Ook heb ik wel is vaker pingplotter gebruikt en 1.1.1.1 en 8.8.8.8 of andere websites gepinged en nooit packetloss gehad (behalve toen T-Mobile opeens de routing via Duitsland ging doen). en nu is er duidelijk wel wat aan de hand ook bekabeld zoals te zien in de screenshots.
Ik heb hier nergens anders last van alleen hier op deze locatie, een vriend van me die 2 a 3 straten verder woont met ook T-Mobile heb ik dezelfde testen laten uitvoeren en die heeft geen packetloss nergens en ik met mijn eigen pc op die locatie ook niet toch vreemd.
Ik heb alles al geprobeerd, nieuwe kabels, verse installatie Windows, verschillende PC's. Nieuwe Router etc. Niks helpt helaas..
Graag zou ik toch willen dat er wat dieper naar mijn problemen gekeken kunnen worden anders ben ik helaas toch geneigd over te stappen naar een andere provider waar ik geen zin in heb want dit is geen doen.
Ook zou ik graag in contact willen komen om mijn FTU punt weer in orde te laten maken ik heb contact gehad met KPN Netwerk en die zeggen alleen wat te kunnen doen als een monteur is geweest van de ISP en een opdracht doorstuurt naar hun.
Hoop dat we snel tot een oplossing kunnen komen!
Bij games wordt het allemaal wat ingewikkelder want games passen zelf ook technologie toe om ping en packet problemen op te lossen namelijk lag predictie. Als jij bijvoorbeeld een ping van 200 naar een gameserver hebt, dan gaat de gameserver software steeds voorspellen waar je 200 ms later zult zijn en je op die plek afbeelden voor andere spelers, omdat je anders door latency voor andere spelers achter zou blijven vergeleken met waar je jezelf op het scherm ziet. Meestal doet de game dit door te kijken waar jij heen beweegt en die lijn door te trekken. Als jij echter onverwachts draait of springt etc dan klopt de lag predictie even niet meer, wordt je op zo'n moment net neergeschoten dan kun je jezelf op een andere plek dood zien liggen dan de game ‘voorspeld’ had. Maar toch klopt het zoveel vaker wel dan niet dat lag predictie behulpzaam is in games, maar het klopt dus niet altijd.
Ik ben wel met je eens dat de kwaliteit van verbinding niet meer zo kristalhelder is als in het begin van de internettijd, en dat zal je inderdaad bij dingen als een high paced shooter het eerst merken. Die packetloss op die hop vond ik wel veel, maar toch had diezelfde hop in andere metingen van je geen enkele packet loss. Kan zijn dat de server net even druk was en er 10 seconden later extra servers werden toegevoegd waardoor de hop ontlast werd, en dat dit eigenlijk sneller had gemoeten , maar ja zoals ik zei, dat is trace interpretatie en daar ben ik geen expert in. Maar ik kan me voorstellen als alles bij eindpunt aankomt met een redelijke ping dat wat t-mobile betreft geleverd wordt wat beloofd is.
Of je dit ergen anders beter zult treffen durf ik niet te zeggen, ik lees dergelijke ervaringen eigenlijk wel bij alle aanbieders. Nu speel ik zelf haast geen snelle shooters meer en heb ik hier dus zelf niet veel last van, maar als dat echt heel belangrijk voor je internetervaring is snap ik prima of je je afvraagt of er een probleem speelt waar iets aan te doen is. Dat je FTU in orde hoort te zijn lijkt naar mijn persoonlijke mening niet te veel gevraagd, maar wie dat moet doen (en wie dat moet betalen) daar zal iemand van t-mobile zich over moeten uitlaten.
Dat je FTU in orde hoort te zijn lijkt naar mijn persoonlijke mening niet te veel gevraagd, maar wie dat moet doen (en wie dat moet betalen) daar zal iemand van t-mobile zich over moeten uitlaten.
Om deze aansluiting te herstellen zal er Kpn-netwerk bij moeten komen.
Maar over de kosten de klant heeft zelf ook aan het gevoelige glasvezel punt gezeten.
De kosten kunnen dan ook bij de klant terecht komen.
Bij games wordt het allemaal wat ingewikkelder want games passen zelf ook technologie toe om ping en packet problemen op te lossen namelijk lag predictie. Als jij bijvoorbeeld een ping van 200 naar een gameserver hebt, dan gaat de gameserver software steeds voorspellen waar je 200 ms later zult zijn en je op die plek afbeelden voor andere spelers, omdat je anders door latency voor andere spelers achter zou blijven vergeleken met waar je jezelf op het scherm ziet. Meestal doet de game dit door te kijken waar jij heen beweegt en die lijn door te trekken. Als jij echter onverwachts draait of springt etc dan klopt de lag predictie even niet meer, wordt je op zo'n moment net neergeschoten dan kun je jezelf op een andere plek dood zien liggen dan de game ‘voorspeld’ had. Maar toch klopt het zoveel vaker wel dan niet dat lag predictie behulpzaam is in games, maar het klopt dus niet altijd.
Ik ben wel met je eens dat de kwaliteit van verbinding niet meer zo kristalhelder is als in het begin van de internettijd, en dat zal je inderdaad bij dingen als een high paced shooter het eerst merken. Die packetloss op die hop vond ik wel veel, maar toch had diezelfde hop in andere metingen van je geen enkele packet loss. Kan zijn dat de server net even druk was en er 10 seconden later extra servers werden toegevoegd waardoor de hop ontlast werd, en dat dit eigenlijk sneller had gemoeten , maar ja zoals ik zei, dat is trace interpretatie en daar ben ik geen expert in. Maar ik kan me voorstellen als alles bij eindpunt aankomt met een redelijke ping dat wat t-mobile betreft geleverd wordt wat beloofd is.
Of je dit ergen anders beter zult treffen durf ik niet te zeggen, ik lees dergelijke ervaringen eigenlijk wel bij alle aanbieders. Nu speel ik zelf haast geen snelle shooters meer en heb ik hier dus zelf niet veel last van, maar als dat echt heel belangrijk voor je internetervaring is snap ik prima of je je afvraagt of er een probleem speelt waar iets aan te doen is. Dat je FTU in orde hoort te zijn lijkt naar mijn persoonlijke mening niet te veel gevraagd, maar wie dat moet doen (en wie dat moet betalen) daar zal iemand van t-mobile zich over moeten uitlaten.
In ieder geval bedankt voor je moeite en uitleg! het vreemde is dat ik er alleen hier op deze locatie last van heb en nergens anders en dat de packet loss constant is op dezelfde hops op elk moment van de dag. en als ik het bij iemand test die ook t-mobile heeft die 2/3 straten verder woont het nooit is.
Ik hoor dan ook graag van @Tommie wat de techneuten eventueel tegen komen en wat we eventueel kunnen doen aan de FTU kwestie.
Tot zover bedankt!
@famverkerk
Wat heb je er nu hangen dan de Fritzbox of de Zyxel.
En wat is er gebeurt met je glasvezel aansluiting.
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.
bedankt!
