Re: [Merged] Manchester Proxies.
 

Oldham - Manchester - you can't tell much about the routes of the cables from the layer 3 information you pick up from a traceroute. The fibres themselves exist at level 1 and could go anywhere - I've seen fibre distances 3x the crow flies distance, and there will be two alternative fibres anyway going two different routes. The backbone fibres are nothing to do with the cable in the ground and won't follow the same routes.

Manchester got split into two halves for capacity reasons, with a new core site in Oldham serving north and east Manchester, which covers Ashton quite nicely. Oldham happens to be more-or-less in the middle of that area.

Re: [Merged] Manchester Proxies.
 

:lol: on a map yes but over country unless you have suspended cables over a country park, river and valley its a long way off..

Re: [Merged] Manchester Proxies.
 

I only seem to go through one of these two, since the proxies came on......

cache9-mant.server.ntli.net or
cache2-mant.server.ntli.net

Re: [Merged] Manchester Proxies.
 

How do you tell that?

Bill - don't put Automatically Detect Settings on in Internet Options - it doesn't do anything except slow your browser startup down. For transparent caching it's completely irrelevant.

Can I remind people that you don't get assigned a specific proxy by ntl, you go through a group of proxies one of which will respond to your request depending on the destination IP you are requesting data from. Thus requests to two different sites could well be fielded by two completely different servers. The only reason you may think you're on a specific proxy is that two visits to the *same* site are likely to be fielded by the *same* proxy.

Re: [Merged] Manchester Proxies.
 

I think what BBK is saying is that it's perfectly possible that there will be longer distances of fibre involved than the as the crow flies distance, this is for redundancies sake - there's no point in having two fibres run if they are both in the same ducting, it leaves a single point where fibre break takes service down.

As far as placement of Ashton and its' layer 1 routing, unless you know where the other set of cams are you can't say that that's close to your uBR than Oldham. From what BBK says this was done for load balancing purposes and seems to do that quite adequately - I really don't see what the issue is with going via Oldham, if you knew the sort of elongated routes DSL subscribers can take through BT's ATM cloud you may see things a bit differently!

What you see in your street is not the same as the fibre that connects uBRs to the rest of the network though, they are seperate networks.

However as I've already mentioned light travels at just under 300,000 km/second - London to Bristol in 1ms or so - it takes about 60ms to cross the Atlantic, going through the numerous repeaters on the way, I can't really see the extra length there making anything more than microseconds of difference and it certainly wouldn't affect services in any way shape or form.

11 26 ms 25 ms 25 ms mant-t2core-b-pos31.inet.ntl.com
12 27 ms 25 ms 27 ms oldh-t2cam1-b-ge-wan54.inet.ntl.com
13 26 ms 25 ms 27 ms ubr01asht.inet.ntl.com

Re: [Merged] Manchester Proxies.
 

Somebody has switched them on again:Yikes: back to slow browsing


1 <10 ms <10 ms <10 ms 192.168.2.1
2 14 ms 14 ms 13 ms 10.23.48.1
3 14 ms <10 ms <10 ms oldh-t2cam1-a-ge910.inet.ntl.com [80.5.164.61]
4 302 ms 13 ms 14 ms mant-t2core-a-ge-wan62.inet.ntl.com [213.104.24
41]
5 14 ms 14 ms 13 ms man-bb-a-so-230-0.inet.ntl.com [62.253.184.57]
6 14 ms 13 ms 14 ms man-bb-b-ae0-0.inet.ntl.com [62.253.187.178]
7 28 ms 14 ms 27 ms win-bb-a-so-300-0.inet.ntl.com [62.253.185.138]
8 14 ms 27 ms 14 ms win-dc-a-v900.inet.ntl.com [62.253.188.162]
9 14 ms 28 ms 13 ms www.ntlworld.com [62.253.162.30]

Re: [Merged] Manchester Proxies.
 

[16:33] * theng (~theng@spcx-roch1-6-0-custx.manc.broadband.ntl.com) has joined #nthellworld
[16:34] <theng> look at the p9ings BBK in the thread

I'll jump in for BBKing here and say this again as I did in previous page...

Pings are not affected by caches

That looks like a bit of activity on the line - note 1st hop and last hop are equal latency... I wouldn't mind pings like those to be honest:

1 1 ms <1 ms 1 ms gatelock-corporate.inside.net [192.168.253.1]
2 1 ms 1 ms 1 ms x-modem.inside.net [10.0.0.2]
3 17 ms 16 ms 17 ms 81-86-224-1.dsl.pipex.com [81.86.224.1]
4 16 ms 17 ms 15 ms sms10k2-2.cr1.uk5.systems.pipex.net [62.241.161.45]
5 18 ms 23 ms 17 ms ge-1-2-0.cr1.gs1.systems.pipex.net [62.241.161.97]
6 28 ms 17 ms 17 ms tmp.xchangepoint.net [217.79.160.89]
7 17 ms 18 ms 17 ms bre-bb-a-so-310-0.inet.ntl.com [62.253.188.105]
8 19 ms 19 ms 19 ms win-bb-b-so-600-0.inet.ntl.com [62.253.185.198]
9 20 ms 18 ms 19 ms win-bb-a-ae0-0.inet.ntl.com [213.105.172.161]
10 19 ms 19 ms 17 ms win-dc-a-v902.inet.ntl.com [62.253.187.222]
11 19 ms 19 ms 19 ms www.ntlworld.com [62.253.162.30]

Re: [Merged] Manchester Proxies.
 

Ah, didn't know that. So we hop around the proxies anyway depending on what page we ask for? So if i specify a proxy do i stay on that one or doesn't it apply either? Not that i change the settings, i'm just curious.

I used Allnet Tools or Samspade always gave these results.

Re: [Merged] Manchester Proxies.
 

If transparently cached yep you hop around the proxies, if you specify one you stay on that one proxy.

The only traffic redirected to the proxies is traffic on port 80, TCP. (Some cases DNS as well but let's not complicate). Standard pings won't be affected, they don't go on port 80 and they don't use TCP.

Re: [Merged] Manchester Proxies.
 

Quite right - it should theoretically be possible for a dodgy proxy to be detected if a lot of people in an area complain about access to a certain site, as you just examine which proxy would cache that site and take a good look at it. Sites subject to poor browsing are thus better to report than traceroutes, which, in th'eng's case, will make people jealous, as it goes to show that his UBR is extremely undersubscribed :)

Re: [Merged] Manchester Proxies.
 

:Yikes: OMG a undersubscibed UBR we cannot have this. Quick do something :PP: :LOL:

Re: [Merged] Manchester Proxies.
 

So what you want us to report is the website we was trying to access and not the tracert......

The proxies seem more trouble that what they are worth....
I will start to report the websites I am trying to visit.. Thanks for replying BBKing and JustAnotherNoob, wonder why they never told us on tech support that its the websites they needed to check the proxies.

One more question how will they know which proxy if we go through them all?
Is there anything we can download that will tell us our proxy when pages fail to load so we will know which and can report it?

I am having a good day really hope it stays like this only national lottery that was slow loading but I havent been on all day and think everyone have gone visiting mothers.....

Re: [Merged] Manchester Proxies.
 

i can confirm that the baguley caches are working, if you have problems with the manc the baguley are ok.

Re: [Merged] Manchester Proxies.
 

Yep...

I'm having great trouble accessing the website I'm working on for my job.

www.hhonline.co.uk

If i manually specifiy a manchester proxy, I can get to it. But when I dont specify one, I cant :(

How can I find out which proxy is stopping me?

Re: [Merged] Manchester Proxies.
 

Please don't do that, you end up with overload somewhere else. If people are going to find the addresses for Baguley they'll need to consult the list anyway and it's a lot better if people pick them kinda randomly (without any being suggested).

Anyone who has any kind of trouble even totally unrelated to proxies may read that post and pile onto Baguley and pretty soon Baguley is far from ok - it's a relatively small site for number of caches (4 of them) and a majority will pile onto cache1, then those in Baguley will start to play musical caches.

The fact is the majority of caches are ok the majority of the time, even specifying one of the Manchester caches will improve service if only one of them is having strife.

You shouldn't have to worry about that - do your work around and give the site's address when reporting the fault, it's ntl's problem to figure out which cache is not working properly, not yours.