• Let op: Dit is het archief van het Provider Forum. De berichten die je hier ziet zijn gedateerd en er kan niet meer op worden gereageerd.

Latency en verbindings problemen

  • Onderwerp starter Onderwerp starter dutchdiver
  • Startdatum Startdatum
D

dutchdiver

Beste lezers,

Sinds maandag 6/7 heb ik problemen met mijn internet en telefonie verbinding.

Hieronder chronologisch wat er sinds 6/7 is gebeurd:

Dinsdag 7/7 gebeld met UPC bandje dat er een storing is in mijn woonplaats.

Woensdag 8/7 weer gebeld met UPC zelfde bandje dat er een storing is in mijn woonplaats.

Donderdag 9/7 gebeld met UPC een HD medewerker gesproken, echter die wist niet dat er een storing was in mijn woonplaats.
Ik heb het probleem uitgelegd:

Sinds maandag 6/7 treden er steeds DC's op, de ping waarde in het upc domein lopen op van rond 10 ms tot wel 5500 ms waardoor het internet er uit vliegt. Modem heeft dan geen signaal en start weer op. Telefonie valt uit of is niet bereikbaar.

Vrijdag 10/7 monteur komt langs ( keurig optijd) doet meetingen probleem zit niet aan mijn kant, er word gebeld met de 2 lijn die doen een lijn check en er word geconstateerd dat er veel packet verlies is en dat er veel ruis op de lijn zit.
Gezien het feit dat er meer mensen in de wijk dit probleem hebben wordt het een zgn collectief(= is een probleem die meer mensen hebben)Er word mij verteld dat een monteur in de wijk het probleem gaat oplossen en dat het zaterdag opgelost moet zijn.

Zaterdag 11/7 tja er was niets opgelost zelfde probleem.

Zondag 12/7 tja er was niets opgelost zelfde probleem.

Maandag 13/7 Maar weer met de HP gebeld, en gevraagd wanneer de storing word opgelost de helpdesk mederwerker wist mij te vertellen dat het in de nacht van zaterdag op zondag was gemaakt. Ik vertelde hem dat dit niet het geval was.
Deze medewerker vertelde me dat het dan aan mijn modem moest liggen en dat hij een nieuwe afspraak met een monteur ging maken. Ik vertelde deze medewerker dat het mijn inziens onmogelijk aan het modem kon liggen, en dat er beter een buiten monteur kon worden gestuurd. Helaas mijn modem moest worden vervangen( zonden van het geld).

Dinsdag 14/7 Monteur (netjes op tijd) heeft het modem vervangen, echter het duurde een paar uur voordat India? het modem had ingesteld.
En ja hoor het lag niet aan het modem, nog steeds het zelfde probleem.

Woensdag 15/7 Weer gebeld met de HD probleem weer van a tot z uitgelegd, de helpdesk medewerker ging het e.e.a uitzoeken en zou mij terug bellen. Na een 1.5 uur netjes terug gebeld! Deze medewerker vertelde mij precies het zelfde
n.l dat het probleem in de wijk zit en dat er een buiten monteur het probleem moet oplossen.
Woensdag avond was het zeer slecht het internet leek wel een knipperlicht totaal niet mee te werken.

Donderdag 16/7 Ik wacht vandaag nog af en wie weet word het eindelijk actie ondernomen.


Gezien wij fanatieke gamers( Counter strike, World of warcraft etc) zijn merken wij zeer snel op of de verbinding wel of niet stabiel is. (Snelheid ( DL 118Mbps/ UL 7Mbps) van de verbinding is ondergeschikt aan kwaliteit van de verbinding)

Ook mijn telefonie heeft dezelfde problemen, geen of slechte verbinding!

Voor 6/7 hadden wij nooit last van dit probleem!!!
(Ik denk dat ik nooit had moeten overstappen naar fiber power 120 mbit)

Word zeker vervolgd.

ps als er iemand tips of trucs heeft dan hoor ik dat graag.
 
Ik heb hier een leuke conclusie voor je.

Ik heb hier ook 120 Mbit van UPC. Maar ik heb naast dat ook nog xs4all ADSL gehouden.

Vroeger speelde ik nogal veel op de servers van blueyonder en zie hier de latency verschillen:

UPC:
PING www.blueyonder.co.uk (92.238.96.13) from 80.56.72.XXX eth2: 56(84) bytes of data.
64 bytes from 92.238.96.13: icmp_seq=1 ttl=115 time=135 ms
64 bytes from 92.238.96.13: icmp_seq=2 ttl=115 time=150 ms
64 bytes from 92.238.96.13: icmp_seq=3 ttl=115 time=165 ms
64 bytes from 92.238.96.13: icmp_seq=4 ttl=115 time=138 ms
64 bytes from 92.238.96.13: icmp_seq=5 ttl=115 time=145 ms
64 bytes from 92.238.96.13: icmp_seq=6 ttl=115 time=151 ms
64 bytes from 92.238.96.13: icmp_seq=7 ttl=115 time=142 ms
64 bytes from 92.238.96.13: icmp_seq=8 ttl=115 time=136 ms
64 bytes from 92.238.96.13: icmp_seq=9 ttl=115 time=131 ms
64 bytes from 92.238.96.13: icmp_seq=10 ttl=115 time=75.9 ms
64 bytes from 92.238.96.13: icmp_seq=11 ttl=115 time=122 ms

XS4ALL
PING www.blueyonder.co.uk (92.238.96.13) from 82.95.127.XXX eth0: 56(84) bytes of data.
64 bytes from 92.238.96.13: icmp_seq=1 ttl=118 time=31.5 ms
64 bytes from 92.238.96.13: icmp_seq=2 ttl=118 time=30.6 ms
64 bytes from 92.238.96.13: icmp_seq=3 ttl=118 time=30.0 ms
64 bytes from 92.238.96.13: icmp_seq=4 ttl=118 time=29.5 ms
64 bytes from 92.238.96.13: icmp_seq=5 ttl=118 time=29.8 ms
64 bytes from 92.238.96.13: icmp_seq=6 ttl=118 time=29.7 ms
64 bytes from 92.238.96.13: icmp_seq=7 ttl=118 time=30.2 ms
64 bytes from 92.238.96.13: icmp_seq=8 ttl=118 time=30.3 ms
64 bytes from 92.238.96.13: icmp_seq=9 ttl=118 time=30.0 ms
64 bytes from 92.238.96.13: icmp_seq=10 ttl=118 time=30.1 ms
64 bytes from 92.238.96.13: icmp_seq=11 ttl=118 time=29.9 ms

Conclusie: xs4all = 5x sneller dan UPC naar www.blueyonder.co.uk, en een stabiele ping

Nu een bestaande ID3.net server:

UPC:

PING 84.244.162.182 (84.244.162.182) from 80.56.72.XXX eth2: 56(84) bytes of data.
64 bytes from 84.244.162.182: icmp_seq=1 ttl=122 time=10.4 ms
64 bytes from 84.244.162.182: icmp_seq=2 ttl=122 time=130 ms
64 bytes from 84.244.162.182: icmp_seq=3 ttl=122 time=8.59 ms
64 bytes from 84.244.162.182: icmp_seq=4 ttl=122 time=8.63 ms
64 bytes from 84.244.162.182: icmp_seq=5 ttl=122 time=16.2 ms
64 bytes from 84.244.162.182: icmp_seq=6 ttl=122 time=15.0 ms
64 bytes from 84.244.162.182: icmp_seq=7 ttl=122 time=70.4 ms
64 bytes from 84.244.162.182: icmp_seq=8 ttl=122 time=9.25 ms
64 bytes from 84.244.162.182: icmp_seq=9 ttl=122 time=9.40 ms
64 bytes from 84.244.162.182: icmp_seq=10 ttl=122 time=14.3 ms

XS4ALL:
PING 84.244.162.182 (84.244.162.182) from 82.95.127.XXX eth0: 56(84) bytes of data.
64 bytes from 84.244.162.182: icmp_seq=1 ttl=122 time=10.0 ms
64 bytes from 84.244.162.182: icmp_seq=2 ttl=122 time=9.64 ms
64 bytes from 84.244.162.182: icmp_seq=3 ttl=122 time=9.09 ms
64 bytes from 84.244.162.182: icmp_seq=4 ttl=122 time=9.32 ms
64 bytes from 84.244.162.182: icmp_seq=5 ttl=122 time=9.05 ms
64 bytes from 84.244.162.182: icmp_seq=6 ttl=122 time=9.54 ms
64 bytes from 84.244.162.182: icmp_seq=7 ttl=122 time=9.09 ms
64 bytes from 84.244.162.182: icmp_seq=8 ttl=122 time=9.26 ms
64 bytes from 84.244.162.182: icmp_seq=9 ttl=122 time=9.04 ms
64 bytes from 84.244.162.182: icmp_seq=10 ttl=122 time=9.48 ms
64 bytes from 84.244.162.182: icmp_seq=11 ttl=122 time=9.07 ms

Conclusie: xs4all is een flink stuk stabieler dan UPC



Eindconclusie voor jouw:

Gamen en latency? Ga voor XS4all
Downloaden/Uploaden? UPC

En onthoud mensen: UPC mag wel adventeren met dat het sneller is dan ADSL. Dat is in een zin best waar. Maar het stukje vanaf hun eigen netwerk naar het internet zelf toe is niet bepaald sneller.

Waar XS4all genoeg bandbreedte voor hun klanten inkoopt. Zodat ze geen geld hoeven uit te geven aan de dure traffic shapers, waardoor hun netwerk gewoon netjes snel blijft.

UPC geeft het geld liever uit aan hardware traffic shapers, zodat er minder geld overblijft voor de inkoop van genoeg bandbreedte, kort gezegd dan. En uit diverse ervaring van ~6maanden met UPC en XS4all naast elkaar draaiend.
 
Even voor de duidelijkheid een hoge latency betekent niet per definitie dat er een gebrek is aan bandbreedte. Een veelgemaakte fout. Jouw conlcusie is daardoor niet waterdicht.
 
knuffa zei:
Even voor de duidelijkheid een hoge latency betekent niet per definitie dat er een gebrek is aan bandbreedte. Een veelgemaakte fout. Bovendien heb je maar een tweetal metingen uitgevoerd. Jouw conlcusie is daardoor niet waterdicht.

Het is maar 1 van de X factoren, dat weet ik ook.
En de tweetal metingen waren een moment opname, duh.
Maar dit mag een moment opname zijn. Ik ervaar al 6 maanden dat ik deze combo heb hetzelfde als wat deze twee metingen nu zeggen


Ik probeer het alleen een beetje begrijpbaar en simpeler hier te houden :)

Enough techtalk as it is :)
 
Ping zegt niets, dan weet je nog steeds niet waar het echte probleem is.
Doe eens een traceroute, dan zie je waar de echte bottleneck zit.

Bijvoorbeeld:
C:\>tracert 92.238.96.13

Tracing route to 92.238.96.13 over a maximum of 30 hops

1 7 ms 7 ms 5 ms 10.15.83.174
2 8 ms 6 ms 7 ms p11252.net.upc.nl [212.142.11.252]
3 11 ms 11 ms 11 ms p14211253.net.upc.nl [212.142.11.253]
4 11 ms 19 ms 19 ms nl-ams05a-ra3-ae-1-0.aorta.net [213.46.183.93]
5 13 ms 11 ms 12 ms nl-ams02a-ra1-ge-3-0-0-0.aorta.net [213.46.183.101]
6 21 ms 17 ms 17 ms uk-lon02a-rd1-so-14-0.aorta.net [213.46.160.237]
7 21 ms 19 ms 21 ms 213.46.174.169
8 20 ms 19 ms 21 ms uk-lon01a-ri4-so-9-0-0.aorta.net [213.46.174.174]
9 20 ms 21 ms 19 ms 213.46.174.70
10 21 ms 22 ms 19 ms nth-bb-b-as0-0.network.virginmedia.net [62.253.184.1]
11 91 ms 91 ms 29 ms man-bb-a-ae2-0.network.virginmedia.net [212.43.163.81]
12 26 ms 27 ms 26 ms cancun-pos30.network.virginmedia.net [213.105.175.214]
13 33 ms 32 ms 34 ms gsr01edin-pos00.network.virginmedia.net [194.117.136.214]
14 33 ms 33 ms 32 ms casablanca-pos130.network.virginmedia.net [194.117.136.209]
15 33 ms 33 ms 33 ms 92.238.96.13

Trace complete.
 
En om nu te zeggen dat je vanuit UPC geen stabiele ping daarop hebt, vind ik ook iets wat redelijk simpel te weerleggen is ;) :

ping is gestart ...

PING 92.238.96.13 (92.238.96.13): 56 data bytes
64 bytes from 92.238.96.13: icmp_seq=0 ttl=114 time=37.242 ms
64 bytes from 92.238.96.13: icmp_seq=1 ttl=114 time=36.945 ms
64 bytes from 92.238.96.13: icmp_seq=2 ttl=114 time=36.306 ms
64 bytes from 92.238.96.13: icmp_seq=3 ttl=114 time=36.596 ms
64 bytes from 92.238.96.13: icmp_seq=4 ttl=114 time=36.138 ms
64 bytes from 92.238.96.13: icmp_seq=5 ttl=114 time=36.075 ms
64 bytes from 92.238.96.13: icmp_seq=6 ttl=114 time=36.837 ms
64 bytes from 92.238.96.13: icmp_seq=7 ttl=114 time=36.042 ms
64 bytes from 92.238.96.13: icmp_seq=8 ttl=114 time=36.294 ms
64 bytes from 92.238.96.13: icmp_seq=9 ttl=114 time=36.315 ms

--- 92.238.96.13 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 36.042/36.479/37.242/0.388 ms

ping is gestart ...

PING 84.244.162.182 (84.244.162.182): 56 data bytes
64 bytes from 84.244.162.182: icmp_seq=0 ttl=121 time=16.959 ms
64 bytes from 84.244.162.182: icmp_seq=1 ttl=121 time=16.485 ms
64 bytes from 84.244.162.182: icmp_seq=2 ttl=121 time=16.433 ms
64 bytes from 84.244.162.182: icmp_seq=3 ttl=121 time=16.476 ms
64 bytes from 84.244.162.182: icmp_seq=4 ttl=121 time=16.291 ms
64 bytes from 84.244.162.182: icmp_seq=5 ttl=121 time=16.329 ms
64 bytes from 84.244.162.182: icmp_seq=6 ttl=121 time=16.123 ms
64 bytes from 84.244.162.182: icmp_seq=7 ttl=121 time=16.129 ms
64 bytes from 84.244.162.182: icmp_seq=8 ttl=121 time=16.063 ms
64 bytes from 84.244.162.182: icmp_seq=9 ttl=121 time=16.038 ms

--- 84.244.162.182 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 16.038/16.333/16.959/0.263 ms
 
Vandaag 17/7 weer met de helpdesk gebeld,
en gevraagd of de buitenmonteur al het probleem heeft gelokaliseerd.
De helpdesk medewerker kon daar niets over vertellen omdat hij daar geen gegevens over had.

Op mijn vraag wanneer ik weer over een goede verbinding kan beschikken was het antwoord dat hij dat niet wist.

Op mijn vraag hoe lang het kan gaan duren was het antwoord,
ik zou het niet weten.

En dus vroeg ik wat moet ik nu doen, kreeg ik geen antwoord.

Tja iemand een idee wat nu????
 
Terug
Bovenaan