Telkom Internet Uncapped User Feedback.

Status
Not open for further replies.
jeanres said:
170KB/s on a well seeded torrent here on TI 10Mbps uncapped.
Click to expand...

Loaded up a couple UK soaps, switched to normal speed limits (385kB/s) and can still max out :)

Killed my torrent client and ran a traceroute (mtr) to bbc.co.uk:

mtr bbc.co.uk.jpg

... looks fine to me.

Possibly you guys are suffering from business hours exchange congestion :confused:
 
traceroute to www.bbc.net.uk (212.58.244.66) , 5 relative hops max, 52 byte packets
1 * * *
2 105.224.100.1 (105.224.100.1) 124.694 ms 128.151 ms 130.231 ms
3 105.226.0.6 (105.226.0.6) 89.684 ms 93.277 ms 95.343 ms
4 105.226.0.13 (105.226.0.13) 32.287 ms 37.266 ms 39.340 ms
5 196.25.39.45 (196.25.39.45) 40.884 ms 44.650 ms 47.224 ms
6 196.43.9.58 (196.43.9.58) 173.386 ms 224.182 ms 226.342 ms
7 83.245.126.93 (83.245.126.93) 452.898 ms 456.338 ms 458.386 ms
8 * * *
9 * * *
10 ae0.er01.telhc.bbc.co.uk (132.185.254.109) 409.812 ms 1424.587 ms 1426.188 ms
11 132.185.255.149 (132.185.255.149) 188.423 ms 382.162 ms 383.655 ms
12 bbc-vip111.telhc.bbc.co.uk (212.58.244.66) 224.677 ms 442.870 ms 444.546 ms
 
when he is here yes, installing mrtg quickly to see if there is something else killing my network
 
In true Telkom style, I just got an email that my issue is resolved. No Call. No nothing.
 
frailwings said:
How long does it usually take for an upgrade to 4MB to take place?
Click to expand...

I went into a store on Tuesday, the line was upped from 2mb to 4mb less than 24 hours later. Don't know if that's general across the country though. I'm in Hermanus btw.
 
jeanres said:
traceroute to www.bbc.net.uk (212.58.244.66) , 5 relative hops max, 52 byte packets
1 * * *
2 105.224.100.1 (105.224.100.1) 124.694 ms 128.151 ms 130.231 ms
3 105.226.0.6 (105.226.0.6) 89.684 ms 93.277 ms 95.343 ms
4 105.226.0.13 (105.226.0.13) 32.287 ms 37.266 ms 39.340 ms
5 196.25.39.45 (196.25.39.45) 40.884 ms 44.650 ms 47.224 ms
6 196.43.9.58 (196.43.9.58) 173.386 ms 224.182 ms 226.342 ms
7 83.245.126.93 (83.245.126.93) 452.898 ms 456.338 ms 458.386 ms
8 * * *
9 * * *
10 ae0.er01.telhc.bbc.co.uk (132.185.254.109) 409.812 ms 1424.587 ms 1426.188 ms
11 132.185.255.149 (132.185.255.149) 188.423 ms 382.162 ms 383.655 ms
12 bbc-vip111.telhc.bbc.co.uk (212.58.244.66) 224.677 ms 442.870 ms 444.546 ms
Click to expand...

Please post the output you get from long pings to 105.226.0.13 and 196.25.39.35, e.g. 'ping -n 50 105.226.0.13' on Windows, or 'ping -c 50 105.226.0.13' on a Unix-like platform.

We are aware that there seem to be some problems in Cape Town (anyone for who hop 2 or 3 is 105.226.0.6), and allocated some reserve bandwidth yesterday. We won't be able to improve (unaccelerated - encrypted or UTP) P2P throughput during peak times for at least another week, maybe 2, until additional IPC capacity is brought up.

For Non-P2P, we don't really seem to be dropping any traffic, so speeds should be adequate. We hope to be applying some changes over the weekend, which should hopefully improve more interactive services (e.g. video streaming, normal web browsing), but this will degrade downloads a little bit during peak times, until the IPC bandwidth upgrade is in. The changes also include better reporting of what traffic is being dropped, which should allow us to identify issues such as the ones during the past 2 weeks much sooner.

For other regions (routing through 105.224.0.6 and 105.228.0.6), we allocated more reserve bandwidth yesterday as well, which has improved matters quite a bit.
 
ponder said:
SOP, they need to make their stats look good.
Click to expand...

Only because they are measuring the wrong stats. But, when we ask why they don't measure the percentage of faults resolved to the customer's satisfaction (instead of faults closed within target time), they say their tools can't measure that.
 
╰─$ ping -c 50 196.25.39.35
PING 196.25.39.35 (196.25.39.35): 56 data bytes
64 bytes from 196.25.39.35: icmp_seq=0 ttl=245 time=29.664 ms
64 bytes from 196.25.39.35: icmp_seq=1 ttl=245 time=33.003 ms
64 bytes from 196.25.39.35: icmp_seq=2 ttl=245 time=31.039 ms
64 bytes from 196.25.39.35: icmp_seq=3 ttl=245 time=31.650 ms
64 bytes from 196.25.39.35: icmp_seq=4 ttl=245 time=28.941 ms
64 bytes from 196.25.39.35: icmp_seq=5 ttl=245 time=29.228 ms
64 bytes from 196.25.39.35: icmp_seq=6 ttl=245 time=29.331 ms
64 bytes from 196.25.39.35: icmp_seq=7 ttl=245 time=106.020 ms
64 bytes from 196.25.39.35: icmp_seq=8 ttl=245 time=29.086 ms
64 bytes from 196.25.39.35: icmp_seq=9 ttl=245 time=29.281 ms
64 bytes from 196.25.39.35: icmp_seq=10 ttl=245 time=28.994 ms
^C

PING 105.226.0.13 (105.226.0.13): 56 data bytes
64 bytes from 105.226.0.13: icmp_seq=0 ttl=250 time=133.437 ms
64 bytes from 105.226.0.13: icmp_seq=1 ttl=250 time=7.723 ms
64 bytes from 105.226.0.13: icmp_seq=2 ttl=250 time=43.655 ms
64 bytes from 105.226.0.13: icmp_seq=3 ttl=250 time=99.244 ms
64 bytes from 105.226.0.13: icmp_seq=4 ttl=250 time=44.258 ms
64 bytes from 105.226.0.13: icmp_seq=5 ttl=250 time=125.512 ms
64 bytes from 105.226.0.13: icmp_seq=6 ttl=250 time=96.697 ms
64 bytes from 105.226.0.13: icmp_seq=7 ttl=250 time=147.363 ms
64 bytes from 105.226.0.13: icmp_seq=8 ttl=250 time=138.048 ms
 
ranger said:
Please post the output you get from long pings to 105.226.0.13 and 196.25.39.35, e.g. 'ping -n 50 105.226.0.13' on Windows, or 'ping -c 50 105.226.0.13' on a Unix-like platform.

We are aware that there seem to be some problems in Cape Town (anyone for who hop 2 or 3 is 105.226.0.6), and allocated some reserve bandwidth yesterday. We won't be able to improve (unaccelerated - encrypted or UTP) P2P throughput during peak times for at least another week, maybe 2, until additional IPC capacity is brought up.

For Non-P2P, we don't really seem to be dropping any traffic, so speeds should be adequate. We hope to be applying some changes over the weekend, which should hopefully improve more interactive services (e.g. video streaming, normal web browsing), but this will degrade downloads a little bit during peak times, until the IPC bandwidth upgrade is in. The changes also include better reporting of what traffic is being dropped, which should allow us to identify issues such as the ones during the past 2 weeks much sooner.

For other regions (routing through 105.224.0.6 and 105.228.0.6), we allocated more reserve bandwidth yesterday as well, which has improved matters quite a bit.
Click to expand...

P2P is worse then on afrihost this time of day, 28kb/s on 10Mbps account and line
 
on another note Ranger, the telkom VDSL routers sucks, they don't support snmp, I have been going through the telnet interface na d not seeing anything
 
MickZA said:
Lets see a traceroute to bbc.co.uk - it might be a TI routing problem for you guys in CT.
Click to expand...

But, PE goes via the same site as CT (Bellville). Your 2nd or 3rd hop is 105.226.0.6, isn't it?

So, if there is a problem with our Bellville site, you should be experiencing it too.

If there isn't a problem with our Bellville site, then it should be DSLAM congestion, but the Afrihiost should be affected too.

There could be one other cause, maybe jeanres has his torrent client forcing encryption, and you don't, in which case you are getting good speeds due to our content acceleration platform, and jeanres isn't because the content acceleration platform can't do it for encrypted bittorrent.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X