Packet loss/Slechte routing gameservers + FTU kapot?

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.

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.

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.”

Zie bericht hierboven :) bedankt!

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. 

Sommige testen waren via wifi, hier allemaal via de kabel direct op het modem aangesloten:

Dan zou je eens een andere kabel naar de router moeten gebruiken. Of zit er toevallig nog een switch o.i.d. tussen. 

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?

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:

1. 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.
2. 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?

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!