Vraag

Fortnite upload package loss

  • 21 september 2020
  • 80 reacties
  • 1096 keer bekeken

Reputatie 1

Ik heb eigenlijk al heel lang (>6 mnd) het "probleem" dat ik standaard een 1%-2% upload package loss bij Fortnite heb. Tijdje terug een keer contact gehad met Ziggo en monteur langs geweest. Die zag wat ruis op de lijn en heeft dat met een swap op de access point kunnen verhelpen. Toch krijg ik die kleine upload package loss maar niet opgelost. Verschillende kabels en hardware (Xbox en pc) al geprobeerd maar toch krijg ik het er niet uit.  Via pingplotter gekeken maar dat komt niet echt een eenduidig beeld uit (soms lijkt ie in jump 4 te zitten en soms in 8 geloof ik). Is er iets wat ik wellicht nog meer zou kunnen doen om de connectie stabiel te krijgen?

Hardware setup: Witte connection box in bridge en daarachter een TP-Link Archer C2600.


80 Reacties

Reputatie 1

Voor de volledigheid, het aantal uncorrectables is na 7 dagen in use van het modem toch best gestegen.

 

CM Downstream Channel Info
Channel Lock Status Channel Type Channel ID Frequency Width Power SNR Modulation Profile ID Correctables Uncorrectables
1 Locked SC-QAM Downstream 5 634000000 Hz 8000000 Hz 5.3 dBmV 40.5 dB QAM256 49 0
2 Locked SC-QAM Downstream 1 602000000 Hz 8000000 Hz 5.2 dBmV 40.6 dB QAM256 55 0
3 Locked SC-QAM Downstream 2 610000000 Hz 8000000 Hz 5 dBmV 40.5 dB QAM256 41 28
4 Locked SC-QAM Downstream 3 618000000 Hz 8000000 Hz 5.2 dBmV 40.6 dB QAM256 59 0
5 Locked SC-QAM Downstream 4 626000000 Hz 8000000 Hz 5.3 dBmV 40.6 dB QAM256 62 42
6 Locked SC-QAM Downstream 6 642000000 Hz 8000000 Hz 5.2 dBmV 40.2 dB QAM256 57 19
7 Locked SC-QAM Downstream 7 650000000 Hz 8000000 Hz 5.5 dBmV 40.5 dB QAM256 65 0
8 Locked SC-QAM Downstream 8 658000000 Hz 8000000 Hz 5.5 dBmV 40.6 dB QAM256 48 30
9 Locked SC-QAM Downstream 9 666000000 Hz 8000000 Hz 5.4 dBmV 40.7 dB QAM256 55 0
10 Locked SC-QAM Downstream 10 674000000 Hz 8000000 Hz 5.6 dBmV 40.1 dB QAM256 42 0
11 Locked SC-QAM Downstream 11 682000000 Hz 8000000 Hz 5.5 dBmV 40.7 dB QAM256 43 0
12 Locked SC-QAM Downstream 12 690000000 Hz 8000000 Hz 5.9 dBmV 40.8 dB QAM256 51 0
13 Locked SC-QAM Downstream 13 698000000 Hz 8000000 Hz 6 dBmV 40.9 dB QAM256 47 0
14 Locked SC-QAM Downstream 14 706000000 Hz 8000000 Hz 5.8 dBmV 40.8 dB QAM256 38 0
15 Locked SC-QAM Downstream 15 714000000 Hz 8000000 Hz 5.8 dBmV 40.8 dB QAM256 48 0
16 Locked SC-QAM Downstream 16 722000000 Hz 8000000 Hz 5.4 dBmV 40.6 dB QAM256 39 0
17 Locked SC-QAM Downstream 17 730000000 Hz 8000000 Hz 5.2 dBmV 40.6 dB QAM256 46 0
18 Locked SC-QAM Downstream 18 738000000 Hz 8000000 Hz 5.2 dBmV 40.7 dB QAM256 69 0
19 Locked SC-QAM Downstream 19 746000000 Hz 8000000 Hz 4.9 dBmV 40.4 dB QAM256 70 0
20 Locked SC-QAM Downstream 20 754000000 Hz 8000000 Hz 4.9 dBmV 40.5 dB QAM256 61 0
21 Locked SC-QAM Downstream 21 762000000 Hz 8000000 Hz 4.7 dBmV 40.4 dB QAM256 69 0
22 Locked SC-QAM Downstream 22 770000000 Hz 8000000 Hz 4.5 dBmV 40.3 dB QAM256 83 0
23 Locked SC-QAM Downstream 23 778000000 Hz 8000000 Hz 4.3 dBmV 40.4 dB QAM256 85 0
24 Locked SC-QAM Downstream 24 786000000 Hz 8000000 Hz 3.9 dBmV 40.2 dB QAM256 90 1

 

 

 

CM Upstream Channel Info
Channel Lock Status Channel Type Channel ID Frequency Width Power Modulation/Profile ID
1 Locked ATDMA 1 57800000 Hz 6400000 Hz 43.8 dBmV 2
2 Locked ATDMA 2 50900000 Hz 6400000 Hz 44.5 dBmV 2
3 Locked ATDMA 3 44000000 Hz 6400000 Hz 44 dBmV 2
4 Locked ATDMA 4 37100000 Hz 6400000 Hz 44 dBmV 2
5 Locked ATDMA 5 31800000 Hz 3200000 Hz 43.5 dBmV 2
6 Locked ATDMA 6 28600000 Hz 3200000 Hz 43.3 dBmV 2
Reputatie 1

@Mariska Ziggo Vooropvolgend op bovenstaande posts. Ik heb vandaag wederom even wat tests gedaan door direct op het Ziggo Modem te connecten (in dit geval dus de Ubee). De resultaten zijn zeker interessant te noemen.

 

Het begon eigenlijk met onderstaand plaatje. Daar zie je 1 pakket verlies direct nadat ik de verbinding direct op het Ubee modem had geplaatst. Hoe snel ik de conclusie wou trekken dat het echt niet aan mijn interne netwerk ligt testte ik nog even verder.

 

Terwijl ik dus nog direct verbonden ben met de Ubee heb ik nog meerdere plots laten lopen en heb ik ook online Fortnite getest. Hierin kwam naar voren dat ik gedurende 30 min geen enkel pakket verloor. Natuurlijk was dit met maar 1 enkele actieve verbinding en op een relatief rustig tijdstip (17:00 uur) maar dat was hoopvol nieuws. Daarna connecte ik de Xbox ook even direct op het modem ook daar kwam hetzelfde resultaat uit, geen pakket verlies.

 

Omdat ik hiermee ging twijfelen of wellicht mijn eigen router wellicht niet een oorzaak kan zijn heb ik direct ook enkele andere testen gedaan. Als eerste zette ik de Ubee in router functie en liet ik 1 kabel direct naar mijn PC lopen met ping plots daarop en 1 kabel via mijn eigen router naar de Xbox (modem>router>xbox). Terwijl ik online Fortnite op de Xbox speelde waren er geen enkele package losses te zien. Daarna draaide ik de setting om om te bepalen hoe daar het resultaat was en ook daar geen packet loss.

 

Uiteindelijk daarna ook weer alles in dezelfde setting als altijd geplaatst en wederom in deze 2 uur gedurende test praktijk weer geen packet loss op zowel PC of Xbox.

 

Bovenstaande is dus allemaal positief en hoopvol. Het kan dus echt wel dat er een verbinding geleverd wordt waar geen packet loss op bevindt. Natuurlijk was het niet gedurende prime time maar het geeft aan dat het mogelijk is.

 

De conclusie die ik hier echter wel wederom aan kan hangen is dat wanneer packet loss ontstaat in de lijn dat het voor mij nog steeds niet aannemelijk is dat dit aan mij ligt maar dat het ergens fout gaat in het netwerk van Ziggo zoals dat enkele dagen geleden wel tot een dieptepunt leidde (waarbij zelfs de game-ervaring negatief werd beïnvloed). Je zag het ook terug in de waardes van het Ubee modem.

 

Als ik even de data wat verder analyseer die ik zelf voorhanden heb. Dan zie ik eigenlijk in alle tests dat de loss voornamelijk vanaf Hop 2 tot maximaal Hop 5 gebeurd (onderstaand is Hop 1 aangezien deze nu direct op jullie modem zit). Oftewel in het middenstuk van het traject van user tot host. Aangezien de benaming van deze hosts eigenlijk overal hetzelfde zijn lijkt het mij dat deze hops zich nog bevinden in het netwerk van Ziggo. Wat ik echter niet kan beantwoorden is de beïnvloedbaarheid tot aan Hop 5 en hoe jullie de connectie voor mij kunnen verbeteren?

 

Dat ik een moment zonder packet loss heb ervaring is wat dat betreft vrij uniek en ik zal het de komende dagen ook zeker in de gaten blijven houden. Toch zou ik je willen vragen om naar bovenstaande te kijken om te zien of je hier iets mee kunt.

 

(Sorry voor het lange verhaal maar ik wou duidelijk verwoorden wat ik getest heb en de daaruit voortvloeiende conclusies die je kunt trekken).

 

 

Reputatie 1

Overigens is de loss er vanochtend weer gewoon als "vanouds". Zichtbaar op alle apparaten.

 

Voorbeeldje hier beneden gedaan vanuit mijn router. Deze wisselt tussen 0%, 2% en 4% per test.

 

Ping www.google.com (216.58.214.4): 64 data bytes
Reply from 216.58.214.4:  bytes=64  ttl=117  seq=1  time=15.214 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=2  time=12.371 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=3  time=11.091 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=4  time=15.620 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=5  time=10.966 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=6  time=10.934 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=7  time=11.996 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=8  time=15.183 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=9  time=11.122 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=10  time=12.340 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=11  time=13.683 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=12  time=11.590 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=13  time=13.058 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=14  time=10.778 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=15  time=11.840 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=16  time=13.996 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=17  time=13.090 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=18  time=13.090 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=19  time=11.653 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=20  time=13.621 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=21  time=11.965 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=22  time=12.934 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=23  time=12.059 ms
Request timed out !
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=25  time=10.934 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=26  time=15.057 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=27  time=11.091 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=28  time=11.496 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=29  time=10.590 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=30  time=10.590 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=31  time=11.652 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=32  time=11.840 ms
Request timed out !
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=34  time=19.837 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=35  time=13.309 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=36  time=13.464 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=37  time=12.715 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=38  time=13.246 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=39  time=11.528 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=40  time=7.810 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=41  time=15.652 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=42  time=11.122 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=43  time=16.870 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=44  time=19.931 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=45  time=10.090 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=46  time=15.995 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=47  time=13.152 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=48  time=11.840 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=49  time=11.809 ms
Reply from 216.58.214.4:  bytes=64  ttl=118  seq=50  time=12.590 ms

--- Ping Statistic "www.google.com" ---
Packets: Sent=50, Received=48, Lost=2 (4.00% loss)
Round-trip min/avg/max = 7.810/12.800/19.931 ms

Reputatie 1

Ik kreeg gisteren avond laat een bericht dat er een Connectbox naar mij opgestuurd wordt. Kan dit kloppen @Mariska Ziggo ?

 

Ik heb verder ook zitten denken. Ik zou ook tijdelijk mijn eigen netwerk uit kunnen schakelen en het bekabelde netwerk direct op de Ziggo modem aansluiten voor enkele dagen (met andere bekabeling!). Hiermee zouden we werkelijk kunnen concluderen of mijn netwerk nu wel of geen invloed heeft op de pakket loss. Maar dan wil ik wel de garantie dat wanneer blijkt dat het issue hier niet mee is opgelost dat er tot op de bodem wordt uitgezocht waarom het probleem in jullie netwerk. Is dit een idee of wat denken jullie?

 

De laatste dagen heb ik er namelijk flink last van gehad tijdens gamen waarbij ik zelfs een aantal keren uit de game wordt gegooid vanwege netwerk issues...

Reputatie 7
Badge +13

Ik heb toevallig gisteren ook zo'n email gehad.

Ik heb daar al navraag over gedaan bij een moderator.

Ik heb hier al terugkoppeling over gehad:

 

Er zijn bij Ziggo meer meldingen ontvangen omtrent onterechte of te late e-mails bij een modemwissel.

Dat wordt op dit moment onderzocht. In ieder geval niets aan de hand dus.

Reputatie 1

Bedankt @Tom. Goed om te weten.

 

Dan wacht ik even @Mariska Ziggo reactie af m.b.t. vervolgstappen. Ik ben bereid om mee te denken om het op te lossen want ik zou graag bij Ziggo willen blijven. Hopelijk reageert ze snel.

Reputatie 7

Goedemiddag @Remmetje,

Dankjewel voor het sturen van je bevindingen. De hops die je aanmerkt als zijnde packetloss hoeven niet direct voor problemen te zorgen. Zie ook de uitleg op deze pagina op de website van Pingplotter voor de uitleg. 
Ik stel wel voor dat ik de komende 7 dagen een ICMP en voicesessie laat lopen om jouw verbinding nauwkeurig te monitoren. Zou jij de komende week ook willen bijhouden op welke data en tijdstippen jij problemen ervaart
met de connectie? Leg je bevindingen dan even vast in een Excel of tekstbestand en deel dit vervolgens na 5 a 7 dagen. Dan kan ik aan de hand van onze en jouw data de vervolgstappen bepalen. 

Reputatie 1

@Paul Ziggo 

Dat is top Paul! Laten we inderdaad over 7 dagen dan eens kijken. Ik heb echter niet de software om constant te monitoren en door de gezinssituatie is gamen ook echt alleen maar mogelijk in de avond dus mijn exposure zogezegd is beperkt tot die momenten dat ik online game. Ik zal echter wel steekproeven blijven doen over de dagen heen om te kijken naar de kwaliteit van de verbinding (software laat ook maar intervallen van max 10 min per meting zien) en zal het eventuele package loss percentage melden per meting (ik weet dat ik naar de laatste hop moet kijken). En als ik in de avonden er echt last van heb gehad (zoals ik dat recent ook had), dan laat ik dit ook weten aan het einde van de 7 dagen.

 

Bedankt in ieder geval dat het probleem serieus wordt genomen door Ziggo, dat waardeer ik echt, en ik ben ook wel benieuwd wat jouw meting straks laat zien. Jij zal daarin een duidelijker beeld hebben.

 

Laatste 2 dagen gamen was overigens wel weer zonder problemen. Zou het afhankelijk kunnen zijn van de drukte van het internetverkeer in de wijk (ik gis hier wat)?

Reputatie 1

@Paul Ziggo 

Ik ben benieuwd naar wat uit jouw monitoring is gekomen. Zou je de resultaten kunnen delen? Ik heb de volgende observaties deze week gedaan. Je ziet hierin wel een trend dat er eigenlijk altijd wel PL is, al komt die eigenlijk niet boven de 1% uit als je steeds een langere periode meet.

 

  Di Wo Do Vr Za Zo Ma
  17-11-2020 18-11-2020 19-11-2020 20-11-2020 21-11-2020 22-11-2020 23-11-2020
Packet Loss momenten 14:28 = 0,3% PL 09:00 = 0,3% PL 09:00 = 0,0% PL 19:25 = 0,0% PL 14:00 = 0,3% PL 11:00 = 0,5% PL 15:45 = 0,1% PL
  Avond: geringe PL (<1%) Om 9:11 - 9:12 viel internet en tv weg 17:00 = 0,4% PL Avond: Geen activiteit gedaan Avond: Geen activiteit gedaan 17:00 = 0,2% PL Avond: geringe PL (<1%)
    17:00 = 0,0% PL 20:15 = 0,2% PL     21:00 = 0,0% PL 20:55 - Flinke spike (bijna discon)
    Avond: Geen activiteit gedaan Avond: geringe PL (<1%)     Avond: Geen activiteit gedaan  
Reputatie 7

@Remmetje Hartelijk dank voor het delen! Uit mijn metingen is naar voren gekomen dat er ruis terug te zien is op het signaal (CCER/CER) wat vervolgens ook gelijk gepaard gaat met packetloss. Op bepaalde momenten is er 0.5%tot 2 % packetloss terug te zien. 
Ik stel voor dat we een afspraak met een netwerkmonteur inplannen. In de monteursbon zal ik dan mijn eigen en jouw data delen zodat er gericht gezocht kan worden. Op welke data schikt een afspraak jou het best?

Reputatie 1

@Paul Ziggo Bedankt voor je antwoord en onderzoek. Goed om te lezen dat er toch iets “zichtbaar” aan de hand is waar hopelijk ook iets aan gedaan kan worden. Het is geen probleem om weer een monteur langs te laten sturen, hopelijk kan deze de ruis wel uit de kabel halen.

 

Aangezien ik op dit moment fulltime thuis werk kan ik op best veel momenten.

Vrij 27-11 - middag

Ma 30-11 - middag

Di 01-12 - hele dag

Wo 02-12 - hele dag

Do 03-12 - hele dag

 

Ik neem aan dat je uit bovenstaande momenten wel een moment kunt inplannen toch?

Reputatie 1

@Paul Ziggo Neem anders even met mij direct contact op per mail/twitter/telefoon zodat we die afspraak kunnen inplannen aangezien de meeste mogelijke momenten al vervlogen zijn. Dat gaat denk ik wat makkelijker en sneller. In je systemen kun je achterhalen hoe je mij kunt bereiken maar via al die kanalen ben ik gewoon goed bereikbaar.

Reputatie 1

@Paul Ziggo Ik wil niet lullig doen maar ik wacht nu al vanaf 25 Nov dat je contact met mij legt om een afspraak vast te leggen voor een monteur voor de gevonden probleem. Zou je met mij contact kunnen opnemen via de aangegeven kanalen?

Reputatie 7
Badge +13

Ik ga aan een Super Expert vragen om een seintje te geven aan de moderators.

 

Reputatie 7
Badge +17

Goeie morgen @Remmetje, ik denk dat je door de grote drukte tussen ka en schip bent beland. Uitermate vervelend, maar niet altijd te voorkomen.

Ik heb inmiddels het moderatieteam een reminder gestuurd.

Reputatie 7

Goedemorgen @Remmetje,

Mijn excuses voor de late reactie! Dit bericht is helaas tussen wal en schip beland vanwege de grote drukte. Ik heb ene afspraak met een monteur voor je weten te regelen op
maandag 14 december 2020 tussen 12:00 uur en 18:00 uur. Mocht het dan niet lukken dan is de afspraak eenvoudig via Mijn Ziggo > Mijn Gegevens > Mijn Monteursafspraken te wijzigen.  
Laat na het monteursbezoek maar weten wat je bevindingen zijn. 

Groeten,

Paul 

Reputatie 1

Bedankt voor de snelle reacties iedereen. Maandag is geen probleem, ik zal zo spoedig mogelijk na het bezoek een update geven.

Reputatie 1

@Paul Ziggo Update vanuit mijn kant: vriendelijke monteur is langs geweest en heeft het punt waarop de verbinding het huis binnen komt weer doorgemeten. Waardes zien er goed uit en na het uitlezen van modem e.d., en na contact te hebben gehad met een collega, zichtbaar dat de problematiek zichtbaar is in de CCER (en niet CER). Daar zag die wel echt afwijkende waardes (nu was er voornamelijk in de downstream een probleem zichtbaar en niet in de upstream, wat ik overigens wel bijzonder vond). Doordat het op deze manier zichtbaar is, is het heel moeilijk vast te stellen wat nu de oorzaak is.

 

Er is voor volgende week maandag een super-expert gepland om te kijken naar de lijn in de wijk (hopen dat die met de aanstaande lockdown nog langs mag komen...). Dus het is even afwachten.

Reputatie 7
Badge +17

@Remmetje Bedankt voor de update. Ben benieuwd naar het vervolg over een week.

Reputatie 7

@Remmetje Hartelijk dank voor je update! Laat maar weten wat er verder uitkomt. We zijn erg benieuwd! In ieder geval fijn dat er actie op ondernomen wordt. 

Reputatie 1

@Paul Ziggo De monteur is langs geweest en heeft in de wijkkast gekeken. Daar zag alles er goed uit. Binnen heeft ie ook gekeken en toen viel hem op dat de connector op de groene kabel (de kabel die vanuit buiten naar binnen komt) niet helemaal goed meer waren en ook gevoelig voor storing waren. Deze zijn vervangen en hij heeft goed gekeken of die nog problemen gaf. Ik vond het opvallend dat dit eigenlijk de eerste monteur was die naar die fysieke verbinding keek.

 

Ik heb sinds dat de monteur weg (>1 uur) een pingplot laten lopen en die bleef rond de 0,1% - 0,2% loss hangen. Ik zal vanavond, wanneer het echt piekuur is op jullie netwerk, nog eenzelfde test laten lopen om te kijken maar ik verwacht dat we hiermee de verbinding zo optimaal mogelijk hebben gemaakt. Niet perfect maar in ieder geval een stuk beter dan toen we begonnen aan deze acties.

 

Dus vanavond nog een korte update en hopelijk komen daar geen al te gekke waardes uit. Het belangrijkste nu is dat de spikes eruit zijn. Als er dan vergelijkbare waardes uit komen dan zal ik het zien als het sluiten van deze issue.

Reputatie 1

Verbinding in de avond was ook niet heel slecht. Variërend van 0% tot 0,3% package loss gemeten over 2 uur (20:00 tot 22:00). Dus de verbinding is weer ietsje beter al kunnen we ook concluderen dat hij niet perfect zal zijn. Ik denk dat dat de conclusie van dit onderzoek van 7 maanden is.

 

Ik wil wat dat betreft ook iedereen op dit forum even bedanken voor alle hulp die aangeboden is.

Reputatie 7

@Remmetje Bedankt voor je terugkoppeling en fijn dat je eerste bevindingen goed zijn. Wat betreft de package los (0 tot 0.3%) hoe heb je dit precies vastgesteld en merk je ook 
iets als je de verbinding gebruikt?

Reputatie 1

@Remmetje Bedankt voor je terugkoppeling en fijn dat je eerste bevindingen goed zijn. Wat betreft de package los (0 tot 0.3%) hoe heb je dit precies vastgesteld en merk je ook 
iets als je de verbinding gebruikt?

Terwijl ik de game speelde op de Xbox, waar de upload package loss soms te zien was, had ik verschillende ping plots lopen op de PC. Iedere 10 minuten keek ik even naar de plots om de package loss (dus een werkelijk pakket aan het eind van het signaal) vast te stellen. Meestal zat er ook daar dus een loss maar heel soms ook niet. 

 

Verder heb ik er gisteren qua verbinding niets van gemerkt. 

Reputatie 7

@Remmetje Zie je dan ook waar de packetloss precies ontstaat? Deel anders een screenshot van een pingsessie.

Reageer