[nl2dav]

Vanaf glasvezel hier;

1 2 ms 1 ms 1 ms 192.168.1.1
2 2 ms 2 ms 6 ms ip82-139-92-2.lijbrandt.net [82.139.92.2]
3 3 ms 3 ms 3 ms ip82-139-66-213.lijbrandt.net [82.139.66.213]
4 4 ms 2 ms 2 ms ip82-139-64-114.lijbrandt.net [82.139.64.114]
5 4 ms 2 ms 2 ms vrrp1-lt-vlan.prolocation.net [94.228.128.53]
6 3 ms * 2 ms ovh.globalswitch.nl-ix.net [193.239.116.188]
7 9 ms * 8 ms 40g.rbx-2-6k.routers.chtix.eu [91.121.131.9]
8 7 ms 7 ms 7 ms rbx-35-m1.routers.chtix.eu [213.251.191.228]
9 7 ms 8 ms 7 ms ks0000000.kimsufi.com [00000000000]

[Raymon]

Ook concepts ICT lijkt de AMS-IX nu volledig te bypassen:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 9 ms 8 ms 8 ms 213.197.27.154
3 8 ms 8 ms 9 ms 213.197.27.117
4 9 ms 16 ms 9 ms ip-87-82-50-229.easynet.co.uk [87.82.50.229]
5 25 ms 33 ms 25 ms te0-0-0.gr10.t2par.fr.easynet.net [87.86.77.30]

6 * * * Time-out bij opdracht.
7 182 ms 30 ms * 160g.rbx-2-6k.routers.chtix.eu [213.186.32.201]

8 22 ms 22 ms 23 ms rbx-20-m1.routers.chtix.eu [213.251.191.183]
9 22 ms 23 ms 24 ms mijn.server [00000000000]

Alsmede XS4all

1 1 ms 1 ms 1 ms 192.168.0.1
2 34 ms 99 ms 99 ms speedtouch.lan [192.168.1.254]
3 18 ms 18 ms 17 ms 195.190.250.28
4 20 ms 20 ms 20 ms 42.ge-1-1-0.xr3.3d12.xs4all.net [194.109.5.41]
5 19 ms 19 ms 20 ms asd2-rou-1002.NL.eurorings.net [134.222.97.17]
6 22 ms 21 ms 21 ms obl-rou-1021.NL.eurorings.net [134.222.231.201]

7 31 ms 31 ms 32 ms nntr-s1-rou-1022.FR.eurorings.net [134.222.231.1
82]
8 32 ms 31 ms 30 ms prs-s4-rou-1021.FR.eurorings.net [134.222.230.15
8]
9 * * * Request timed out.
10 34 ms * 30 ms 160g.rbx-2-6k.routers.chtix.eu [213.186.32.201]

11 31 ms 30 ms 30 ms rbx-20-m1.routers.chtix.eu [213.251.191.183]
12 42 ms 41 ms 39 ms mijn.server [00000000000]

Ping tijden zijn hierdoor omhoog geschoten van 15msec naar 23 tot 40msec Waar is de AMS-IX gebleven....

[Raymon]

Heb momenteel ook ineens een rare route vanaf Alice DSL;

  1     1 ms     1 ms     1 ms  192.168.2.1
  2     2 ms     1 ms     1 ms  local.gateway [172.19.3.1]
  3     9 ms     9 ms     9 ms  78.40.192.123
  4    10 ms     9 ms    10 ms  78.40.192.98
  5    10 ms    10 ms    10 ms  vlan96.newxr2.nik-asd.internl.net [78.40.192.118
]
  6    10 ms    10 ms    10 ms  K440.internlnet.ams1.nl.above.net [82.98.254.221
]
  7    10 ms    10 ms     9 ms  ge-0-2-0.mpr1.ams1.nl.above.net [64.125.28.93]
  8    17 ms    17 ms    49 ms  xe-1-1-0.mpr1.fra1.de.above.net [64.125.24.10]
  9    26 ms    25 ms    25 ms  xe-0-1-0.mpr1.cdg11.fr.above.net [64.125.31.233]

 10     *        *        *     Time-out bij opdracht.
 11    58 ms     *       24 ms  160g.rbx-2-6k.routers.chtix.eu [213.186.32.201]

 12    27 ms    24 ms    23 ms  rbx-17-m1.routers.chtix.eu [213.251.191.174]
 13    22 ms    22 ms    22 ms  mijn.server [000000000000000]

Normaal ging ik rechstreeks over amsix.ovh.com. Frankfurt staat ook op "rood" in de weathermap, in de "werken" kon ik zo snel niets ontdekken. De route was eerst 15msec, nu 22-23.

[freakt]

UPC -> http://www.ispam.nl/archives/14012/o...t-knijpen-upc/

[freakt]

Bij de meeste NL providers wordt al het ovh verkeer direct via de AMS-IX aan OVA geleverd, waarom gaat bij UPC het signaal (via transit) de halve wereld rond?

Dat terwijl Ams-ix dan goedkoper zou zijn.

Goedkoper dat klopt, maar als je dat langs AMS-IX laat verlopen, dan gaat UPC meer en meer bandbreedte krijgen wat betekend dat hun AMS-IX poort sneller toe zal zitten, wat dan betekend dat ze een extra poort of moeten upgraden, wat dan ook betekend dat hun hele netwerk infrastructuur hierop voorzien moet zijn... en dat dan nog eens eventueel extra kabels moeten gelegd (lees geleased) worden en ga maar door ...

Nu lijkt het gewoon ontmoediging !

[Josje]

Bij de meeste NL providers wordt al het ovh verkeer direct via de AMS-IX aan OVA geleverd, waarom gaat bij UPC het signaal (via transit) de halve wereld rond?

Dat terwijl Ams-ix dan goedkoper zou zijn.

[alexweblog]

maar ondanks dat het probleem er was was het ook snel opgelost

[patrickekkel]

niet alleen met chello alexweblog ook vodafone gebruikers hadden dit probleem

[alexweblog]

Afgelopen zaterdag was er een storing zodat ik met chello niet meer het datacenter in frankrijk binnen kwam maar alles was super snel opgelost. Normaal heb ik eigenlijk nooit problemen met de verbinding.

[Modis]

Waarschijnlijk dan wel niet zo'n super abbo bij openpeering

[Raymon]

Ah, ik was er niet van op de hoogte dat OVH ook verkeer over openpeering gooide.

[freakt]

Of het nu wel of niet gunstig is voor UPC. Openpeering zou een goede aanvulling zijn voor het OVH netwerk in Amsterdam

Tja het loopt al via daar dusja waarom zou je het dan nog nemen als het al via daar gaat?

AMS-IX is niet het enige waar ovh een uplink heeft hoor.

[Raymon]

Of het nu wel of niet gunstig is voor UPC. Openpeering zou een goede aanvulling zijn voor het OVH netwerk in Amsterdam

[freakt]

Ze zouden bij OVH eens moeten kijken naar Open Peering Initative. Een andere provider waar ik host, werkt hier ook mee. Deze hebben direct connectie met UPC en zeer strakke latency op alle NL providers.

Deze welke enige tijd geleden problemen had? :-)
Nee maar OVH stuurt verkeer ook via die weg naar UPC, maar UPC routeerd dit de halve wereld rond in de baan terug!

[Modis]

Ze zouden bij OVH eens moeten kijken naar Open Peering Initative. Een andere provider waar ik host, werkt hier ook mee. Deze hebben direct connectie met UPC en zeer strakke latency op alle NL providers.

[freakt]

Voor streaming maakt een hoge ping niet uit. Ik heb voor klanten in Azie en China shoutcast servers in singapore gehad. Daar hadden Nederlandse luisteraars ook geen enkel probleem mee om te connecten

hangt af wat voor streaming, met verschillende sources gaat het echt fout als die afwisselen etc, en wanneer mensen eens moeten bufferen (door een download locaal) knalt de hele stream er wel eens uit. Hier draaien meerdere streams welke enkel bij UPC problemen hebben... vandaar...

Verbding gaat ook langere weg op / gevoeliger...

[Raymon]

[...] streaming [...] moet je niet gaan proberen...

Voor streaming maakt een hoge ping niet uit. Ik heb voor klanten in Azie en China shoutcast servers in singapore gehad. Daar hadden Nederlandse luisteraars ook geen enkel probleem mee om te connecten

[freakt]

@mug daar heb je meer dan gelijk in! meerdere connecties zullen dan ook betere om nog meer snelheid te halen.

Echter VOIP toepassingen en gameservers en streaming en zelfs simpele IRC moet je niet gaan proberen...

[mug]

Download snelheid is ook het probleem niet. Het gaat meer om het opzetten van verbindingen. Latency speelt een belangrijke rol in hoe lang dat duurt. Als de verbinding uiteindelijk tot stand is gebracht, dan komt het vaak prima over de lijn (al dan niet geheel op de max. snelheid).

Daarnaast blijft het kwalijk dat UPC niet voor de meest efficiënte route kiest, maar over wat flut netwerken de traffic stuurt.

[Wiggly]

Via sftp geen problemen met downloaden. Heb upc fiber 60, 4 threads @ 1,8MB/sec

[freakt]

Dat had ik al verwacht. Het blijft immers UPC. Ik denk dat de hogere hand van OVH maar eens ernaar moet kijken. Als ze echt de kwaliteit willen verbeteren mbt latency, dan zou ik wel hier iets aan doen. Anders kan je namelijk net zo goed bij een US provider zitten, dat scheelt qua latency performance op die manier weinig.

OVH zou hier druk kunnen op uitoefenen maar dan moeten er meer klachten zijn om dit een reden te geven. Want UPC gaat niet zomaar zeggen 'ok we zetten dit terug goed'. UPC kennende zou dit via enkele controle organen moeten aangegeven worden en dan heb je al enige reden nodig...

[Modis]

Dat had ik al verwacht. Het blijft immers UPC. Ik denk dat de hogere hand van OVH maar eens ernaar moet kijken. Als ze echt de kwaliteit willen verbeteren mbt latency, dan zou ik wel hier iets aan doen. Anders kan je namelijk net zo goed bij een US provider zitten, dat scheelt qua latency performance op die manier weinig.

[freakt]

Al ging dat over traffic shaping met betrekking tot torrents. Nou vind ik dat niet zo erg, want ik heb daar geen last van. Het verkeer echter gewoon de verkeerde kant opsturen of bewust niet de snelste route kiezen, vind ik wel kwalijk. Kan dit door iemand van OVH bevestigd worden?

Dat is vaak voor financiele redenen omdat het voor hun goedkoper uit komt op bulk traffic langs ergens rond de gaan sturen, in ieder geval na het bellen door mij naar hun en nog 2 mensen willen ze er niets aan doen.

[Modis]

Al ging dat over traffic shaping met betrekking tot torrents. Nou vind ik dat niet zo erg, want ik heb daar geen last van. Het verkeer echter gewoon de verkeerde kant opsturen of bewust niet de snelste route kiezen, vind ik wel kwalijk. Kan dit door iemand van OVH bevestigd worden?

[freakt]

Kost UPC niets hoor (nuja beetje goede wil ook!), OVH moet niets doen! zoals je ziet gaat het langs de kant van OVH goed en sturen ze dit over hun globalcrossing... de kortste weg. (niet over AMS-IX wat ik raar vind, zou het dan kunnen den UPC geen AMS-IX poortje heeft?)

UPC routeerd je verkeer gewoon de hele andere kant op om jou als klant het moeilijk te maken daar veer verkeer over te doen en hun in kosten te besparen.

UPC is echter bekend in dergelijke praktijken en knijpt maar al te graag dingen af...

Dit zal toch met UPC besproken moeten worden als zijnde klant, denk dat OVH eens kan proberen maar vrees er ook voor.

Als ik het niet fout heb is er ooit op tweakers.net eens wat verschenen over grote klachten tegen UPC...

[Modis]

Dat ziet er dan zo uit. Ik weet echter dat OVH beter hier met UPC (of met AMS-IX) over kan hebben. Daarnaast gaat het vaak om geld. UPC vraagt daar volgens mij behoorlijk wat geld voor, zoiets heb ik vernomen. En je wordt altijd bij UPC naar de ander gestuurd als klant, dus dat heeft weinig zin. Heb het namelijk al eens eerder met hun over dit soort zaken gehad, maar wilde ze niks van weten.

traceroute to 62.195.xxx.xxx (62.195.xxx.xxx), 30 hops max, 40 byte packets
 1  94.23.60.254 (94.23.60.254)  0.420 ms * *
 2  94.23.122.138 (94.23.122.138)  5.525 ms * *
 3  160g.gsw-1-6k.routers.chtix.eu (213.186.32.225)  4.044 ms * *
 4  30g.gblx.gsw-1-6k.routers.chtix.eu (213.186.32.129)  212.263 ms  212.335 ms  212.451 ms
 5  msn-1.ar4.PAO2.gblx.net (64.212.107.50)  27.446 ms  27.452 ms  27.455 ms
 6   (84.116.131.22)  28.568 ms  28.455 ms  28.427 ms
 7  p21184.net.upc.nl (212.142.21.184)  29.441 ms  29.067 ms  29.020 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[freakt]

Ze hebben volgens mij wel een router of meerdere op de AMS-IX staan... Het heeft volgens mij puur met de routering te maken. Ik weet dat mijn vorige verbinding (Telfort ADSL) wel via de AMS-IX router liep.

Klopt allemaal goed wat je zegt maar als je tracert naar OVH vanaf UPC dan heeft UPC dit grotendeels in handen en zal je bij UPC moeten aankloppen. Deze partij weet maar al te goed dat via OVH veel dataverkeer komt en weren dit als de pest! Doe eens een tracert van OVH naar je UPC ip... langs waar loopt dit?

[Modis]

Klopt het wat ik zie, dat UPC GEEN AMS-IX verbinding heeft of toch niet via daar traffic stuurd?

Het ligt vooral aan UPC hoor omdat die het verkeer gewoon de verkeerde kant opstuurd. als ze dit naar AMS-IX opsturen ben je met ~8 hops maximaal klaar, want OVH heeft een AMSI-IX verbinding http://weathermap.ovh.net/ (lees: meerdere!)

Leasweb en UPC zijn redelijk kort me elkaar verbonden, kan je bijvoorbeeld eens naar volgende proberen?
bit.nl
oxilion.nl
transip.nl

Ze hebben volgens mij wel een router of meerdere op de AMS-IX staan. Bij BIT, Oxilion en Transip krijg ik rond 10ms standaard, dus vrij normaal.
Het heeft volgens mij puur met de routering te maken. Ik weet dat mijn vorige verbinding (Telfort ADSL) wel via de AMS-IX router liep.

PING bit.nl (213.136.12.236): 56 data bytes
64 bytes from 213.136.12.236: icmp_seq=0 ttl=250 time=9.647 ms
64 bytes from 213.136.12.236: icmp_seq=1 ttl=250 time=8.709 ms
64 bytes from 213.136.12.236: icmp_seq=2 ttl=250 time=13.084 ms
64 bytes from 213.136.12.236: icmp_seq=3 ttl=250 time=10.614 ms
64 bytes from 213.136.12.236: icmp_seq=4 ttl=250 time=12.810 ms
64 bytes from 213.136.12.236: icmp_seq=5 ttl=250 time=10.723 ms
64 bytes from 213.136.12.236: icmp_seq=6 ttl=250 time=14.678 ms
64 bytes from 213.136.12.236: icmp_seq=7 ttl=250 time=12.617 ms

Ik vermoed toch dat hier wel wat aan gedaan kan worden en lijkt me ook niet erg onverstandig, aangezien UPC 693.000 breedband klanten in NL heeft

[Brian]

Ik gebruik zelf ook kabel internet alleen dan van Ziggo.
Mijn ping naar ovh is rond de 9ms.
Ben daar wel tevreden mee!

[freakt]

Deze geven voor mij (Chello classic shit, wat dat nu ook is)
10-14ms.

Ligt het er niet gewoon aan dat OVH ergens in een centertje in Frankrijk ligt en leaseweb gewoon een snellere verbinding met UPC? Zelfde dan met die 3 andere.

Uiteraard ligt OVH gigantisch veel verder en zal hoe je het ook draait of keert Leaseweb zal korter zitten in traceroutes of even lang (op uitzondering van rare traceroutes)

Tevens zullen nederlandse bedrijven betere verbindingen naar UPC nemen (of omgekeerd).

Echter merkte ik in de TS zijn verhaal op dat die via UPC niet naar AMS-iX gaat maar een heel andere kant op. En moesten ze bij UPC zo slim zijn om dit goed te routeren of een poortje bij de AMS-IX te nemen (vermoed dat ze dit wel hebben) zou dit veel oplossen.

Nuja UPC is wel bekend om het knijpen van verkeer etc, en ze zullen dan vermoedelijk bewust het verkeer de moeilijke weg opsturen omdat OVH nogal wat data verkeer naar NL verstuurd. Ze geven tevens ook nog toe aan klanten van hun dat dit aan hun ligt maar dat ze hier niets willen aan doen omdat het nu toch 'gewoon werkt'. Van zodra het niet werkt mag je hen terug bellen en dan lossen ze mogelijk problemen op.


Echter meld ik OVH ook nog even op dat ze zeker met UPC eens moeten praten want streaming etc vanaf OVH servers loopt zelden goed, zelfs IRC chat dingen lopen met gigantische vertragingen op. Het ligt gewoon aan UPC dit en niet aan OVH. Tja als je internet provider zo 'koppig' is.

[XSlicer]

bit.nl
oxilion.nl
transip.nl

Deze geven voor mij (Chello classic shit, wat dat nu ook is)
10-14ms.

Ligt het er niet gewoon aan dat OVH ergens in een centertje in Frankrijk ligt en leaseweb gewoon een snellere verbinding met UPC? Zelfde dan met die 3 andere.

[freakt]

Klopt het wat ik zie, dat UPC GEEN AMS-IX verbinding heeft of toch niet via daar traffic stuurd?

Het ligt vooral aan UPC hoor omdat die het verkeer gewoon de verkeerde kant opstuurd. als ze dit naar AMS-IX opsturen ben je met ~8 hops maximaal klaar, want OVH heeft een AMSI-IX verbinding http://weathermap.ovh.net/ (lees: meerdere!)

Leasweb en UPC zijn redelijk kort me elkaar verbonden, kan je bijvoorbeeld eens naar volgende proberen?
bit.nl
oxilion.nl
transip.nl

[Modis]

Ik zit op een UPC Fiber Power verbinding en ik merk sinds de overgang van ADSL naar kabel, dat de latency hoger uitvalt. Ik vind een latency tegen de 40ms aan wel aan de hoge kant, zeker als ik op een snelle breedband verbinding zit.

Nu ben ik benieuwd hoe de latency naar OVH server bij andere providers is en vooral of ze bij OVH netwerkmanagement hier eens aan kunnen sleutelen

Dit is gemiddeld wat ik krijg naar OVH servers (ook mijn eigen server bij OVH).

PING ovh.nl (94.23.151.34): 56 data bytes
64 bytes from 94.23.151.34: icmp_seq=0 ttl=56 time=36.781 ms
64 bytes from 94.23.151.34: icmp_seq=1 ttl=56 time=36.469 ms
64 bytes from 94.23.151.34: icmp_seq=2 ttl=56 time=37.032 ms
64 bytes from 94.23.151.34: icmp_seq=3 ttl=56 time=38.494 ms
64 bytes from 94.23.151.34: icmp_seq=4 ttl=56 time=34.386 ms
64 bytes from 94.23.151.34: icmp_seq=5 ttl=56 time=34.568 ms
64 bytes from 94.23.151.34: icmp_seq=6 ttl=56 time=36.380 ms
64 bytes from 94.23.151.34: icmp_seq=7 ttl=56 time=38.206 ms
64 bytes from 94.23.151.34: icmp_seq=8 ttl=56 time=38.370 ms
64 bytes from 94.23.151.34: icmp_seq=9 ttl=56 time=40.307 ms
64 bytes from 94.23.151.34: icmp_seq=10 ttl=56 time=36.375 ms
64 bytes from 94.23.151.34: icmp_seq=11 ttl=56 time=38.461 ms
64 bytes from 94.23.151.34: icmp_seq=12 ttl=56 time=36.512 ms

traceroute to ovh.nl (94.23.151.34), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  1071.740 ms  0.584 ms  0.518 ms
 2  10.15.191.129 (10.15.191.129)  8.215 ms  7.753 ms  8.124 ms
 3  p21161.net.upc.nl (212.142.21.161)  9.970 ms  10.543 ms  9.005 ms
 4  84.116.244.81 (84.116.244.81)  8.565 ms  14.905 ms  11.066 ms
 5  84.116.244.37 (84.116.244.37)  10.770 ms  10.614 ms  9.388 ms
 6  84.116.131.1 (84.116.131.1)  9.750 ms  11.002 ms  12.426 ms
 7  at-vie15a-rd1-pos-14-0.aorta.net (213.46.160.250)  30.077 ms  31.064 ms  30.079 ms
 8  at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.173.193)  30.023 ms
    at-vie15a-rd1-xe-4-2-0.aorta.net (213.46.173.53)  32.216 ms
    at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.173.193)  32.659 ms
 9  at-vie01a-rd1-xe-0-1-0.aorta.net (213.46.173.137)  31.652 ms
    at-vie01a-rd1-xe-0-0-0.aorta.net (213.46.173.189)  29.587 ms  37.277 ms
10  at-vie05b-ri1-g-2-0.aorta.net (213.46.173.202)  42.019 ms  30.561 ms  32.100 ms
11  1g.vie-1-6.routers.chtix.eu (91.121.131.65)  35.223 ms  59.463 ms *
12  30g.pra-1-6k.routers.chtix.eu (213.251.128.97)  37.570 ms  34.966 ms  37.719 ms
13  50g.fra-1-6k.routers.chtix.eu (213.251.128.110)  36.386 ms  38.758 ms *
14  * * *
15  * 80g.p19-2-6k.routers.chtix.eu (213.186.32.150)  75.398 ms  167.116 ms
16  10g.p19-57-6k.routers.chtix.eu (213.251.128.34)  39.424 ms  60.321 ms *
17  94.23.151.34 (94.23.151.34)  37.093 ms  36.423 ms  35.130 ms

In vergelijking met Leaseweb

PING leaseweb.nl (83.149.80.111): 56 data bytes
64 bytes from 83.149.80.111: icmp_seq=0 ttl=58 time=11.704 ms
64 bytes from 83.149.80.111: icmp_seq=1 ttl=58 time=10.032 ms
64 bytes from 83.149.80.111: icmp_seq=2 ttl=58 time=10.100 ms
64 bytes from 83.149.80.111: icmp_seq=3 ttl=58 time=11.834 ms
64 bytes from 83.149.80.111: icmp_seq=4 ttl=58 time=9.810 ms
64 bytes from 83.149.80.111: icmp_seq=5 ttl=58 time=9.872 ms
64 bytes from 83.149.80.111: icmp_seq=6 ttl=58 time=9.512 ms
64 bytes from 83.149.80.111: icmp_seq=7 ttl=58 time=9.675 ms
64 bytes from 83.149.80.111: icmp_seq=8 ttl=58 time=9.246 ms

traceroute to leaseweb.nl (83.149.80.111), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  0.922 ms  0.586 ms  0.521 ms
 2  10.15.191.129 (10.15.191.129)  6.439 ms  8.690 ms  7.003 ms
 3  p21161.net.upc.nl (212.142.21.161)  9.868 ms  8.058 ms  8.535 ms
 4  84.116.131.21 (84.116.131.21)  20.682 ms  12.403 ms  9.803 ms
 5  crs-tc2.leaseweb.net (195.69.144.215)  13.661 ms  9.643 ms  9.684 ms
 6  te5-4.sr1.sbp.leaseweb.net (62.212.80.45)  10.534 ms  8.410 ms  9.889 ms
 7  www.leaseweb.com (83.149.80.111)  10.244 ms  10.465 ms  10.221 ms