Telecom PRO Broadband - Slower than Bigtime

Forums › Spark New Zealand › Telecom PRO Broadband - Slower than Bigtime

gmball

347 posts

Ultimate Geek
+1 received by user: 58

Topic # 66729 22-Aug-2010 15:17

So we changed from Big Time to Telecom PRO 40gb plan as per the suggestion on our letter, now web browsing is slower, and downloads are slower. Websites sometimes sit waiting to load, and only load upon refresh?

Surely the pro plan should be faster?

Have reset the modem, and also confirmed that we have only used 7600MB of 40960MB....

1 | 2 | 3

8027 posts

Uber Geek
+1 received by user: 387

Trusted

Subscriber

Reply # 371061 22-Aug-2010 16:28

Here is my suspicion (not guaranteed to be factually correct)

Telecom have been progressively turning on their transparent proxy caching hardware, there seems to definitely be a problem with throughput via the caches currently.

Not all ip ranges assigned to customers are currently going via the cache.

Check your current ip addresses here
http://www.lagado.com/proxy-test

Try rebooting the router and see if you can a ip address in a range not going via their transparent proxy.

Also I would log a fault with the helpdesk, the more people that do this the sooner they will get on to fixing it (assuming they aren't well aware of it yet).

ptinson

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

Reply # 371075 22-Aug-2010 16:54

Ragnor: Here is my suspicion (not guaranteed to be factually correct)

Telecom have been progressively turning on their transparent proxy caching hardware, there seems to definitely be a problem with throughput via the caches currently.

I would be interested in hearing what makes you think there is a throughput issue.

You are correct, it is a progressive roll out.

Paul

meat popsicle

raab

262 posts

Ultimate Geek
Inactive user

Reply # 371080 22-Aug-2010 17:01

I also seem to be affected, however the opposite seems to be that my mate is going through the proxy and getting good speeds whereas I'm not and I'm getting bad speeds. Both in Wellington and both on PRO

I was testing on http://blowfi.sh/test.bin which is my 100mbit server in france and he's able to achieve 700+KB/s whereas I can only get a max of ~200KB/s, both single streams. I'm not sure if the file is cached for him hence getting good speeds

I ran a traceroute on both our connections and mine seems to take a different route:

Me:

Tracing route to blowfi.sh [94.23.195.164]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms xx.ad.local [172.22.16.1]
2 1 ms <1 ms <1 ms 172.22.15.1
3 8 ms 10 ms 7 ms 125-237-255-1.jetstream.xtra.co.nz [125.237.255.1]
4 * * * Request timed out.
5 17 ms 18 ms 17 ms ae4-10.akbr5.global-gateway.net.nz [202.37.244.221]
6 17 ms 18 ms 17 ms ae1-2.akbr4.global-gateway.net.nz [202.50.232.77]
7 18 ms 18 ms 18 ms ae1-10.tkbr9.global-gateway.net.nz [202.50.232.37]
8 143 ms 143 ms 143 ms so6-0-3.labr5.global-gateway.net.nz [122.56.127.34]
9 175 ms 175 ms 177 ms so7-0-3.sjbr2.global-gateway.net.nz [122.56.127.54]
10 177 ms 175 ms 177 ms so0-0-2.pabr4.global-gateway.net.nz [202.50.232.18]
11 * * * Request timed out.
12 304 ms 464 ms 338 ms 20g.vss-2-6k.routers.chtix.eu [94.23.122.109]
13 299 ms 301 ms 299 ms ns302379.ovh.net [94.23.195.164]

vs his:

Tracing route to blowfi.sh [94.23.195.164]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms vulcan.sol.net [10.1.1.1]
2 9 ms 8 ms 8 ms 125-237-64-1.jetstream.xtra.co.nz [125.237.64.1]
3 * * * Request timed out.
4 19 ms 19 ms 20 ms ae4-10.akbr5.global-gateway.net.nz [202.37.244.221]
5 19 ms 20 ms 19 ms ae1-2.akbr4.global-gateway.net.nz [202.50.232.77]
6 20 ms 20 ms 19 ms ae1-10.tkbr9.global-gateway.net.nz [202.50.232.37]
7 145 ms 144 ms 145 ms 202.50.232.42
8 151 ms 151 ms 176 ms so6-0-1.sjbr2.global-gateway.net.nz [202.50.232.89]
9 151 ms 180 ms 179 ms 202.50.232.10
10 * * * Request timed out.
11 300 ms 300 ms 326 ms 20g.vss-2-6k.routers.chtix.eu [94.23.122.109]
12 302 ms 302 ms 301 ms ns302379.ovh.net [94.23.195.164]

Coincidentally I used to be on that gateway, 125.237.64.1, before moving house

Edit: I just tried another download location, http://www.dilatedgraphics.com/dubsaw/DubsawSession4.mp3, and were getting similar speeds of ~130-150KB/s on a single stream.

I don't remember non cached intl traffic being this slow before..

National speeds max out my line

Ragnor

8027 posts

Uber Geek
+1 received by user: 387

Trusted

Subscriber

Reply # 371092 22-Aug-2010 17:28

ptinson:
Ragnor: Here is my suspicion (not guaranteed to be factually correct)

Telecom have been progressively turning on their transparent proxy caching hardware, there seems to definitely be a problem with throughput via the caches currently.

I would be interested in hearing what makes you think there is a throughput issue.

You are correct, it is a progressive roll out.

Paul

Here are two examples

http://www.gpforums.co.nz/showthread.php?s=&threadid=362778&perpage=25&pagenumber=285#post7335837
http://www.gpforums.co.nz/showthread.php?s=&threadid=362778&perpage=25&pagenumber=287#post7338557

Quite a few people coming off Big Time are posting back saying they are now on a range going via cache and normally usage http downloads etc are slower than on BT.

l43a2

1497 posts

Uber Geek
+1 received by user: 474

Trusted

Reply # 371093 22-Aug-2010 17:29

can we opt out of this stupid caching proxy ?

cheap secure seedboxes

raab

262 posts

Ultimate Geek
Inactive user

Reply # 371095 22-Aug-2010 17:29

I think routing might be the issue here, for some gateways, as from my OVH box I'm going via tokyo.

me:

raab@ns302379:~$ traceroute 122.57.39.xx
traceroute to (122.57.39.xx), 30 hops max, 40 byte packets
1 94.23.195.254 (94.23.195.254) 54.574 ms * *
2 20g.ldn-1-6k.routers.chtix.eu (94.23.122.110) 3.974 ms * *
3 30g.gblx-1.ldn.routers.ovh.net (213.251.130.54) 3.942 ms 4.161 ms 4.154 ms
4 p1-0.globalcrossing.londen03.uk.bb.gin.ntt.net (208.50.13.146) 9.451 ms 9.437 ms 9.570 ms
5 ae-1.r23.londen03.uk.bb.gin.ntt.net (129.250.5.237) 13.085 ms ae-1.r22.londen03.uk.bb.gin.ntt.net (129.250.5.233) 13.239 ms 13.232 ms
6 as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254) 79.862 ms ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85) 12.882 ms as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254) 76.272 ms
7 as-0.r20.nycmny01.us.bb.gin.ntt.net (129.250.3.254) 79.631 ms 76.256 ms ae-0.r21.nycmny01.us.bb.gin.ntt.net (129.250.2.26) 79.631 ms
8 as-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 107.143 ms as-2.r21.sttlwa01.us.bb.gin.ntt.net (129.250.3.190) 165.284 ms 168.577 ms
9 ae-0.r20.sttlwa01.us.bb.gin.ntt.net (129.250.2.53) 165.095 ms as-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.5.24) 153.165 ms 147.629 ms
10 as-3.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.4.190) 289.114 ms po-2.r00.lsanca19.us.bb.gin.ntt.net (129.250.6.42) 155.035 ms 146.939 ms
11 as-3.r20.lsanca03.us.bb.gin.ntt.net (129.250.3.22) 271.707 ms 278.580 ms ge-1-7.r00.lsanca19.us.ce.gin.ntt.net (204.1.253.50) 157.619 ms
12 so0-2-0.labr5.global-gateway.net.nz (203.96.120.101) 160.801 ms ae-0.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.34) 272.406 ms 281.978 ms
13 so2-0-1.tkbr9.global-gateway.net.nz (122.56.127.33) 279.267 ms * *
14 210.55.203.202 (210.55.203.202) 276.843 ms ge-1-7.r00.lsanca19.us.ce.gin.ntt.net (204.1.253.50) 277.612 ms 210.55.203.202 (210.55.203.202) 282.505 ms
15 * so0-2-0.labr5.global-gateway.net.nz (203.96.120.101) 280.081 ms 283.710 ms
16 125-237-255-1.jetstream.xtra.co.nz (125.237.255.1) 293.912 ms 298.870 ms 294.324 ms
17 210.55.203.202 (210.55.203.202) 409.556 ms 402.098 ms 407.324 ms
18 * * *
19 * 125-237-255-1.jetstream.xtra.co.nz (125.237.255.1) 419.225 ms 416.316 ms
20 * * *
21 * *^C

him:
raab@ns302379:~$ traceroute
traceroute to (125.236.242.xx), 30 hops max, 40 byte packets
1 * * *
2 20g.ldn-1-6k.routers.chtix.eu (94.23.122.110) 202.929 ms * *
3 30g.gblx-3.ldn.routers.ovh.net (94.23.122.126) 3.976 ms 3.957 ms 4.050 ms
4 sl-bb20-lon-10-0-0.sprintlink.net (213.206.131.25) 12.619 ms 12.612 ms 12.602 ms
5 sl-bb21-lon-15-0-0.sprintlink.net (213.206.128.38) 8.618 ms 8.610 ms 8.600 ms
6 sl-bb21-tuk-10-0-0.sprintlink.net (144.232.24.14) 84.360 ms 84.313 ms 84.302 ms
7 sl-crs2-pen-0-8-2-0.sprintlink.net (144.232.20.138) 81.519 ms 80.853 ms 80.840 ms
8 sl-crs2-rly-0-0-5-0.sprintlink.net (144.232.20.32) 81.152 ms sl-crs2-rly-0-2-2-0.sprintlink.net (144.232.19.2) 80.871 ms sl-crs2-rly-0-4-3-0.sprintlink.net (144.232.20.111) 85.692 ms
9 sl-crs2-dc-0-4-0-2.sprintlink.net (144.232.8.164) 81.254 ms sl-crs2-dc-0-6-0-3.sprintlink.net (144.232.9.214) 85.203 ms sl-crs2-dc-0-12-2-0.sprintlink.net (144.232.19.221) 80.988 ms
10 sl-crs2-fw-0-12-0-1.sprintlink.net (144.232.19.102) 118.750 ms 118.740 ms 118.070 ms
11 sl-crs2-ana-0-6-2-0.sprintlink.net (144.232.19.196) 145.744 ms sl-crs2-ana-0-9-3-0.sprintlink.net (144.232.9.64) 146.031 ms sl-crs2-ana-0-6-2-0.sprintlink.net (144.232.19.196) 145.295 ms
12 sl-st20-la-0-0-0.sprintlink.net (144.232.20.204) 151.852 ms 151.787 ms sl-st20-la-11-0-0.sprintlink.net (144.232.8.94) 145.578 ms
13 sl-newzeal-137399-0.sprintlink.net (144.232.154.242) 157.230 ms 157.354 ms 157.450 ms
14 so1-0-0.labr5.global-gateway.net.nz (202.50.232.238) 153.650 ms 153.895 ms 153.790 ms
15 202.50.232.41 (202.50.232.41) 289.734 ms so6-0-3.tkbr9.global-gateway.net.nz (122.56.127.61) 286.807 ms so6-0-2.tkbr9.global-gateway.net.nz (122.56.127.37) 279.848 ms
16 ae0-10.akbr4.global-gateway.net.nz (202.50.232.38) 295.716 ms 303.245 ms 288.871 ms
17 ae5-2.akbr5.global-gateway.net.nz (202.50.232.78) 282.296 ms 281.603 ms 282.078 ms
18 * * *
19 125-237-64-1.jetstream.xtra.co.nz (125.237.64.1) 293.035 ms 294.022 ms 292.621 ms
20 * * *
21 * * *
22 * *^C

tardtasticx

2889 posts

Uber Geek
+1 received by user: 380

Reply # 371107 22-Aug-2010 17:48

yes I am having this problem too. Any way around it?

Bachelor of Computing Systems (2015)

Late 2013 MacBook Pro with Retina Display (4GB/2.4GHz i5/128GB SSD) - HP DV6 (8GB/2.8GHz i7/120GB SSD + 750GB HDD)
iPhone 6S + (64GB/Gold/Vodafone NZ) - Xperia Z C6603 (16GB/White/Spark NZ)

Sam, Auckland

Ragnor

8027 posts

Uber Geek
+1 received by user: 387

Trusted

Subscriber

Reply # 371122 22-Aug-2010 18:09

ptinson posted in another thread if you have a static ip address you can be added to a bypass list.

Might be better to wait for them to iron out the kinks, usually caching improves performance!

gmball

347 posts

Ultimate Geek
+1 received by user: 58

Reply # 371142 22-Aug-2010 18:37

Did the proxy test as suggested and received the following reply:

Proxy Test

This request appears to have come via a proxy.

The proxy host is 219-**-***-***.jetstart.xtra.co.nz which has ip address 219.**.***.***

The proxy server has announced itself as 1.1 AKmdrL2CacheBC7.telecom.co.nz

Does this mean that I am forever stuck on slow PRO broadband unless I continually reboot my modem?

I think it might be easier for me to switch to another provider and take my $200 plus per month telecom bill to another provider,

Doozy if your around can you shed any light on why PRO broadband is so much slower than big time?

raab

262 posts

Ultimate Geek
Inactive user

Reply # 371147 22-Aug-2010 18:44

Apparently most if not all IP's on the gateway 125.237.255.1 go through GLF thus a high probability of going through NTT. This is unrelated to cache issues btw

Might have to get a static IP so I don't go via ntt

gmball

347 posts

Ultimate Geek
+1 received by user: 58

Reply # 371150 22-Aug-2010 18:46

So why exactly are telecom instigating this change when there was supposedly nothing wrong with the Full speed plans before this change?

raab

262 posts

Ultimate Geek
Inactive user

Reply # 371152 22-Aug-2010 18:52

Because in the long run caching data reduces the amount of traffic going overseas

It also benefits the end user in that you get full speed from the cache as opposed to inconsistent results when pulling data intl, routing issues etc etc

Just think of it like the google caches where youtube videos come down at your line speed, therefore no buffering

l43a2

1497 posts

Uber Geek
+1 received by user: 474

Trusted

Reply # 371186 22-Aug-2010 20:08

raab: Because in the long run caching data reduces the amount of traffic going overseas

It also benefits the end user in that you get full speed from the cache as opposed to inconsistent results when pulling data intl, routing issues etc etc

Just think of it like the google caches where youtube videos come down at your line speed, therefore no buffering

if thats the case then i expect bigger data caps :)

cheap secure seedboxes

ptinson

677 posts

Ultimate Geek
+1 received by user: 27

Trusted

Reply # 371215 22-Aug-2010 21:16

Ragnor:
ptinson:
Ragnor: Here is my suspicion (not guaranteed to be factually correct)

Telecom have been progressively turning on their transparent proxy caching hardware, there seems to definitely be a problem with throughput via the caches currently.

I would be interested in hearing what makes you think there is a throughput issue.

You are correct, it is a progressive roll out.

Paul

Here are two examples

http://www.gpforums.co.nz/showthread.php?s=&threadid=362778&perpage=25&pagenumber=285#post7335837
http://www.gpforums.co.nz/showthread.php?s=&threadid=362778&perpage=25&pagenumber=287#post7338557

Quite a few people coming off Big Time are posting back saying they are now on a range going via cache and normally usage http downloads etc are slower than on BT.

Thanks I am taking a read now.
The thread of the discussion is a bit dis-jointed so thanks for the specific pointers...

Paul

meat popsicle

Driftdamage

60 posts

Master Geek

Reply # 371269 22-Aug-2010 22:51

I'm getting horrible performance now as well thanks to the cache it seems. Few days ago it all started, did a cache and proxy test, and I had been put behind the proxy.

Facebook requires refreshes every 2/3 navigation (it just timesout). Isohunt times out each 2/3 navigation, and can't sort by seeders.
I also randomly lose CSS of sites, surfing through a site then all the formatting disappears.

I'll be taking my money elsewhere if this continues. Before the changes my net was blistering fast.

1 | 2 | 3