Userbase

Heeft iemand hier een idee waarom alle google diensten naar AMS geroute worden bij Telenet? Bij proximus haal ik 12ms (bij iemand die niet de beste omstandigheden heeft - 75/15 verbinding) en hier (Telenet business 240/30) haal ik ~40ms.
8.8.8.8:

Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 70 0.3 0.5 0.3 5.8 0.6
2. 178-119-228-1.access.telenet.be 0.0% 70 16.9 17.4 9.8 72.0 11.5
3. dD5E0CE62.access.telenet.be 0.0% 70 15.2 13.8 8.7 24.0 2.9
4. dD5E0FA75.access.telenet.be 0.0% 70 16.0 16.2 12.7 22.9 2.5
5. dD5E07D05.access.telenet.be 0.0% 70 42.6 37.7 32.2 64.9 5.0
6. ???
7. 209.85.241.115 0.0% 69 34.7 38.3 33.0 53.8 3.9
8. google-public-dns-a.google.com 0.0% 69 33.8 34.9 31.5 42.7 2.6

Google IPv6:
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. xxxxxxxxxxxx.ip6.access.telenet.be 0.0% 26 0.3 0.4 0.3 0.6 0.0
2. ptr-377wh5apd8gqeke8lf5t.18120a2.ip6.access.telenet.be 0.0% 26 15.2 15.9 10.5 47.2 9.4
3. ???
4. 2a020:1207:0:3 42.3% 26 13.5 16.2 13.2 23.6 2.8
5. 2a020:1207:0:3 0.0% 26 40.9 27.8 13.7 40.9 9.8
2a0210:5
6. 2a0210:5 0.0% 26 33.3 35.7 31.6 42.2 2.7
2001:4860:0:2
7. 2001:4860:0:2 0.0% 26 42.5 39.7 33.3 48.0 4.4
2001:4860::8:0:cb95
8. 2001:4860::8:0:cb95 0.0% 26 42.8 42.6 38.3 52.4 3.0
2607:f8b0:e000:8000::4
9. 2607:f8b0:e000:8000::4 44.0% 25 51.4 44.0 39.9 51.4 3.8
2607:f8b0:e000:8000::3
10. 2607:f8b0:e000:8000::3 12.0% 25 41.9 43.5 39.5 50.3 2.8
2001:4860:0:1::155d
11. 2001:4860:0:1::155d 0.0% 25 38.4 42.2 38.4 48.3 2.9
ams15s22-in-x03.1e100.net
12. ams15s22-in-x03.1e100.net 0.0% 25 41.0 42.3 36.7 63.1 5.2

Google (IPv4):
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 4 0.4 0.4 0.3 0.4 0.0
2. 178-119-228-1.access.telenet.be 0.0% 4 11.5 12.6 11.0 16.2 2.3
3. dD5E0CA62.access.telenet.be 0.0% 4 11.9 12.3 10.6 14.2 1.3
4. dD5E0FA75.access.telenet.be 0.0% 4 16.2 15.1 13.6 16.2 0.8
5. dD5E07D05.access.telenet.be 0.0% 4 32.8 33.9 32.8 36.3 1.4
6. 108.170.251.208 0.0% 4 31.9 33.5 31.9 35.0 1.3
7. 108.170.226.3 0.0% 3 33.3 36.0 33.3 40.3 3.7
8. 209.85.244.158 0.0% 3 40.7 41.0 40.0 42.3 1.0
9. 216.239.42.212 0.0% 3 42.3 44.3 42.3 45.6 1.7
10. 108.170.241.129 0.0% 3 44.1 45.8 39.3 53.9 7.4
11. 216.239.42.71 0.0% 3 40.7 39.8 38.6 40.7 1.0
12. ams15s22-in-f163.1e100.net 0.0% 3 45.2 40.5 37.7 45.2 4.0




Toen ik toch eens de back-end dienst moest contacteren heb ik dit gevraagd, nooit antwoord terug gehad.
(Zelfs niet voor met wat ik problemen had terwijl een andere persoon tehoren kreeg dat een 2 maand lang routing probleem (150+ms in de avond was zelfs eens 400+) aan een "kaart" lag...)

^ ik heb maar ~25ms latency vanop Telenet. Uw jump in latency is trouwens in het TN netwerk.

Over het waarom: ik vermoed dat Google daar een node heeft staan die direct aan de Liberty Global backbone zit, waardoor de latency in principe laag genoeg is om vanaf daar TN en Nederland en eventueel nog buurlanden te bedienen (gaat uiteindelijk over kleine geografische afstanden). ~25ms is niet meteen slecht te noemen.

Voor Proximus zullen ze wellicht wel een node in het datacentrum van Proximus hebben staan als je daar 12ms krijgt.

Naar nederland krijg ik veel lagere latency, meestal 20 - 25ms, dus ik snap niet waarom het hier om soms zelfs het dubbele gaat.

't is de link tussen dD5E0FA75 en dD5E07D05 die het probleem vormt, niet de link naar Amsterdam. Ik passeer die link niet, dus geen last van. Zal regiogebonden zijn.

Eventueel TN eens contacteren met die traceroutes.

Op uw IPv6 zit ook een packet loss.

CCatalyst schreef:Eventueel TN eens contacteren met die traceroutes.

Op uw IPv6 zit ook een packet loss.

Daar lachen ze mij gewoon uit en heb ik al gedaan, paar maanden geleden dacht ik, nog geen antwoord.

Telenet heeft een rechtstreekse link met google.
Maar waar ze die link hebben is niet duidelijk, het is niet in amsterdam, want de latency weerlegt dat.
Het is gokken, maar zuiver latency-wise, lijkt de verbinding naar google in dublin te lopen.

Dat sommige hops in een traceroute niet altijd replyen op icmp, wil daarom niet zeggen dat de verbinding niet optimaal is.
Veel routers (de hops dat je ziet) hebben limieten op het aantal icmp aanvragen te beantwoorden.

Vr gr
Dries

Ik haal op Telenet hier toch ook een 10 à 14 ms, ping geeft gelijkaardige resultaten.

Hier 7 hops van TN router -> 8.8.8.8

gem. van 35ms hier ook

't lijkt dat de 8.8.8.8 (en 8.8.4.4) niet representatief is voor de rest van Google.

Ik haal ook 10 ms op die IP's, terwijl ik op www.google.com ~25 haal.

Die DNS'en zijn toch anycast?
https://developers.google.com/speed/public-dns/faq

Nu heb ik net even een test gedaan:



Voor:


Na:


Het gaat ongeveer met 10ms omlaag als ik een static IP gebruik...?

Wat mij opvalt is dat er nu geen telenet link is die hogere latency heeft (zie oude traceroute bij een oudere reactie).

Uw afbeeldingen geven 404. Gebruik imgur oid in de plaats.

Mijn latency was ook berekend vanaf een statisch IP.

CCatalyst schreef:Uw afbeeldingen geven 404. Gebruik imgur oid in de plaats.

Raar, toen ik ze hier plaatste werkte het

Edit: Opgelost.

Hier vandaag gem van 42ms :O

Hier totaal geen probleem... wireless test vanaf een TN Whoppa met modem-only;

172.217.17.132 op deze haal ik 49ms gem.
(11 hops)

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 36ms, Maximum = 37ms, Average = 36ms
Telkens 1 lost

En nog eens even Dynamic (L) vs Static (R) naast elkaar op exact hetzelfde tijdstip:



Het static IP legt een langere route af. (als in kabels lokaal)

buthead schreef:Packets: Sent = 4, Received = 3, Lost = 1 (25% loss)

Ow, je hebt zelfs packet loss... misschien toch eens contact opnemen met TN ?

Test je dit trouwens rechtstreeks op je HGW ?

datakiller schreef:En nog eens even Dynamic (L) vs Static (R) naast elkaar op exact hetzelfde tijdstip:

Maar beide zijn pingtijden die het dubbele zijn als bij mij ?

Gaat het hier in beide gevallen over een een HGW of is de static via een modem-only ?

r2504 schreef:Gaat het hier in beide gevallen over een een HGW of is de static via een modem-only ?

Beide testen zijn gedaan met een modem-only op dezelfde tijd.

Dynamic IP: Modem-only -> Switch -> Server

Static IP: Modem-only -> Switch -> Server (virtual router) -> Switch (LAN) -> Server

Het verschil is meestal 5 - 10ms, ik vraag me af welke praktijken Telenet hier nu weer voor gebruikt... (Latency naar mijn mailserver in Roemenie ging ook met 10ms omlaag met mijn static IP).

driesp schreef:Het is gokken, maar zuiver latency-wise, lijkt de verbinding naar google in dublin te lopen.

Ik ga mijn woorden terugtrekken, waarschijnlijk zit die link wat vol.
Want dat kan natuurlijk ook invloed hebben op de latency.

Misschien hebben ze meerdere poorten met google.

Om even duidelijk te zijn… alles rechts van je "modem only" is jou lokaal netwerk ?

Dan lijkt het dat je zelf verantwoordelijk bent voor die vertraging van 5 a 10 ms.

Test eens met een PC rechtstreeks op je HGW.

r2504 schreef:Dan lijkt het dat je zelf verantwoordelijk bent voor die vertraging van 5 a 10 ms.

Dynamic IP: Modem-only -> Switch (niet lokaal) -> Server (niet lokaal)

Static IP: Modem-only -> Switch (niet lokaal) -> Server (virtual router) -> Switch (LAN) -> Server

En het static IP heeft minder latency dan het dynamic IP, het static IP gaat langs mijn local netwerk en legt exact dezelfde route af (tot aan de server dan).

De routing is wel verandert:

Bij het dynamic IP is er een telenet hop die 20ms is en degene erna 38ms, bij het static IP heb ik deze niet, laatste telenet hop is daarbij 15ms, geen 38.

datakiller schreef:Dynamic IP: Modem-only -> Switch (niet lokaal) -> Server (niet lokaal)

Static IP: Modem-only -> Switch (niet lokaal) -> Server (virtual router) -> Switch (LAN) -> Server

Ik ben niet meer mee... wat bedoel je met "niet lokaal" ? Geef eens wat achtergrond van je setup.

datakiller schreef:En het static IP heeft minder latency dan het dynamic IP, het static IP gaat langs mijn local netwerk en legt exact dezelfde route af (tot aan de server dan).

Hoe je een IP verkrijgt maakt totaal niets uit (tenzij je hier spreekt over je WAN IP-adres van je modem only).

datakiller schreef:Bij het dynamic IP is er een telenet hop die 20ms is en degene erna 38ms, bij het static IP heb ik deze niet, laatste telenet hop is daarbij 15ms, geen 38.

De ping tijden van tussen liggende hops zijn totaal NIET relevant (zelfs van je eigenlijke bestemming niet).

In theorie kan het dat een ping naar de Google DNS 500 ms in beslag neemt maar dat de DNS request op 10 ms antwoord geeft.

Lets try it again:

Niet lokaal is een switch die direct achter de modem-only hangt (en dus niet 192.168.0.xxx) waar ik dus mijn digicorder, router, test routers etc op aansluit.

Een modem-only heeft geen WAN IP (hopelijk) en blijkbaar maakt het wel wat uit hoe ik mijn IP verkrijg, want met een static IP heb ik 10ms minder latency.

De google DNS is 2 - 4x trager als cloudflare/Telenet DNS...


Edit:
Dit is miss wat makkelijker?
Ik heb de server niet direct op de LAN poort van de virtuele router omdat het makkelijker is om een andere router te gebruiken met mijn setup.
Volgens jouw redenering zou het static IP hogere latency moeten hebben dan het dynamic IP.

datakiller schreef:Niet lokaal is...

Wat mij betreft is dat allemaal lokaal… het is jou apparatuur die achter een modem-only staat.

Alle verschillen zijn dus puur aan JOU EIGEN configuratie te wijten

datakiller schreef:Volgens jouw redenering zou het static IP hogere latency moeten hebben dan het dynamic IP.

Waar lees je dat... ik zeg dat het niet uitmaakt hoe je een IP-adres krijgt... alles wat van jou modem-only vertrekt moet dezelfde latency hebben.

r2504 schreef:Waar lees je dat...

r2504 schreef:Dan lijkt het dat je zelf verantwoordelijk bent voor die vertraging van 5 a 10 ms.

Het dynamic IP heeft 10ms hogere latency dan mijn static IP die door mijn router gaat + extra switch.

r2504 schreef:Alle verschillen zijn dus puur aan JOU EIGEN configuratie te wijten

Van IP veranderen haalt de latency naar google etc met 10ms omlaag, zoals je ziet op mijn grafieken, dat was met exact dezelfde configuratie.

Telenet HGW -- Switch TP-link TL-SG108E -> PC of etc..
vandaag ook getest, ga zo meteen is modem herstarten is enige tijd geleden nu.

Ander IP gekregen zie ik, maar nog zelfde aantal ms

driesp schreef:Waarschijnlijk zit die link wat vol.
Misschien hebben ze meerdere poorten met google.

Misschien announcen ze de residentiele ip ranges op de congested link met google,
en de IP ranges van de corporate klanten op de niet congested link.

Congestie heeft invloed op de latency.
Volgens mij verklaart dit het. Maartoch, blijft speculatie, zeker weten doe ik dat niet.

buthead schreef:Ander IP gekregen zie ik, maar nog zelfde aantal ms

Het verschil zit hier bij Static IP vs Dynamic IP, als je een ander Dynamic IP krijgt is er geen verschil.

driesp schreef:Volgens mij verklaart dit het. Maartoch, blijft speculatie, zeker weten doe ik dat niet.

Dit gokte ik ook, maar toen ik laatst van static naar dynamic overstapte (om te testen was het toen) was de routing hetzelfde als de dynamic IP's, misschien hebben ze een aanpassing gedaan.

Ach ja het werkt het internet ..

buthead schreef:Ach ja het werkt het internet ..

Maja, idd, mensen zijn tevreden dat het werkt.
Dat een DNS lookup een paar ms langer duurt, ligt niemand wakker van.

driesp schreef:Dat een DNS lookup een paar ms langer duurt, ligt niemand wakker van.

Totdat het 400ms is

Kon het niet laten dit nog wat verder te testen

De boosdoener blijkt

dD5E07D05.access.telenet.be of 213.224.125.5 te zijn daar zie ik pieken tot wel 180ms soms rest ziet er gewoon goed uit

buthead schreef:Kon het niet laten dit nog wat verder te testen

Ik test ook altijd als ik wat op mijn smokeping zie (ping grafieken naar veel ISP's).
Maarja, als je de oorzaak aan Telenet zou melden, zouden ze nog niets doen, zelfs niet als het 400ms is en je internet 10mbps is
2 maanden later maak je miss kans als business klant (service!)

Ja eens gebeld naar telenet als biz klant met 4 pct packetloss (irritant op VoIP & ssh): "ja we zijn op de hoogte, probleem in straat kabel, hebben nog niets gedaan want jullie zijn de eerste die het melden"
Daarna nog 2 weken moeten wachten...

datakiller schreef:Het verschil zit hier bij Static IP vs Dynamic IP, als je een ander Dynamic IP krijgt is er geen verschil.

Heb jij dan een business abonnement ? Waarom neem je dan geen contact op met de business helpdesk ?

buthead schreef:De boosdoener blijkt
dD5E07D05.access.telenet.be of 213.224.125.5 te zijn daar zie ik pieken tot wel 180ms soms rest ziet er gewoon goed uit

Ping tijden van tussen liggende nodes bewijzen niets... het enige wat telt is je destination adres (en zelfs dat is relatief).

r2504 schreef:Heb jij dan een business abonnement ? Waarom neem je dan geen contact op met de business helpdesk ?

Ja, en daar lachen ze me uit als je snapt wat ik bedoel. Vorige keer werd ik doorgestuurt: KMO -> non business -> big business -> KMO.

Ik ben vergeten of ik mijn klanten nr al gegeven had maar zal hun gesprek nog eens beluisteren (auto call recorder).

welke biz abo heb jij?
volgens je speedtest signature ziet dat er wel iets crap uit...

ik begin altijd met m'n klantnummer als ik bel, dan weten ze meteen wat ik heb en gaat het sneller meestal

splinterbyte schreef:welke biz abo heb jij?

business fibernet 240

splinterbyte schreef:volgens je speedtest signature ziet dat er wel iets crap uit...

Tja, iedere avond, 2 maanden lang had ik dit, duurde ook 2 maanden om de back-end dienst te bereiken (toen het probleem voorbij was werd contact opgenomen met mij) real business service.

Nu heb ik wel 1 maand internet terugbetaalt gekregen omdat ik naar de ombuds dienst ging en test aankoop, maar als dit de volgende keer gebeurt word het voor hun per maand 2x de maandelijkse prijs (of meer).

Een andere persoon die hetzelfde probleem had (het lag aan een "kaart" ergens) kreeg een mini-PC in huis en daar vonden ze blijkbaar een tijd "niets" mee...

Maar uiteindelijk heeft een niet business klant betere service gekregen als de business klant.

Het probleem was van ~6(in de avond) tot ~10(in de avond) en meestal niet op zaterdag.

hmm misschien helpt dreigen dat je gaat opzeggen wel iets in zo'n geval.

ik heb ook biz 240+, nog niets gemerkt dat google traag is, net test gedaan op beiden dyn/static IPs en is ~10-14ms.
heb er geen constante monitoring op staan momenteel.