|
ntl peering capacity is it been upgraded?
I just finished a discussion on irc about ntl been a record slow, here is some figures.
.uk 100mbit 198kB/sec .nl 10mbit 48kB/sec .de 100mbit 56kB/sec adslguide speedtest Results from broadband speed test recorded on Saturday, 03 December 2005, 16:18. Downstream 1823 Kbps (227.9 KB/sec) 1968 Kbps (inc. overheads) Upstream 476 Kbps (59.5 KB/sec) 514 Kbps (inc. overheads) ntl speed test 7.91mbps clearly with the differences between ntl speedtest and the other figures there is some kind of external capacity issue with ntl and its a big issue the figures are shocking. All the servers except adslguide I can personally vouch for not been maxed out and almost idle as well as other isp's having no issues with them. I did a trace from the uk box to my ip and I am seeing spikes after enta hands over to ntl over linx supporting that their linx port is saturated. 2 84-45-252-145.no-dns-yet.enta.net (84.45.252.145) 197.386 ms 0.933 ms 0.511 ms 3 telehouse-east.bdr.enta.net (84.45.193.193) 0.369 ms 0.348 ms 0.338 ms 4 linx-gw1.router.ntli.net (195.66.224.22) 0.540 ms 0.428 ms 0.452 ms 5 nth-bb-b-so-600-0.inet.ntl.com (62.253.184.1) 4.940 ms 19.777 ms 5.983 ms 6 lee-bb-a-so-600-0.inet.ntl.com (62.253.185.102) 8.108 ms 24.854 ms 7.703 ms 7 leic-t2core-a-so-000-0.inet.ntl.com (62.253.188.109) 10.681 ms 17.153 ms 9.957 ms 8 leic-t2cam1-a-ge-wan32.inet.ntl.com (82.3.33.9) 32.935 ms 10.230 ms 41.198 ms 9 leic-leic-ubr-8-ge01.inet.ntl.com (82.3.35.150) 10.098 ms 10.184 ms 39.594 ms note the ping spikes hop 5 onwards. For arguments sake people will tell me icmp is low priority so here is 2 sets of pings, first lot on hop 4 and 2nd lot on hop 5. 64 bytes from 195.66.224.22: icmp_seq=0 ttl=252 time=0.836 ms 64 bytes from 195.66.224.22: icmp_seq=1 ttl=252 time=0.615 ms 64 bytes from 195.66.224.22: icmp_seq=2 ttl=252 time=0.726 ms 64 bytes from 195.66.224.22: icmp_seq=3 ttl=252 time=0.601 ms 64 bytes from 195.66.224.22: icmp_seq=4 ttl=252 time=0.677 ms 64 bytes from 195.66.224.22: icmp_seq=5 ttl=252 time=0.705 ms 64 bytes from 195.66.224.22: icmp_seq=6 ttl=252 time=0.985 ms 64 bytes from 195.66.224.22: icmp_seq=7 ttl=252 time=0.629 ms 64 bytes from 195.66.224.22: icmp_seq=8 ttl=252 time=0.841 ms 64 bytes from 195.66.224.22: icmp_seq=9 ttl=252 time=0.719 ms 64 bytes from 195.66.224.22: icmp_seq=10 ttl=252 time=0.617 ms 64 bytes from 62.253.184.1: icmp_seq=0 ttl=249 time=20.410 ms 64 bytes from 62.253.184.1: icmp_seq=1 ttl=249 time=7.186 ms 64 bytes from 62.253.184.1: icmp_seq=2 ttl=249 time=4.731 ms 64 bytes from 62.253.184.1: icmp_seq=3 ttl=249 time=25.295 ms 64 bytes from 62.253.184.1: icmp_seq=4 ttl=249 time=4.712 ms 64 bytes from 62.253.184.1: icmp_seq=5 ttl=249 time=4.862 ms 64 bytes from 62.253.184.1: icmp_seq=6 ttl=249 time=34.514 ms 64 bytes from 62.253.184.1: icmp_seq=7 ttl=249 time=35.037 ms 64 bytes from 62.253.184.1: icmp_seq=8 ttl=249 time=44.538 ms 64 bytes from 62.253.184.1: icmp_seq=9 ttl=249 time=14.679 ms 64 bytes from 62.253.184.1: icmp_seq=10 ttl=249 time=4.979 ms This is frustrating since although I expected increased contention speeds of say 3-5mbit but this is quite ridicolous, I am getting performance in some cases on par with a 512kbit connection, people who come on claiming they downloading at 10meg I would be interested in the url they are using and if its of a proxy server, my main interest is non http traffic. |
Re: ntl peering capacity is it been upgraded?
Quote:
FTP. Direct Connect. all give me full download speeds when the other end has the speed required. This from newshostings test page Your IP address has been detected as Out BGP (port 119, 23, 80, 3128, etc) 2 ae4.j3.iad.scnet.net (66.225.244.161) 9.613 ms 10.243 ms 9.874 ms 3 0.so-4-2-0.cr1.iad1.us.nlayer.net (69.31.30.129) 9.891 ms 10.313 ms 9.932 ms 4 0.so-1-0-0.cr1.nyc3.us.nlayer.net (69.22.142.101) 9.898 ms 9.879 ms 9.910 ms 5 so-3-2-0-dcr1.nyk.cw.net (69.31.94.34) 9.730 ms 9.383 ms 9.885 ms 6 so-2-0-0-dcr2.tsd.cw.net (195.2.10.110) 96.029 ms 81.280 ms 81.171 ms 7 so-5-0-0-bcr1.tsd.cw.net (195.2.10.61) 78.123 ms 78.277 ms 78.296 ms 8 ntl1.tsd.cw.net (166.63.211.150) 89.340 ms 88.939 ms 89.425 ms 9 win-bb-a-so-500-0.inet.ntl.com (213.105.172.129) 89.142 ms 89.389 ms 107.482 ms 10 man-bb-b-so-600-0.inet.ntl.com (62.253.185.137) 210.723 ms 94.678 ms 95.015 ms 11 man-bb-a-ae0-0.inet.ntl.com (62.253.187.177) 94.685 ms 94.566 ms 94.545 ms 12 bagu-t2core-a-pos31.inet.ntl.com (62.253.188.26) 95.133 ms 95.556 ms 95.215 ms 13 bagu-cache-1.server.ntli.net (80.5.160.4) [open] 95.800 ms 95.188 ms 97.235 ms Out SC (port 7000) 2 ae4.j3.iad.scnet.net (66.225.244.161) 9.807 ms 9.494 ms 9.731 ms 3 0.so-4-2-0.cr1.iad1.us.nlayer.net (69.31.30.129) 9.913 ms 9.196 ms 19.257 ms 4 0.so-1-0-0.cr1.nyc3.us.nlayer.net (69.22.142.101) 10.009 ms 9.808 ms 9.724 ms 5 so-3-2-0-dcr1.nyk.cw.net (69.31.94.34) 35.963 ms 61.099 ms 9.411 ms 6 so-2-0-0-dcr2.tsd.cw.net (195.2.10.110) 81.187 ms 81.272 ms 81.877 ms 7 so-5-0-0-bcr1.tsd.cw.net (195.2.10.61) 78.094 ms 78.300 ms 78.178 ms 8 ntl1.tsd.cw.net (166.63.211.150) 88.745 ms 103.759 ms 93.665 ms 9 win-bb-a-so-500-0.inet.ntl.com (213.105.172.129) 89.221 ms 89.374 ms 89.157 ms 10 man-bb-b-so-600-0.inet.ntl.com (62.253.185.137) 94.610 ms 94.743 ms 94.543 ms 11 man-bb-a-ae0-0.inet.ntl.com (62.253.187.177) 94.562 ms 94.554 ms 94.691 ms 12 bagu-t2core-a-pos31.inet.ntl.com (62.253.188.26) 96.180 ms 95.275 ms 94.911 ms 13 bagu-cache-1.server.ntli.net (80.5.160.4) [open] 94.943 ms 94.873 ms 101.116 ms Out Cogent (port 8000) 2 g3-0.core01.iad01.atlas.cogentco.com (38.112.21.237) 9.610 ms 9.452 ms 10.949 ms 3 p11-0.core02.dca01.atlas.cogentco.com (154.54.2.197) 9.517 ms 11.184 ms 9.743 ms 4 p6-0.core01.par01.atlas.cogentco.com (66.28.4.205) 96.140 ms 97.186 ms 96.368 ms 5 p13-0.core01.lon02.atlas.cogentco.com (130.117.1.121) 115.894 ms 116.048 ms 218.664 ms 6 tele-ic-1-ge-001-217.inet.ntl.com (212.250.14.61) 84.352 ms 85.215 ms 85.290 ms 7 nth-bb-b-so-600-0.inet.ntl.com (62.253.184.1) 103.631 ms 92.954 ms 94.226 ms 8 lee-bb-a-so-600-0.inet.ntl.com (62.253.185.102) 96.447 ms 98.524 ms 96.296 ms 9 lee-bb-b-ae0-0.inet.ntl.com (62.253.187.186) 96.540 ms 96.957 ms 97.063 ms 10 bagu-t2core-b-pos31.inet.ntl.com (62.253.188.30) 98.888 ms 97.962 ms 98.476 ms 11 bagu-cache-1.server.ntli.net (80.5.160.4) [open] 97.593 ms 97.826 ms 98.658 ms Out BtN (port 9000) 2 ge13-2.br02.ash01.pccwbtn.net (63.218.94.129) 10.260 ms 11.574 ms 9.925 ms 3 fkft-ic-1.inet.ntl.com (80.81.192.5) 100.090 ms 100.126 ms 100.187 ms 4 nth-bb-a-as0-0.inet.ntl.com (213.105.174.85) 103.772 ms 104.276 ms 103.988 ms 5 nth-bb-b-ae0-0.inet.ntl.com (62.253.185.118) 103.985 ms 103.872 ms 103.872 ms 6 lee-bb-a-so-600-0.inet.ntl.com (62.253.185.102) 107.072 ms 107.047 ms 109.199 ms 7 lee-bb-b-ae0-0.inet.ntl.com (62.253.187.186) 107.499 ms 107.173 ms 107.113 ms 8 bagu-t2core-b-pos31.inet.ntl.com (62.253.188.30) 108.424 ms 109.077 ms 108.611 ms 9 bagu-cache-1.server.ntli.net (80.5.160.4) [open] 108.284 ms 108.236 ms 108.308 ms Between 6.00pm till 12.00 midnight i am luck to get full speed via any connection however |
Re: ntl peering capacity is it been upgraded?
Newshosting wise im pulling down 1200KB per second, sometimes it dips but never anything lower than 800KB.
Fastest HTTP ive gotten is 1021KB downloading JAVA JDK from Sun. 10meg lines are getting to a point now where some smaller servers pushing out content are slower than the lines we use. At the end of the day I dont really care, there is no noticeable difference browsing websites and downloading files have all been very fast and not something I can bitch about. Personally I think NTL should be given some time to analyse and adjust to the roll out which no doubr caused a massive amount of problems as all these type of things do. If im honest im shocked they managed to pull it off so well. J. |
Re: ntl peering capacity is it been upgraded?
Quote:
I fully agree with you :tu: |
Re: ntl peering capacity is it been upgraded?
except I know the servers I am testing on are not the issue, only one was 10mbit and was idle at the time.
With other people not seeing the same issues I wonder if ntl route different parts of the country out on differing peering points. A friend of mine in birmingham sees the same issues as me, so I wonder if the midlands is suffering more now, most people in leics seem to be having issues but I have seen one who says its fine. ---------- Post added at 19:36 ---------- Previous post was at 19:31 ---------- do newshosting have any type of speedtester? if not I might sign up for 1 month just to see how I get on, bill you say between 6 and 12pm but how was it for you today during the day? |
Re: ntl peering capacity is it been upgraded?
Quote:
Newshosting has a form of speed test here I have found Newshosting to be very very good. |
Re: ntl peering capacity is it been upgraded?
Quote:
I live in Cambridge if that makes any difference and use an NTL 250 modem. On my SB3100 browsing was impossible while downloading at 5-6mbit. |
Re: ntl peering capacity is it been upgraded?
I would only be using them for tests tho, I dont really use news servers much.
About 30 mins after I left the forum yesterday I did a download of creative at 1.15mb/sec over http, I got no idea if it was of a proxy or not but I know some peering routes are fine, its just some are completely overflowing and thats why I am frustrated. |
Re: ntl peering capacity is it been upgraded?
Im another person in Leicester who is having the same issues as Chrysalis regarding Ntl again my brother is in Poole and he doesnt have the same issues as myself so i agree different areas probaly are routed differently.
|
Re: ntl peering capacity is it been upgraded?
Quote:
dest www.ntlworld.com 2 ffm-s1-rou-1002.DE.eurorings.net (134.222.229.49) 1.266 ms 1.019 ms 1.049 ms 3 obl-rou-1003.NL.eurorings.net (134.222.230.29) 7.948 ms 6.957 ms 6.884 ms 4 195.190.233.250 (195.190.233.250) 7.912 ms 7.510 ms 7.475 ms 5 * * * 6 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 7.965 ms 7.898 ms 7.895 ms 7 amst-ic-1.inet.ntl.com (195.69.144.40) 9.855 ms 16.713 ms 8.065 ms dest leics me 2 ffm-s1-rou-1001.DE.eurorings.net (134.222.229.41) 1.140 ms 1.010 ms 0.731 ms 3 ledn-rou-1001.NL.eurorings.net (134.222.231.17) 6.235 ms 6.194 ms 72.244 ms 4 195.190.233.248 (195.190.233.248) 8.187 ms 7.743 ms 7.582 ms 5 * * * 6 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 7.349 ms 7.658 ms 7.844 ms 7 amst-ic-1.inet.ntl.com (195.69.144.40) 7.145 ms 14.836 ms 6.897 ms dest colc cache 2 ffm-s1-rou-1001.DE.eurorings.net (134.222.229.41) 1.207 ms 1.050 ms 0.953 ms 3 ledn-rou-1001.NL.eurorings.net (134.222.230.13) 6.174 ms 6.142 ms 6.132 ms 4 195.190.233.248 (195.190.233.248) 7.655 ms 7.601 ms 7.587 ms 5 * * * 6 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 7.368 ms 7.310 ms 7.215 ms 7 amst-ic-1.inet.ntl.com (195.69.144.40) 7.430 ms 6.987 ms 7.208 ms dest guildford cache 2 ffm-s1-rou-1002.DE.eurorings.net (134.222.229.49) 0.856 ms 1.079 ms 0.781 ms 3 obl-rou-1003.NL.eurorings.net (134.222.230.29) 6.994 ms 6.972 ms 6.948 ms 4 195.190.233.252 (195.190.233.252) 7.463 ms 7.469 ms 7.434 ms 5 * * * 6 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 8.090 ms 7.993 ms 7.992 ms 7 amst-ic-1.inet.ntl.com (195.69.144.40) 22.267 ms 8.147 ms 8.015 ms However its only the kpn part of the route that changes and not ntl's part until it gets further into ntl's network of course. |
Re: ntl peering capacity is it been upgraded?
hey Chrysalis ur not the only one having problems in leicester :(
me too jus upgraded today and did speed tests @ ADSLguide LE4 NTL: 250 RESULTS! Direction Actual Speed True Speed (estimated) Downstream 3243 Kbps (405.4 KB/sec) 3502 Kbps (inc. overheads) Upstream 481 Kbps (60.1 KB/sec) 519 Kbps (inc. overheads) |
Re: ntl peering capacity is it been upgraded?
Chrysalis those all go into the same part of the ntl network - are you saying the ntl core is congested?
|
Re: ntl peering capacity is it been upgraded?
no how can I, I dont know what load each particular hop is under, I just know alot of server's in germany/holland area go to crap for big parts of the day. But some people on here are claiming they getting kickass performance all day long from those area's so something isnt right.
Here is a graph taken from 10.42 am on a monday morning 5th dec, downloading from a 100mbit .de ftp server. http://www.chrysalisnet.org/ntl/ntl10degraph.jpg ---------- Post added at 10:06 ---------- Previous post was at 10:02 ---------- sorry to add 195.69.144.40 is the hop that seems to always be involved when its subpar, you may also say 4mbit speeds are not that bad but bear in mind its 10am on a monday morning and in decline mode already, most other routes are still fine at that time of day. At 9pm it is nearer 0.5mbit. |
Re: ntl peering capacity is it been upgraded?
ok regarding different external routes been used for different ntl area's this caught my attention. A ntl user was complaing of problem with his WoW connection and posted the following traceroute.
1 <1 ms <1 ms <1 ms air.setup [192.168.11.1] 2 11 ms 19 ms 7 ms 10.152.71.254 3 14 ms 9 ms 7 ms rdng-t2cam1-b-ge94.inet.ntl.com [62.253.122.137] 4 94 ms 62 ms 62 ms winn-t2core-b-ge-wan62.inet.ntl.com [62.253.121.149] 5 12 ms 9 ms 7 ms win-bb-b-so-300-0.inet.ntl.com [213.105.174.101] 6 1527 ms 1513 ms 1495 ms po4-0.brsbb1.bristol.opentransit.net [193.251.254.145] 7 1521 ms 1548 ms 1543 ms po8-0.loncr3.london.opentransit.net [193.251.243.37] 8 1586 ms 1575 ms 1553 ms po3-0.nykcr3.newyork.opentransit.net [193.251.243.21] 9 1551 ms 1552 ms 1592 ms ft-gw.n54ny.ip.att.net [192.205.32.137] 10 1667 ms 1634 ms 1614 ms tbr1-p032501.n54ny.ip.att.net [12.122.80.22] 11 1604 ms 1601 ms 1598 ms tbr1-cl14.cgcil.ip.att.net [12.122.10.2] 12 1629 ms 1671 ms 1626 ms tbr1-cl1.sffca.ip.att.net [12.122.10.6] 13 1646 ms 1672 ms 1698 ms gar3-p360.sffca.ip.att.net [12.123.13.157] 14 1718 ms 1736 ms 1701 ms mdf1-gsr12-2-pos-7-0.lax1.attens.net [12.122.255.254] 15 1705 ms 1740 ms 1740 ms mdf1-bi8k-1-eth-2-4.lax1.attens.net [12.129.192.62] 16 * * * Request timed out. If I am right he is in reading near london. I decided to trace the same ip and got the following. 1 27 ms 8 ms 12 ms UBR [10.8.143.254] 2 11 ms 11 ms 13 ms leic-t2cam1-a-ge914.inet.ntl.com [82.3.35.149] 3 9 ms 13 ms 75 ms leic-t2core-a-ge-220-0.inet.ntl.com [82.3.33.10] 4 12 ms 19 ms 24 ms lee-bb-a-so-220-0.inet.ntl.com [62.253.188.110] 5 23 ms 28 ms 14 ms lee-bb-b-ae0-0.inet.ntl.com [62.253.187.186] 6 53 ms 18 ms 13 ms man-bb-a-so-700-0.inet.ntl.com [62.253.185.193] 7 25 ms 24 ms 26 ms 212.187.137.1 8 28 ms 57 ms 37 ms so-6-1-0.mp2.manchesteruk1.level3.net [4.68.113. 118] 9 91 ms 109 ms 90 ms ae-0-0.bbr2.newyork1.level3.net [64.159.1.42] 10 91 ms 92 ms 107 ms ae-23-54.car3.newyork.level3.net [4.68.97.114] 11 103 ms 136 ms 93 ms att-level3-oc48.newyork1.level3.net [4.68.127.6] 12 184 ms 199 ms 183 ms tbr1-p032501.n54ny.ip.att.net [12.122.80.22] 13 167 ms 160 ms 162 ms tbr1-cl14.cgcil.ip.att.net [12.122.10.2] 14 162 ms 168 ms 163 ms tbr1-cl1.sffca.ip.att.net [12.122.10.6] 15 158 ms 195 ms 160 ms gar3-p360.sffca.ip.att.net [12.123.13.157] 16 191 ms 202 ms 167 ms mdf1-gsr12-2-pos-7-0.lax1.attens.net [12.122.255 .254] 17 179 ms 161 ms 162 ms mdf1-bi8k-1-eth-2-4.lax1.attens.net [12.129.192. 62] 18 ^C Ok so different route, so I thought maybe they rerouted it after he managed to get thru to tier2 support so for good measure I traced a opentransit hop to see what route I got to it and to see if problematic. 1 32 ms 10 ms 34 ms UBR [10.8.143.254] 2 9 ms 9 ms 7 ms leic-t2cam1-a-ge914.inet.ntl.com [82.3.35.149] 3 9 ms 10 ms 10 ms leic-t2core-a-ge-220-0.inet.ntl.com [82.3.33.10] 4 25 ms 17 ms 12 ms lee-bb-a-so-220-0.inet.ntl.com [62.253.188.110] 5 32 ms 14 ms 37 ms nth-bb-b-so-000-0.inet.ntl.com [62.253.185.101] 6 18 ms 33 ms 17 ms nth-bb-a-ae0-0.inet.ntl.com [62.253.185.117] 7 21 ms 32 ms 22 ms so-2-2-0-0.loncr2.london.opentransit.net [193.251.254.141] 8 71 ms 56 ms 23 ms po2-0.loncr3.london.opentransit.net [193.251.242.21] 9 97 ms 109 ms 93 ms po3-0.nykcr3.newyork.opentransit.net [193.251.243.21] Appears no problem, can someone in the south of england trace us.logon.worldofwarcraft.com please that was the target he traced so can see if the routing is indeed different, this could explain the hige differences in performances different areas appear to have. ---------- Post added at 21:04 ---------- Previous post was at 21:01 ---------- ip 12.129.232.116 as it is a pool of ip's I want to make sure same destination. |
Re: ntl peering capacity is it been upgraded?
Grats man, a different route from a different source, due to the different routes having different metrics. Nice to see that Cisco Network Academy lesson one is actually true.
Dynamic protocol running routers will take the most efficient path, including BGP even though they have different measures of this. Also modifications of such fields as MED, local preference, AS Prepending, metric, origin, etc, in route maps can be used to manipulate traffic. I think your point is that ntl have some transit and peering links that are congested yes? The first trace you posted supports this nicely without the need for the other stuff after it. If all areas were routed the same way there would be no resiliency, it's like saying that every car that wants to go from x to x absolutely has to go down this B road even though there's a dual carriageway and a motorway also, pointless. Basic dynamic routing, what you appeared to think was the case implied static routing which is absolutely not an option on a network with hundreds of routers. ---------- Post added at 21:49 ---------- Previous post was at 21:46 ---------- Quote:
Addresses: 12.129.232.109, 12.129.232.110, 12.129.232.111, 12.129.232.112 12.129.232.113, 12.129.232.114, 12.129.232.115, 12.129.232.116 Somehow I don't think that 8 consecutive IPs on the other side of the world will have different routes to them, otherwise the full route table would be just a tad larger than the 240,000 or so routes it is currently. (Hint it's called summarisation, the summarising of several smaller networks into a larger network / subnet called a supernet :) ) Quote:
|
Re: ntl peering capacity is it been upgraded?
The point I am making ignition, is that if Customer A in one part of england complains of slow speed and Customer B in a different area gets full whack, the blaim will be put on Customer A since it cant be ntl's fault as Customer B has no problems, most isp's I have seen tend to route people to london no matter where they live then out on the same external pipe, this way I have no problem with as long as it doesnt create a distortion between different area's.
|
Re: ntl peering capacity is it been upgraded?
The problem there is these issues should never actually reach tech support, capacity management are supposed to use the resources available to them to make sure these issues don't happen.
Think someone planned the access network while forgetting the core edge network. |
Re: ntl peering capacity is it been upgraded?
That I agree on :)
If that was done all this routing would be irrelevant. |
| All times are GMT. The time now is 06:56. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
All Posts and Content are © Cable Forum