Skip to main content
Beantwoord

Packetloss/lage snelheid glasvezel bij Geforce Now

E

Hallo allemaal. Ik heb sinds een aantal weken een jaar abonnement op een gaming service van Nvidia genaamd Geforce Now. Dit stelt me in staat om games te streamen van hun servers. Zoals je zou denken neemt dit veel bandbreedte in beslag (tot 50mbps), T-Mobile Thuis glasvezel zou hier dus uitstekend voor moeten zijn…..

 

Helaas heb ik sinds dag 1 problemen met de service. De voornaamste problemen zijn:

  • Lage bandbreedte: <10mbps
  • Packet loss: >10%

Dit maakt de ervaring zeer slecht en in veel gevallen onspeelbaar. De situatie die ik thuis heb is als volgt:

TP-Link MC220L → OpenWrt router (TP-Link AC2600)

Alle Geforce Now apparaten zijn aangesloten met ethernet. Een speedtest op die apparaten haalt consequent 100/100mbps (mijn max snelheid). Nu heb ik ook proberen uit te sluiten dat het aan OpenWrt ligt of media converter van TP-link. Vandaar dat ik vandaag de Vigor Draytek weer heb aangesloten.

Hierbij zie ik exact hetzelfde problematiek als bij mijn normale setup. 

Verder heb ik contact opgenomen met Nvidia zonder uitsluitsel.

Een aantal opvallende observaties:

  • Via 4g, met de telefoon, ondervind ik geen packet loss
  • Bij me broer, die ook T-Mobile Thuis heeft met een Huawei modem, ondervond ik ook geen problemen

Dus ik zit inmiddels met mijn handen in mijn grote bos haar en daarom hoop ik dat T-Mobile hierbij kan ondersteunen. OF eventueel 1 van de velen slimme internet gangers op dit forum.

Beste antwoord door EduardA

Jason schreef:

Hoi @EduardA, bedankt voor je terugkoppeling! 

In principe kunnen wij aan onze kant niet zoveel wijzigen in jouw situatie, maar gelukkig zie ik dat mijn collega van de Klantenservice voor hulp heeft aangeklopt bij de technische dienst. Hun verwerkingstijd bedraagt momenteel maximaal twaalf dagen. Heb je het Draytekmodem aangesloten op het FTU (glasvezelaansluitpunt)? Zo niet, wanneer ons modem niet aangesloten is, kan er geen lijnmeting gedaan worden om jouw packetloss situatie te analyseren. 

Daarnet een onwijs frustrerend gesprek gehad met de t-mobile klantenservice. Technische dienst stelt dat ze geen game streaming diensten ondersteunen bij T-Mobile Thuis, ik raakte daar eerlijk gezegd enigzins geirriteerd over omdat ze blijkbaar niet eens de moeite hebben gedaan om dit echt te testen (e.g. kijken of UDP verkeer goed wordt afgehandeld). Heb het eigenlijk een beetje gehad hiermee. Ik ga het opzeggen en overstappen. Deze topic kan je sluiten.

Bekijk origineel

23 reacties

Hidden.nld
Super User
Forum|alt.badge.img+4
  • Hidden.nldSuper User
  • Odido Superuser
  • 3596 reacties
  • 18 oktober 2020

@EduardA dat word een lastige.

zou je een ping -c 100 kunnen doen voor de server waar mee je verbinding maakt en 2 andere sites bijvoorbeeld google dns 8.8.8.8 en nu.nl

zo kunnen we zien of het probleem met de gameserve is of ergens anders.

een tracert voor de zelfde hosts zou ook helpen.

op die manier kunnen we bepalen welke kant er op gewerkt moet worden en kan een moderator het door zetten.

Heeft geen glazenbol.
E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 18 oktober 2020

Sure:

 

$ ping -c 100 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.18 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=2.98 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=2.89 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=2.85 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=2.94 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=2.94 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 2.845/2.962/3.181/0.107 ms
ping -c 100 nu.nl
PING nu.nl (13.224.68.36) 56(84) bytes of data.
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=1 ttl=242 time=18.1 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=2 ttl=242 time=18.0 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=3 ttl=242 time=18.1 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=4 ttl=242 time=18.0 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=5 ttl=242 time=18.0 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=6 ttl=242 time=18.0 ms
64 bytes from server-13-224-68-36.dub2.r.cloudfront.net (13.224.68.36): icmp_seq=7 ttl=242 time=18.0 ms
^C
--- nu.nl ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6007ms
rtt min/avg/max/mdev = 17.980/18.033/18.067/0.025 ms

Nvidia blokkeert alle ping request (helaas). Dit is in ieder geval de range van adressen waaruit de UDP stream wordt opgezet:

https://ipinfo.io/AS50889/80.84.163.0/24

 

 

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 19 oktober 2020
Hidden.nld schreef:

@EduardA dat word een lastige.

zou je een ping -c 100 kunnen doen voor de server waar mee je verbinding maakt en 2 andere sites bijvoorbeeld google dns 8.8.8.8 en nu.nl

zo kunnen we zien of het probleem met de gameserve is of ergens anders.

een tracert voor de zelfde hosts zou ook helpen.

op die manier kunnen we bepalen welke kant er op gewerkt moet worden en kan een moderator het door zetten.

Als je nog ideetjes heb hoe ik een antwoord boven water kan halen bij die Nvidia servers dan sta ik zeker open tot suggesties.

Hidden.nld
Super User
Forum|alt.badge.img+4
  • Hidden.nldSuper User
  • Odido Superuser
  • 3596 reacties
  • 22 oktober 2020

@EduardA 6 pings is een beetje weinig om packetloss te zien. daarom had ik er 100 van gemaakt.

heb je server adressen ? gaan we eens kijken of we daar war mee kunnen.

Heeft geen glazenbol.
E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 22 oktober 2020
Hidden.nld schreef:

@EduardA 6 pings is een beetje weinig om packetloss te zien. daarom had ik er 100 van gemaakt.

heb je server adressen ? gaan we eens kijken of we daar war mee kunnen.

$ ping -c 100 nu.nl
PING nu.nl (13.224.68.94) 56(84) bytes of data.
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=1 ttl=243 time=19.9 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=2 ttl=243 time=105 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=3 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=4 ttl=243 time=34.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=5 ttl=243 time=47.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=6 ttl=243 time=92.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=7 ttl=243 time=95.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=8 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=9 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=10 ttl=243 time=37.7 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=11 ttl=243 time=85.9 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=12 ttl=243 time=81.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=13 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=14 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=15 ttl=243 time=42.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=16 ttl=243 time=99.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=17 ttl=243 time=22.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=18 ttl=243 time=40.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=19 ttl=243 time=55.6 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=20 ttl=243 time=104 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=21 ttl=243 time=105 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=22 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=23 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=24 ttl=243 time=91.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=25 ttl=243 time=94.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=26 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=27 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=28 ttl=243 time=21.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=29 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=30 ttl=243 time=90.9 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=31 ttl=243 time=20.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=32 ttl=243 time=26.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=33 ttl=243 time=75.7 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=34 ttl=243 time=68.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=35 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=36 ttl=243 time=22.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=37 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=38 ttl=243 time=20.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=39 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=40 ttl=243 time=35.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=41 ttl=243 time=69.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=42 ttl=243 time=23.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=43 ttl=243 time=20.6 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=44 ttl=243 time=21.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=45 ttl=243 time=58.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=46 ttl=243 time=80.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=47 ttl=243 time=88.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=48 ttl=243 time=106 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=49 ttl=243 time=21.6 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=50 ttl=243 time=54.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=51 ttl=243 time=64.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=52 ttl=243 time=114 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=53 ttl=243 time=22.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=54 ttl=243 time=20.9 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=55 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=56 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=57 ttl=243 time=20.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=58 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=59 ttl=243 time=26.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=60 ttl=243 time=64.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=61 ttl=243 time=51.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=62 ttl=243 time=34.9 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=63 ttl=243 time=56.6 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=64 ttl=243 time=80.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=65 ttl=243 time=102 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=66 ttl=243 time=21.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=67 ttl=243 time=22.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=68 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=69 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=70 ttl=243 time=20.6 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=71 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=72 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=73 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=74 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=75 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=76 ttl=243 time=46.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=77 ttl=243 time=20.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=78 ttl=243 time=20.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=79 ttl=243 time=22.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=80 ttl=243 time=33.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=81 ttl=243 time=57.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=82 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=83 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=84 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=85 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=86 ttl=243 time=21.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=87 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=88 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=89 ttl=243 time=20.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=90 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=91 ttl=243 time=20.4 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=92 ttl=243 time=21.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=93 ttl=243 time=20.1 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=94 ttl=243 time=20.2 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=95 ttl=243 time=21.0 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=96 ttl=243 time=19.8 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=97 ttl=243 time=21.3 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=98 ttl=243 time=20.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=99 ttl=243 time=65.5 ms
64 bytes from server-13-224-68-94.dub2.r.cloudfront.net (13.224.68.94): icmp_seq=100 ttl=243 time=20.1 ms

--- nu.nl ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99129ms
rtt min/avg/max/mdev = 19.802/39.979/113.880/28.708 ms

$ ping -c 100 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=5.61 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=6.32 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=5.52 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=6.36 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=5.41 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=6.46 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=7.00 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=5.80 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=5.82 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=5.49 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=119 time=5.58 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=119 time=5.43 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=119 time=5.99 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=119 time=5.82 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=119 time=5.48 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=119 time=9.55 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=119 time=5.24 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=119 time=5.86 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=119 time=5.59 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=119 time=5.82 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=119 time=6.80 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=119 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=119 time=5.44 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=119 time=5.20 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=119 time=5.20 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=119 time=6.19 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=119 time=9.83 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=119 time=5.42 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=119 time=6.03 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=119 time=5.39 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=119 time=5.35 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=119 time=5.27 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=119 time=5.47 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=119 time=6.46 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=119 time=5.42 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=119 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=119 time=5.58 ms
64 bytes from 8.8.8.8: icmp_seq=44 ttl=119 time=6.25 ms
64 bytes from 8.8.8.8: icmp_seq=45 ttl=119 time=5.46 ms
64 bytes from 8.8.8.8: icmp_seq=46 ttl=119 time=5.40 ms
64 bytes from 8.8.8.8: icmp_seq=47 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=48 ttl=119 time=5.70 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=119 time=6.03 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=119 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=119 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=52 ttl=119 time=5.41 ms
64 bytes from 8.8.8.8: icmp_seq=53 ttl=119 time=5.34 ms
64 bytes from 8.8.8.8: icmp_seq=54 ttl=119 time=5.39 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=119 time=5.73 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=119 time=5.73 ms
64 bytes from 8.8.8.8: icmp_seq=57 ttl=119 time=6.28 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=119 time=5.44 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=119 time=7.08 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=119 time=5.35 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=119 time=5.20 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=119 time=7.22 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=119 time=6.83 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=119 time=5.33 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=119 time=5.24 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=119 time=5.52 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=119 time=5.53 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=119 time=5.32 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=119 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=119 time=8.09 ms
64 bytes from 8.8.8.8: icmp_seq=71 ttl=119 time=5.51 ms
64 bytes from 8.8.8.8: icmp_seq=72 ttl=119 time=5.30 ms
64 bytes from 8.8.8.8: icmp_seq=73 ttl=119 time=9.38 ms
64 bytes from 8.8.8.8: icmp_seq=74 ttl=119 time=5.78 ms
64 bytes from 8.8.8.8: icmp_seq=75 ttl=119 time=5.72 ms
64 bytes from 8.8.8.8: icmp_seq=76 ttl=119 time=7.09 ms
64 bytes from 8.8.8.8: icmp_seq=77 ttl=119 time=5.26 ms
64 bytes from 8.8.8.8: icmp_seq=78 ttl=119 time=5.41 ms
64 bytes from 8.8.8.8: icmp_seq=79 ttl=119 time=5.78 ms
64 bytes from 8.8.8.8: icmp_seq=80 ttl=119 time=5.71 ms
64 bytes from 8.8.8.8: icmp_seq=81 ttl=119 time=6.19 ms
64 bytes from 8.8.8.8: icmp_seq=82 ttl=119 time=5.59 ms
64 bytes from 8.8.8.8: icmp_seq=83 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=84 ttl=119 time=5.35 ms
64 bytes from 8.8.8.8: icmp_seq=85 ttl=119 time=4.97 ms
64 bytes from 8.8.8.8: icmp_seq=86 ttl=119 time=5.28 ms
64 bytes from 8.8.8.8: icmp_seq=87 ttl=119 time=5.31 ms
64 bytes from 8.8.8.8: icmp_seq=88 ttl=119 time=5.84 ms
64 bytes from 8.8.8.8: icmp_seq=89 ttl=119 time=6.03 ms
64 bytes from 8.8.8.8: icmp_seq=90 ttl=119 time=5.52 ms
64 bytes from 8.8.8.8: icmp_seq=91 ttl=119 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=92 ttl=119 time=5.52 ms
64 bytes from 8.8.8.8: icmp_seq=93 ttl=119 time=6.55 ms
64 bytes from 8.8.8.8: icmp_seq=94 ttl=119 time=5.50 ms
64 bytes from 8.8.8.8: icmp_seq=95 ttl=119 time=5.48 ms
64 bytes from 8.8.8.8: icmp_seq=96 ttl=119 time=9.77 ms
64 bytes from 8.8.8.8: icmp_seq=97 ttl=119 time=7.63 ms
64 bytes from 8.8.8.8: icmp_seq=98 ttl=119 time=5.36 ms
64 bytes from 8.8.8.8: icmp_seq=99 ttl=119 time=6.48 ms
64 bytes from 8.8.8.8: icmp_seq=100 ttl=119 time=6.78 ms

lijst van ip’s die nvidia gebruikt:

https://ipinfo.io/AS50889/80.84.163.0/24

Per sessie kan het anders zijn maar valt terug te vinden in die lijst. Dit is dan de dichtstbijzijnde data centrum vanuit Nederland. 

M
  • miguelmurgia
  • Debutant
  • 2 reacties
  • 5 november 2020

Ik heb hetzelfde probleem. De speedtest via wifi en ethernet is snel genoeg maar bij Geforce Now heb ik lage bandbreedte en packet loss. Overigens heb ik hetzelfde probleem bij Xbox cloud gaming. 
 

Heb jij al een oplossing gevonden? De T-Mobile en Geforce klantenservice konden mij niet helpen. 

E
1 persoon vindt dit leuk
  • E
    EduardA
G
Odido
Forum|alt.badge.img+16
  • GinnyOdido
  • Oud-Moderator
  • 619 reacties
  • 8 november 2020

Hoi @miguelmurgia, zou je eens wat serveradressen willen delen, zoals hierboven? Dan kijken we graag met je mee! @Hidden.nld Ben jij in de gelegenheid om hier eens naar te kijken? Dankjewel!

Ik ben per 01-01-2023 niet meer werkzaam als Moderator op de Community. Ik zal eventuele privéberichten daarom niet meer kunnen beantwoorden maar mijn collega's helpen je graag!
Boris
1 persoon vindt dit leuk
  • Boris
    Boris
Hidden.nld
Super User
Forum|alt.badge.img+4
  • Hidden.nldSuper User
  • Odido Superuser
  • 3596 reacties
  • 8 november 2020

probeer pingplotter eens. wellicht kan je dan zien waar de loss zit

Heeft geen glazenbol.
Boris
B
2 mensen vinden dit leuk
  • Boris
    Boris
  • B
    billiedehamster
E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 12 november 2020
My traceroute  [v0.94]

MacBook-Pro.lan (192.168.1.161) -> 77.111.251.136      2020-11-03T13:06:23+0100

Keys:  Help   Display mode   Restart statistics   Order of fields   quit

                                       Packets               Pings

 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. openwrt.lan                       8.9%   236    3.7   5.0   2.5  17.9   2.6

 2. 1-72-146-85.ftth.glasoperator.nl  0.0%   236    5.1   7.3   4.4  21.2   2.8

 3. 10.10.10.205                      0.0%   236    6.2   7.4   5.0  18.0   2.2

 4. 10.10.10.197                      0.0%   236    6.2   7.8   5.0  20.9   2.8

 5. ae44-xcr1.att.cw.net              0.4%   236    7.3   9.7   5.3  42.6   5.7

 6. zayo-gw-xcr1.att.cw.net           0.4%   236   23.7   8.2   5.1  35.2   3.9

 7. ae9.cs1.ams17.nl.eth.zayo.com    21.2%   236    6.8   8.2   5.5  24.2   2.7

 8. ae7.er1.ams13.nl.zip.zayo.com     6.4%   236    5.7   7.9   5.2  25.4   2.7

 9. 77.111.251.17                     0.0%   235   21.3   8.2   5.5  22.9   3.2

10. 77.111.251.136                    0.0%   235   13.5   8.1   5.3  20.3   3.0

77.111.251.17 is de Nvidia server. We zien hier dat het gruwelijk mis gaat bij zayo. Is dit een T-Mobile Thuis partij? 

Die 8,9% komt zeer waarschijnlijk doordat het verder in de lijn mis gaat. Zoals je eerder hebt gezien heb ik geen last van packet loss.

 

@Hidden.nld @Ginny 

 IP heb tik 0evens achterhaald via de webbrowser in steam client in de geforce now VM

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 12 november 2020
miguelmurgia schreef:

Ik heb hetzelfde probleem. De speedtest via wifi en ethernet is snel genoeg maar bij Geforce Now heb ik lage bandbreedte en packet loss. Overigens heb ik hetzelfde probleem bij Xbox cloud gaming. 
 

Heb jij al een oplossing gevonden? De T-Mobile en Geforce klantenservice konden mij niet helpen. 

Nee maar ben wel een beetje doorgekomen bij Nvidia. Die stellen het volgende:

 

From your logs we don't see any problem with our GFN service so its not a bug that is causing your issue. The problem is with your local network which can be a result a bad cable/router. Per our Engineering, "The data shows that user has very high BW , but it has bursty packet loss.  Some of the sessions also show periodic packet loss every 500 frames or so that can be due to other local traffics or router scanning."

 

Dit doet denken dat er packages incompleet aankomen en dat ze bijvoorbeeld onterecht worden afgekapt. Misschien dat er bij de MTU auto negotiation iets mis gaat. Dat zou bijvoorbeeld een reden kunnen zijn waarom die packages verloren gaan (en past ook bij het beeld dat Nvidia ziet).

 

@Hidden.nld @Ginny 

Kunnen we dit op 1 of andere manier nagaan?

B
1 persoon vindt dit leuk
  • B
    billiedehamster
M
  • miguelmurgia
  • Debutant
  • 2 reacties
  • 15 november 2020

Target Name: 77.111.251.17
         IP: 77.111.251.17
  Date/Time: 11/15/2020 3:12:53 PM - 11/15/2020 3:22:53 PM

Hop     Sent  PL%   Min      Max       Avg     Host Name / [IP]
  1       26       0       1.59      3.12      2.10     home [192.168.1.1]
  2       26       0       5.90     10.69     6.56     1-160-144-85.ftth.glasoperator.nl [85.144.160.1]
  3       26       0       9.69     11.62     10.28   10.10.10.205 [10.10.10.205]
  4       26       0       8.42      9.94      9.17     10.10.10.197 [10.10.10.197]
  5       26       0       9.28     11.60     9.99     ae44-xcr1.att.cw.net [195.2.20.74]
  6       26       0       8.91     15.75     9.95     zayo-gw-xcr1.att.cw.net [195.2.24.214]
  7       26      35      9.62     14.47    10.51    ae9.cs1.ams17.nl.eth.zayo.com [64.125.31.10]
  8       26      15      9.81     10.33    10.08    ae7.er1.ams13.nl.zip.zayo.com [64.125.26.147]
  9       25       0       9.74     11.96    10.53    77.111.251.17 [77.111.251.17]

 

Hier zijn mijn pingplotter resultaten. Hebben jullie nog meer info nodig? (ik heb er niet extreem veel verstand van namelijk)

Bij mij gaat het volgens mij ook mis bij zayo.

Hidden.nld
Super User
Forum|alt.badge.img+4
  • Hidden.nldSuper User
  • Odido Superuser
  • 3596 reacties
  • 15 november 2020

@miguelmurgia ja daar lijkt het wel op. 

Dat zal Nvidia moeten oplossen. het is de link tussen hun en Zayo waar het mis gaat.

Wellicht dat T-Mobile hier in iets kan betekenen. dat durf ik niet te zeggen. maar gezien ze in Amsterdam zitten verwacht ik wel dat ze op de AMS-IX zitten. als T-Mobile een pering zou opzetten met AS50889 zal dit ongetwijfeld beter werken.

Heeft geen glazenbol.
B
1 persoon vindt dit leuk
  • B
    billiedehamster
A
  • Anonymous
  • 0 reacties
  • 15 november 2020
Hidden.nld schreef:

@miguelmurgia ja daar lijkt het wel op. 

Dat zal Nvidia moeten oplossen. het is de link tussen hun en Zayo waar het mis gaat.

Wellicht dat T-Mobile hier in iets kan betekenen. dat durf ik niet te zeggen. maar gezien ze in Amsterdam zitten verwacht ik wel dat ze op de AMS-IX zitten. als T-Mobile een pering zou opzetten met AS50889 zal dit ongetwijfeld beter werken.

Nvidia (AS50889) zit zo te zien niet op de AMS-IX maar alleen achter Transit partijen ( een Russische IX) Vandaar dat het verkeer ook via CW en Zayo gaat. 

TM doet alleen transit met CW, Level3 en HE. Dit zou inderdaad door Nvidia moeten worden opgelost gezien die werken met Zayo. 

 

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 18 november 2020
TechRacing93 schreef:
Hidden.nld schreef:

@miguelmurgia ja daar lijkt het wel op. 

Dat zal Nvidia moeten oplossen. het is de link tussen hun en Zayo waar het mis gaat.

Wellicht dat T-Mobile hier in iets kan betekenen. dat durf ik niet te zeggen. maar gezien ze in Amsterdam zitten verwacht ik wel dat ze op de AMS-IX zitten. als T-Mobile een pering zou opzetten met AS50889 zal dit ongetwijfeld beter werken.

Nvidia (AS50889) zit zo te zien niet op de AMS-IX maar alleen achter Transit partijen ( een Russische IX) Vandaar dat het verkeer ook via CW en Zayo gaat. 

TM doet alleen transit met CW, Level3 en HE. Dit zou inderdaad door Nvidia moeten worden opgelost gezien die werken met Zayo. 

 

Hangt ervan af, als T-Mobile ICMP berichten blokkeert vanuit zayo dan kan je ook stellen dat dit aan T-Mobile ligt. Daarnaast heeft T-Mobile in mijn eigen ervaring eerder problemen gehad met Path MTU Discovery (zie ook de topics over Netflix + Android TV/Nvidia Shield). Maar goed het is nu voornamelijk speculeren zonder dat dit onder ogen komt bij de juiste persoon binnen T-Mobile (e.g. een infra/netwerk specialist). Idem bij Nvidia, ze hebben mijn issue aan het engineering team voorgelegd die terug communiceert dat ze inderdaad package loss zien in de game sessies….. (wederom een infra/network specialist kan hier iets zinnigers over zeggen).

Dus wederom onze smeekbede @Ginny kan dit onder aandacht worden gebracht bij iemand die bovenstaande kan onderzoeken?

B
1 persoon vindt dit leuk
  • B
    billiedehamster
E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 20 november 2020

Ik heb trouwens dit onder de aandacht gebracht van Nvidia via hun support forum:

 

https://www.nvidia.com/en-us/geforce/forums/support/413855/geforce-now-low-bitratehigh-package-loss-due-to-is/

 

Het zou helpen als men dit kan up- voten indien ze een account hebben. De kans is dan beter aanwezig dat het onder de aandacht komt bij Nvidia.

 

(je kan ook proberen een support ticket aan te maken maar de kans is groot dat die in het soep loopt of weken lang gaat duren)

Boris
Odido
  • BorisOdido
  • Oud-Moderator
  • 2462 reacties
  • 27 november 2020

Hey @EduardA ,

Ik ben erg benieuwd wat de terugkoppeling van Nvidia is. Kan je ons een korte samenvatting geven? Wat @Hidden.nld zegt heeft namelijk veel voet in de aarde. Ik ben nieuwsgierig naar het antwoord van Nvidia.

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 27 november 2020
Boris schreef:

Hey @EduardA ,

Ik ben erg benieuwd wat de terugkoppeling van Nvidia is. Kan je ons een korte samenvatting geven? Wat @Hidden.nld zegt heeft namelijk veel voet in de aarde. Ik ben nieuwsgierig naar het antwoord van Nvidia.

@Boris 

De support ticket komt weinig uit behalve dat ze geen problemen zien in hun lokale sessies. Via de support forum geven ze aan dat het niet ligt aan bijv. MTU Path Discovery maar aan datacongestie bij T-Mobile. Ze stellen dat het mogelijk is dat er bij ISP’s geen Quality of Service maatregelen zijn om datacongestie te voorkomen bij dit soort UDP verkeer. Iets waar bijvoorbeeld TCP wel in voorziet, vandaar dat ander internet verkeer wel goed gaat. Verder is Zayo hun ISP maar ze hebben niet direct controle over hun netwerk. 

Oftewel Nvidia stuurt pakketten die te veel en te groot zijn voor de hardware van T-Mobile om goed af te handelen en in het protocol zijn er geen algoritmes opgenomen om het te managen.

 

edit: Kastje → Muur

Jason van Odido
Moderator
Forum|alt.badge.img+16
  • Jason van Odido
  • Community Manager
  • 10763 reacties
  • 2 december 2020

Hoi @EduardA, bedankt voor je terugkoppeling! 

In principe kunnen wij aan onze kant niet zoveel wijzigen in jouw situatie, maar gelukkig zie ik dat mijn collega van de Klantenservice voor hulp heeft aangeklopt bij de technische dienst. Hun verwerkingstijd bedraagt momenteel maximaal twaalf dagen. Heb je het Draytekmodem aangesloten op het FTU (glasvezelaansluitpunt)? Zo niet, wanneer ons modem niet aangesloten is, kan er geen lijnmeting gedaan worden om jouw packetloss situatie te analyseren. 

Meld je nu aan voor de Community Open Dag: https://community.odido.nl/nieuws-552/open-dag-community-odido-2025-375250
E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 2 december 2020
Jason schreef:

Hoi @EduardA, bedankt voor je terugkoppeling! 

In principe kunnen wij aan onze kant niet zoveel wijzigen in jouw situatie, maar gelukkig zie ik dat mijn collega van de Klantenservice voor hulp heeft aangeklopt bij de technische dienst. Hun verwerkingstijd bedraagt momenteel maximaal twaalf dagen. Heb je het Draytekmodem aangesloten op het FTU (glasvezelaansluitpunt)? Zo niet, wanneer ons modem niet aangesloten is, kan er geen lijnmeting gedaan worden om jouw packetloss situatie te analyseren. 

@Jason 

Ik heb ook telefonisch contact gehad en daarvoor heb ik de draytek terug gezet zodat ze een lijnmeting konden uitvoeren. Uit de lijnmeting kwam niks naar boven.  

Ik vind het niet erg om even de draytek terug te plaatsen voor een lijnmeting oid maar voor dagelijks gebruik is het niet goed genoeg (zie andere topic die ik heb gemaakt).

Maar goed, het lijkt erop dat dit probleem heeft te maken met game streaming services en hoe het T-Mobile netwerk ermee om gaat. Gisteren toevallig uitgeprobeerd op het netwerk van me buurman (die heeft KPN adsl) en dat ging stukken beter (een 20mbps lijntje en ik zat op wifi ipv ethernet).

 

Dus ik hoop dat de technische dienst serieus gaat kijken naar of er daadwerkelijk sprake is van datacongestie of dat er misschien iets anders speelt binnen het netwerk en zich niet doodstaart op een lijnmeting.

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • Antwoord
  • 18 december 2020
Jason schreef:

Hoi @EduardA, bedankt voor je terugkoppeling! 

In principe kunnen wij aan onze kant niet zoveel wijzigen in jouw situatie, maar gelukkig zie ik dat mijn collega van de Klantenservice voor hulp heeft aangeklopt bij de technische dienst. Hun verwerkingstijd bedraagt momenteel maximaal twaalf dagen. Heb je het Draytekmodem aangesloten op het FTU (glasvezelaansluitpunt)? Zo niet, wanneer ons modem niet aangesloten is, kan er geen lijnmeting gedaan worden om jouw packetloss situatie te analyseren. 

Daarnet een onwijs frustrerend gesprek gehad met de t-mobile klantenservice. Technische dienst stelt dat ze geen game streaming diensten ondersteunen bij T-Mobile Thuis, ik raakte daar eerlijk gezegd enigzins geirriteerd over omdat ze blijkbaar niet eens de moeite hebben gedaan om dit echt te testen (e.g. kijken of UDP verkeer goed wordt afgehandeld). Heb het eigenlijk een beetje gehad hiermee. Ik ga het opzeggen en overstappen. Deze topic kan je sluiten.

E
  • EduardAis een Master Poster
  • Auteur
  • Doet lekker mee
  • 23 reacties
  • 22 januari 2021

Voor de mensen die interesse hebben in een oplossing. Sinds kort zit ik bij KPN, daar ondervind ik deze problemen niet. Dus mijn vermoedens (data congestie door goedkope hardware T-Mobile of geen traffic shaping) blijken te kloppen.

N
1 persoon vindt dit leuk
  • N
    nikitapashinsky
J
  • JNSQ
  • heeft eerste post geplaatst
  • 1 reactie
  • 24 oktober 2021

Hoi allemaal,

 

Ik post ook nog even iets in dit topic omdat ik met hetzelfde probleem zit (Tmobile Thuis xDSL, Zyxel T50, alles bedraad direct op modem).

Vorige week zat ik nog bij KPN (ook DSL, over dezelfde lijn) en was alles prima in orde.

 

Als ik een speedtest doe via Ookla is er geen probleem en haal ik 96/30 met een ping van 9.

Als ik een speedtest naar Nvidia doe heb ik een packetloss van 5-15%.

Doe ik de test naar Nvidia via 4G (ook T-mobile) , dan is de packetloss weg.

 

Zit het probleem hier weer verderop in de verbinding of zou het aan de Zyxel kunnen liggen?

 

Naar Geforce Now

Target Name: 77.111.251.17
         IP: 77.111.251.17
  Date/Time: 24/10/2021 08:46:44 - 24/10/2021 08:56:44

Hop  Sent  PL%   Min    Max   Avg  Host Name / [ip]
  1    38   71  0,64   3,37  1,19  home [192.168.1.1]
  2    39   21  6,00  10,57  7,32  1-160-144-85.ftth.glasoperator.nl [85.144.160.1]
  3    39   18  6,00   8,68  7,11  10.10.10.205 [10.10.10.205]
  4    39   18  6,00  11,00  7,38  10.10.12.57 [10.10.12.57]
  5    39   21  7,00  27,55  9,55  195.89.101.53 [195.89.101.53]
  6    39   21  7,28   8,81  8,13  adm-b1-link.ip.twelve99.net [62.115.154.136]
  7    39   21  7,00  12,56  8,55  adm-bb4-link.ip.twelve99.net [62.115.137.64]
  8    39   21  7,65  11,61  8,35  adm-b2-link.ip.twelve99.net [62.115.141.37]
  9    39   31  7,54   9,50  8,07  nvidia-ic350991-adm-b2.ip.twelve99-cust.net [62.115.182.181]
 10    39   21  4,71  12,78  8,06  77.111.251.17 [77.111.251.17]

 

Naar Nu.nl

Target Name: nu.nl
         IP: 104.110.191.41
  Date/Time: 24/10/2021 08:59:15 - 24/10/2021 09:09:15

Hop  Sent  PL%   Min     Max    Avg  Host Name / [ip]
  1    28   86  0,80  103,19  26,41  home [192.168.1.1]
  2    32    0  4,52   95,82  14,30  1-160-144-85.ftth.glasoperator.nl [85.144.160.1]
  3    32    0  6,63   82,41  11,75  10.10.10.205 [10.10.10.205]
  4    32    0  6,00   69,60  10,03  10.10.12.57 [10.10.12.57]
  5    31  100     0       0      0   [-]
  6    32    0  7,00   42,31   8,53  192.168.224.1 [192.168.224.1]
  7    32    0  7,00   28,61   8,14  192.168.233.129 [192.168.233.129]
  8    32    3  7,04   15,79   7,75  192.168.241.21 [192.168.241.21]
  9    32    0  7,00  122,70  21,40  nu.nl [104.110.191.41]

 

Naar GeforceNow via 4G

Target Name: 77.111.251.17
         IP: 77.111.251.17
  Date/Time: 24/10/2021 09:11:00 - 24/10/2021 09:21:00

Hop  Sent  PL%    Min    Max    Avg  Host Name / [IP]
  1    23   83   2,00   3,65   3,05  192.168.231.213 [192.168.231.213]
  2    27  100      0      0      0   [-]
  3    27  100      0      0      0   [-]
  4    27  100      0      0      0   [-]
  5    27  100      0      0      0   [-]
  6    28    0  17,00  40,76  25,29  84.241.225.42 [84.241.225.42]
  7    28    0  20,56  58,33  27,56  80.157.130.241 [80.157.130.241]
  8    28    0  19,46  39,22  24,09  80.156.162.118 [80.156.162.118]
  9    28    0  20,70  52,63  26,21  ae9.cs1.ams17.nl.eth.zayo.com [64.125.31.10]
 10    28    0  21,33  37,58  26,49  ae7.er1.ams13.nl.zip.zayo.com [64.125.26.147]
 11    28    0  21,18  43,47  26,90  77.111.251.17 [77.111.251.17]

 

Als ik met Analiti een check doe zie ik ook veel fouten bij de DNS-name query, bij KPN was dit ook gewoon 100%.

 

N
1 persoon vindt dit leuk
  • N
    nikitapashinsky
D
  • Dzmkalo24
  • is een Top Poster
  • 8 reacties
  • 23 augustus 2024

I can confirm that switching to alternative ISP helped me with the same problem. More details in my reddit post https://www.reddit.com/r/GeForceNOW/comments/1eew0bu/error_0x80120001_eu_northeast_macos/

N
1 persoon vindt dit leuk
  • N
    nikitapashinsky

Reageer


ForumvoorwaardenCookie instellingen

Cookiebeleid

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.

 
Cookie instellingen