Telkom Internet Capped/Uncapped User Feedback (Pt2)

MickZA · Dec 29, 2014

OK, p2p shaping is definitely screwed, the attached graph details torrents that were started yesterday evening with a couple of additional ones started around midday to see if shaping would be applied. Download is limited by my torrent client to 285 kB/s except during nightsurfer (timed for 23:50 - 07:15) when it's set for 580 kB/s:

... it seems TI has only applied shaping during nightsurfer

ranger · Dec 29, 2014

MickZA said:
From the little testing I can perform during business hours it seems that TI detects p2p download speed and shapes once it exceeds an undetermined limit.

This is absolutely not the case. We don't place any limit on a specific user's p2p, or do anything to a user's non-p2p traffic based on their p2p traffic.

We did make some changes to individual user traffic management around 11 Dec in order to test them on the live network (after all testing passed in QA) for features that are in the pipeline, but there should be no way for you to trigger the policy in question.

I'll queue something for tonight to see if I can see any issues, but at aggregate levels, everything looks fine.

ranger · Dec 29, 2014

Mannemarak said:
Well my problem is still there, after a legnthy message via @telkomZA, the only reply i got was "Hi, according to test result ping is fine to TI, no line errors and no congestion. No ISP have control once you outside the network.HR"

Here is the message i sent:
tracert:
Tracing route to mybroadband.co.za [197.242.89.170]
over a maximum of 30 hops:

1 <1 ms 1 ms 1 ms 192.168.0.1
2 10 ms 9 ms 10 ms nngy-ip-bb-1.east.dsl.telkomsa.net
[105.224.124.1]
3 12 ms 12 ms 12 ms ipc-1-up.east.dsl.telkomsa.net
[105.229.0.22]
4 11 ms 12 ms 11 ms ipc-aggr-2.east.dsl.telkomsa.net
[105.229.0.13]
5 10 ms 10 ms 10 ms ndn-ip-hsll-1.telkom-ipnet.co.za
[165.165.233.249]
6 32 ms 32 ms 33 ms 196.43.11.234
7 34 ms 33 ms 33 ms 196.43.25.206
8 35 ms 37 ms 35 ms 196.25.247.26
9 35 ms 36 ms 35 ms css1-ctn-gi0-2.ip.isnet.net [168.209.6.10]
10 35 ms 34 ms 34 ms 196.36.84.154
11 51 ms 49 ms 50 ms
CORE.GP-CN-HET-MEE-1.TO.GP-HV-ICT-MEE-1.DFA.P2P.10G.za [41.84.13.66]
12 52 ms 52 ms 51 ms
41-66-132-246-f6.HET001-CPE-1-to-GP-CN-HET-MEE-1.africainx.net
[41.66.132.246]
13 51 ms 51 ms 51 ms core-access-switch1.jnb1.host-h.net
[197.189.193.1]
14 55 ms 55 ms 53 ms row-access-switch1-row3-4.jnb1.host-h.net
[197.189.193.36]
15 51 ms 51 ms 51 ms 197.242.89.170

Trace complete.

Why did you send a traceroute MyBroadband (in Johannesburg which you are reaching via SAIX then IS in Cape Town) when you were mainly (as far as I can tell) having issues with gaming on MWEB servers in Cape Town? The path taken will be *entirely* different after the 4th hop (shouldn't touch SAIX, should hand over to MWEB in Cape Town although one side of the path could be via Johannesburg).

durban > durban (SAIX host) http://www.speedtest.net/my-result/3974350281
durban > durban (MWEB host) http://www.speedtest.net/my-result/3974354675

durban > cape town (SAIX host) http://www.speedtest.net/my-result/3974359089
durban > cape town (MWEB host) http://www.speedtest.net/my-result/3974364416

So, the high latency to MWEB Durban is because the shortest path (fewest IP hops) to them is via Cape Town (or possibly Johannesburg). The real question is, why do you get lower latency to their Durban speedtest server than the Cape Town one? I guess it might be the csse if you get to MWEB speedtest via Johannesburg. A traceroute to these would be useful (I have access to a test VM in Durban, but the firewall it os behind isn't currently allpwing traceroute to work).

These test snaps was about 2 weeks ago, but problem is still there.
Can someone please help me understand why connecting to MWEB causes ping to jump?
As a league gamer, one would think with Telkom sponsoring arguably the biggest gaming league in the country, PING to any and all ISPs in the country would be phenomenal.

Will this issue still be there if i switch to a capped account? Or should i rather switch to something else.....again

You need to provide a bit more detail. At least a traceroute to the server you are experiencing high latency to. If the latency show s up in the traceroute, the question will be where ( I doubt it will be on our side). If it doesn't show up, then there may be a traffic recognition problem, in which case I'll need an 'official' reference to be able to get anything fixed (so I would need you to send all the details to support at telkomsa dot net and PM me the ticket number). Any (significant) changes would need to wait for the end of the change freeze period though.

Big Bean · Dec 29, 2014

The only ping issue to Mweb, is the increased latency on their side, which still persists. I tried PMing Mweb guy a while back but he "could not see the issue". There is no terrible ping issue as there has been before though.

Tracing route to ts.navgaming.co.za [197.85.191.91]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms home.gateway [10.0.0.2]
2 8 ms 9 ms 7 ms wblv-ip-esr-3.south.dsl.telkomsa.net [105.224.80
.1]
3 11 ms 10 ms 12 ms ipc-2-up.south.dsl.telkomsa.net [105.226.0.22]
4 11 ms 10 ms 10 ms ipc-aggr-2.south.dsl.telkomsa.net [105.226.0.57]

5 11 ms 10 ms 10 ms ct1-pr-01-te0-0-0.net.telkomsa.net [105.187.249.
138]
6 12 ms 11 ms 11 ms mweb.ct1.napafrica.net [196.46.25.15]
7 36 ms 39 ms 38 ms be-1-cpt-p-1.mweb.co.za [197.84.7.33]
8 37 ms 38 ms 37 ms vl-12-cpt-hscore-2.mweb.co.za [197.84.5.254]
9 33 ms 31 ms 31 ms vp-02-14.bb.ctn.c27.za.net [196.28.178.70]
10 32 ms 33 ms 32 ms 197-85-139-78.cpt.mweb.co.za [197.85.139.78]
11 36 ms 37 ms 38 ms 197-85-191-91.cpt.virtualservers.co.za [197.85.1
91.91]

Trace complete.

Mannemarak · Dec 29, 2014

will do a tracert to my TS server, one via Telkom account and one via another ISP, just between those two there is a 30ms difference. TS server is in Cape Town.

Thanks for the feedback ranger, but question is "if not your side" but only on a Ti account, what must I do to get a good gaming experience out of Ti?

ranger said:
Why did you send a traceroute MyBroadband (in Johannesburg which you are reaching via SAIX then IS in Cape Town) when you were mainly (as far as I can tell) having issues with gaming on MWEB servers in Cape Town? The path taken will be *entirely* different after the 4th hop (shouldn't touch SAIX, should hand over to MWEB in Cape Town although one side of the path could be via Johannesburg).

So, the high latency to MWEB Durban is because the shortest path (fewest IP hops) to them is via Cape Town (or possibly Johannesburg). The real question is, why do you get lower latency to their Durban speedtest server than the Cape Town one? I guess it might be the csse if you get to MWEB speedtest via Johannesburg. A traceroute to these would be useful (I have access to a test VM in Durban, but the firewall it os behind isn't currently allpwing traceroute to work).

You need to provide a bit more detail. At least a traceroute to the server you are experiencing high latency to. If the latency show s up in the traceroute, the question will be where ( I doubt it will be on our side). If it doesn't show up, then there may be a traffic recognition problem, in which case I'll need an 'official' reference to be able to get anything fixed (so I would need you to send all the details to support at telkomsa dot net and PM me the ticket number). Any (significant) changes would need to wait for the end of the change freeze period though.

ranger · Dec 29, 2014

Mannemarak said:
will do a tracert to my TS server, one via Telkom account and one via another ISP, just between those two there is a 30ms difference. TS server is in Cape Town.

Thanks for the feedback ranger, but question is "if not your side" but only on a Ti account, what must I do to get a good gaming experience out of Ti?

Depends on what we see on the traceroute. We aren't 100% sure MWEB has sufficient backhaul capacity to the Cape Town peering location, other ISPs may use a different link/peering location to get to MWEB.

Alternatively, we may have to work with MWEB to improve routing between us for users in Durban.

Mannemarak · Dec 30, 2014

hope this helps a little more (tracerts to teamspeak) *logging some game servers will do some more tracerts tomorrow*

tracert with Openweb
Tracing route to 152.111.192.232 over a maximum of 30 hops

1 <1 ms 1 ms <1 ms 192.168.0.1
2 10 ms 9 ms 10 ms 196-210-157-1.dynamic.isadsl.co.za [196.210.157.1]
3 12 ms 11 ms 11 ms cdsl1-umh-gi0-0-0-3102.ip.isnet.net [196.38.74.245]
4 11 ms 12 ms 10 ms 196.26.210.200
5 12 ms 13 ms 11 ms mi-za-umh-p7-ten-0-0-1-1.ip.isnet.net [168.209.93.239]
6 24 ms 22 ms 23 ms mi-za-bry-p7-lo0.ip.isnet.net [168.209.255.208]
7 22 ms 22 ms 22 ms core1a-bry-gi0-0-0.ip.isnet.net [168.209.217.1]
8 22 ms 21 ms 22 ms core1a-bry-ge1-0-1.isnet.net [168.209.100.237]
9 21 ms 21 ms 21 ms 196.26.0.10
10 21 ms 21 ms 21 ms mweb-2.jinx.net.za [196.223.14.32]
11 50 ms 49 ms 49 ms tengig-0-0-0-3-vic-p-1.mweb.co.za [197.80.7.65]
12 48 ms 48 ms 46 ms tengig-0-0-0-0-cpt-p-2.mweb.co.za [197.84.4.46]
13 45 ms 45 ms 46 ms vl-11-cpt-hscore-1.mweb.co.za [197.84.5.238]
14 58 ms 45 ms 46 ms 196.28.178.66
15 45 ms 44 ms 43 ms gig5-1-cpt-opt-65-1.optinet.net [196.41.133.234]
16 44 ms 43 ms 44 ms 152.111.192.232

Trace complete.

Ti Account:

Tracing route to 152.111.192.232 over a maximum of 30 hops

1 <1 ms 1 ms 1 ms 192.168.0.1
2 9 ms 10 ms 9 ms nngy-ip-bb-1.east.dsl.telkomsa.net [105.224.124.1]
3 12 ms 11 ms 11 ms ipc-1-up.east.dsl.telkomsa.net [105.229.0.22]
4 12 ms 11 ms 11 ms ipc-aggr-2.east.dsl.telkomsa.net [105.229.0.13]
5 40 ms 40 ms 39 ms telkom-internet.jb1.napafrica.net [196.46.25.241]
6 57 ms 57 ms 57 ms mweb.jb1.napafrica.net [196.46.25.145]
7 84 ms 83 ms 83 ms tengig-0-7-0-3-vic-p-1.mweb.co.za [197.80.7.1]
8 87 ms 87 ms 87 ms tengig-0-0-0-0-cpt-p-2.mweb.co.za [197.84.4.46]
9 69 ms 68 ms 68 ms vl-12-cpt-hscore-2.mweb.co.za [197.84.5.254]
10 86 ms 84 ms 85 ms vp-02-14.bb.ctn.c27.za.net [196.28.178.70]
11 84 ms 85 ms 85 ms 196.41.144.34
12 67 ms 65 ms 66 ms gig5-1-cpt-opt-65-1.optinet.net [196.41.133.234]
13 86 ms 85 ms 85 ms 152.111.192.232

Trace complete.

All these numbers have given me a headache

ranger said:
Depends on what we see on the traceroute. We aren't 100% sure MWEB has sufficient backhaul capacity to the Cape Town peering location, other ISPs may use a different link/peering location to get to MWEB.

Alternatively, we may have to work with MWEB to improve routing between us for users in Durban.

ranger · Dec 30, 2014

Mannemarak said:
Ti Account:

Tracing route to 152.111.192.232 over a maximum of 30 hops

1 <1 ms 1 ms 1 ms 192.168.0.1
2 9 ms 10 ms 9 ms nngy-ip-bb-1.east.dsl.telkomsa.net [105.224.124.1]
3 12 ms 11 ms 11 ms ipc-1-up.east.dsl.telkomsa.net [105.229.0.22]
4 12 ms 11 ms 11 ms ipc-aggr-2.east.dsl.telkomsa.net [105.229.0.13]
5 40 ms 40 ms 39 ms telkom-internet.jb1.napafrica.net [196.46.25.241]
6 57 ms 57 ms 57 ms mweb.jb1.napafrica.net [196.46.25.145]
7 84 ms 83 ms 83 ms tengig-0-7-0-3-vic-p-1.mweb.co.za [197.80.7.1]
8 87 ms 87 ms 87 ms tengig-0-0-0-0-cpt-p-2.mweb.co.za [197.84.4.46]
9 69 ms 68 ms 68 ms vl-12-cpt-hscore-2.mweb.co.za [197.84.5.254]
10 86 ms 84 ms 85 ms vp-02-14.bb.ctn.c27.za.net [196.28.178.70]
11 84 ms 85 ms 85 ms 196.41.144.34
12 67 ms 65 ms 66 ms gig5-1-cpt-opt-65-1.optinet.net [196.41.133.234]
13 86 ms 85 ms 85 ms 152.111.192.232

Trace complete.

There are two issues here, one is on our side (it shouldn't take 30ms to get from Durban to Johannesburg), the other may require cooperation from MWEB (why the handover to MWEB is in Johannesburg and not Cape Town).

Mannemarak · Dec 30, 2014

Yoh remind me next time to rather take leave between Christmas and New Year, Im dog tired over here ...

Anyhow, where to from here, what must I do to make something happen?

Thanks again for the feedback ranger

ranger said:
There are two issues here, one is on our side (it shouldn't take 30ms to get from Durban to Johannesburg), the other may require cooperation from MWEB (why the handover to MWEB is in Johannesburg and not Cape Town).

MickZA · Dec 30, 2014

ranger said:
This is absolutely not the case. We don't place any limit on a specific user's p2p, or do anything to a user's non-p2p traffic based on their p2p traffic.

We did make some changes to individual user traffic management around 11 Dec in order to test them on the live network (after all testing passed in QA) for features that are in the pipeline, but there should be no way for you to trigger the policy in question.

I'll queue something for tonight to see if I can see any issues, but at aggregate levels, everything looks fine.

Last nights graph plus session and p2p speed limits schedulers:

The 580kB/s p2p limit was set at 23:30 and a new session for nightsurfer was started at 23:45. As can be seen from the graph 580kB/s was maintained until about 01:00 and then dwindled to virtually 0kB/s until a new session was started at 06:45, speed climbed back to 580kB/s dropping to 285kB/s at 07:00 when the lower p2p speed limits kicked in.

285kB/s was maintained until 08:00 when I enabled the 580kB/s limit which was only maintained for a short period before dying at which point I enabled the 285kB/s limit which is still running smoothly.

No new torrents were started during the test period and only one completed.

ranger · Dec 30, 2014

Mannemarak said:
Anyhow, where to from here, what must I do to make something happen?

We have logged a change for this afternoon to implement an adjustment to how traffic from one of the Durban IPC routers gets to the Johannesburg peering router, and we are currently in the process of getting approval for the change.

Will update later this afternoon.

Mannemarak · Dec 30, 2014

Shot ranger, again thanks for the help, much appreciated

ranger said:
We have logged a change for this afternoon to implement an adjustment to how traffic from one of the Durban IPC routers gets to the Johannesburg peering router, and we are currently in the process of getting approval for the change.

Will update later this afternoon.

ranger · Dec 30, 2014

ranger said:
We have logged a change for this afternoon to implement an adjustment to how traffic from one of the Durban IPC routers gets to the Johannesburg peering router, and we are currently in the process of getting approval for the change.

Will update later this afternoon.

The change was implemented, and the latency looks to be about 15-20ms lower than before, so you should get between 45 and 65ms. We should be able to improve it a bit later once the change freeze is over (some other circuits only got completed just before the change freeze, so there is still some work that will have impact to be done).

Before:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:24.179 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/48/49 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:40.712 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 1 msec  0 msec  0 msec 
 2  196.46.25.241 30 msec  30 msec  30 msec 
 3  196.46.25.145 47 msec  47 msec  47 msec 
 4  197.80.7.98 [MPLS: Label 16806 Exp 3] 47 msec 
    197.80.7.1 50 msec 
    197.80.7.34 49 msec 
 5  197.84.4.46 [MPLS: Label 16807 Exp 3] 50 msec 
    197.84.4.34 46 msec 
    197.84.4.46 51 msec 
 6  197.84.5.254 46 msec 
    197.84.5.238 49 msec  48 msec 
 7  196.28.178.70 47 msec  64 msec  45 msec 
 8  196.41.133.234 46 msec 
    196.41.144.34 49 msec  45 msec 
 9  196.41.133.234 50 msec 
    152.111.192.232 49 msec  46 msec

After:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:16.075 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:17.560 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 2 msec  0 msec  0 msec 
 2  196.46.25.241 14 msec  15 msec  14 msec 
 3  196.46.25.145 31 msec  31 msec  31 msec 
 4  197.80.7.1 [MPLS: Label 16839 Exp 3] 36 msec 
    197.80.7.65 34 msec 
    197.80.7.98 33 msec 
 5  197.84.4.46 [MPLS: Label 16808 Exp 3] 36 msec 
    197.84.4.34 30 msec 
    197.84.4.46 34 msec 
 6  197.84.5.254 29 msec  32 msec 
    197.84.5.238 34 msec 
 7  196.28.178.66 73 msec 
    196.28.178.70 34 msec 
    196.28.178.66 30 msec 
 8  196.41.133.234 33 msec  34 msec 
    196.41.144.34 29 msec 
 9  152.111.192.232 33 msec  31 msec 
    196.41.133.234 29 msec

Mannemarak · Dec 30, 2014

WOOT WOOT, thanks again, much appreciated, will give it a whirl tonight when i get home

ranger said:

The change was implemented, and the latency looks to be about 15-20ms lower than before, so you should get between 45 and 65ms. We should be able to improve it a bit later once the change freeze is over (some other circuits only got completed just before the change freeze, so there is still some work that will have impact to be done).

Before:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:24.179 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/48/49 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:40.712 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 1 msec  0 msec  0 msec 
 2  196.46.25.241 30 msec  30 msec  30 msec 
 3  196.46.25.145 47 msec  47 msec  47 msec 
 4  197.80.7.98 [MPLS: Label 16806 Exp 3] 47 msec 
    197.80.7.1 50 msec 
    197.80.7.34 49 msec 
 5  197.84.4.46 [MPLS: Label 16807 Exp 3] 50 msec 
    197.84.4.34 46 msec 
    197.84.4.46 51 msec 
 6  197.84.5.254 46 msec 
    197.84.5.238 49 msec  48 msec 
 7  196.28.178.70 47 msec  64 msec  45 msec 
 8  196.41.133.234 46 msec 
    196.41.144.34 49 msec  45 msec 
 9  196.41.133.234 50 msec 
    152.111.192.232 49 msec  46 msec

After:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:16.075 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:17.560 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 2 msec  0 msec  0 msec 
 2  196.46.25.241 14 msec  15 msec  14 msec 
 3  196.46.25.145 31 msec  31 msec  31 msec 
 4  197.80.7.1 [MPLS: Label 16839 Exp 3] 36 msec 
    197.80.7.65 34 msec 
    197.80.7.98 33 msec 
 5  197.84.4.46 [MPLS: Label 16808 Exp 3] 36 msec 
    197.84.4.34 30 msec 
    197.84.4.46 34 msec 
 6  197.84.5.254 29 msec  32 msec 
    197.84.5.238 34 msec 
 7  196.28.178.66 73 msec 
    196.28.178.70 34 msec 
    196.28.178.66 30 msec 
 8  196.41.133.234 33 msec  34 msec 
    196.41.144.34 29 msec 
 9  152.111.192.232 33 msec  31 msec 
    196.41.133.234 29 msec

ranger · Dec 30, 2014

MickZA said:
Last nights graph plus session and p2p speed limits schedulers:

View attachment 178773

View attachment 178769

View attachment 178771

The 580kB/s p2p limit was set at 23:30 and a new session for nightsurfer was started at 23:45. As can be seen from the graph 580kB/s was maintained until about 01:00 and then dwindled to virtually 0kB/s until a new session was started at 06:45, speed climbed back to 580kB/s dropping to 285kB/s at 07:00 when the lower p2p speed limits kicked in.

285kB/s was maintained until 08:00 when I enabled the 580kB/s limit which was only maintained for a short period before dying at which point I enabled the 285kB/s limit which is still running smoothly.

No new torrents were started during the test period and only one completed.

Looks like my queue finished by about 02h35, but there was no significant change at 01h00:

Code:

[ranger@media ~]$ grep throttle .rtorrent.rc
schedule = throttle_1,00:15:00,24:00:00,download_rate=400
schedule = throttle_2,05:45:00,24:00:00,download_rate=8
schedule = throttle_start,00:00:00,24:00:00,"d.multicall=,d.start="
schedule = throttle_stop,06:00:00,24:00:00,"d.multicall=,d.stop="

I might need to set up a test from the Bellville test VM, but all sites are running the same revision of policy.

ponder · Dec 30, 2014

ranger said:
Looks like my queue finished by about 02h35, but there was no significant change at 01h00:

View attachment 178925

Code:

[ranger@media ~]$ grep throttle .rtorrent.rc schedule = throttle_1,00:15:00,24:00:00,download_rate=400 schedule = throttle_2,05:45:00,24:00:00,download_rate=8 schedule = throttle_start,00:00:00,24:00:00,"d.multicall=,d.start=" schedule = throttle_stop,06:00:00,24:00:00,"d.multicall=,d.stop="

I might need to set up a test from the Bellville test VM, but all sites are running the same revision of policy.

You could try durban as well, torrents are completely dead for me. I do need to mention though that I'm in the orange on the usage tracking tool but that's never been an issue though. If you want ssh or teamviewer access to my box just shout.

Mannemarak · Dec 31, 2014

Hi ranger, got so excited yesterday, I forgot to do a tracert to post

But pings dropped by almost 25ms last night, so ye GG WP to you and thanks again for the help and feedback much appreciated

will put a tracert later...

ranger said:

The change was implemented, and the latency looks to be about 15-20ms lower than before, so you should get between 45 and 65ms. We should be able to improve it a bit later once the change freeze is over (some other circuits only got completed just before the change freeze, so there is still some work that will have impact to be done).

Before:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:24.179 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/48/49 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 09:01:40.712 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 1 msec  0 msec  0 msec 
 2  196.46.25.241 30 msec  30 msec  30 msec 
 3  196.46.25.145 47 msec  47 msec  47 msec 
 4  197.80.7.98 [MPLS: Label 16806 Exp 3] 47 msec 
    197.80.7.1 50 msec 
    197.80.7.34 49 msec 
 5  197.84.4.46 [MPLS: Label 16807 Exp 3] 50 msec 
    197.84.4.34 46 msec 
    197.84.4.46 51 msec 
 6  197.84.5.254 46 msec 
    197.84.5.238 49 msec  48 msec 
 7  196.28.178.70 47 msec  64 msec  45 msec 
 8  196.41.133.234 46 msec 
    196.41.144.34 49 msec  45 msec 
 9  196.41.133.234 50 msec 
    152.111.192.232 49 msec  46 msec

After:

Code:

#ping 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:16.075 SAST
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 152.111.192.232, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/33 ms
#traceroute 152.111.192.232 source 105.229.0.14
Tue Dec 30 14:55:17.560 SAST

Type escape sequence to abort.
Tracing the route to 152.111.192.232

 1  105.229.0.13 2 msec  0 msec  0 msec 
 2  196.46.25.241 14 msec  15 msec  14 msec 
 3  196.46.25.145 31 msec  31 msec  31 msec 
 4  197.80.7.1 [MPLS: Label 16839 Exp 3] 36 msec 
    197.80.7.65 34 msec 
    197.80.7.98 33 msec 
 5  197.84.4.46 [MPLS: Label 16808 Exp 3] 36 msec 
    197.84.4.34 30 msec 
    197.84.4.46 34 msec 
 6  197.84.5.254 29 msec  32 msec 
    197.84.5.238 34 msec 
 7  196.28.178.66 73 msec 
    196.28.178.70 34 msec 
    196.28.178.66 30 msec 
 8  196.41.133.234 33 msec  34 msec 
    196.41.144.34 29 msec 
 9  152.111.192.232 33 msec  31 msec 
    196.41.133.234 29 msec

Joka69 · Dec 31, 2014

My Telkom ADSL lines been dead since 29/12/2014, no connection at all, i called in on the 29th and guy told me they are busy with the exchange and it will be sorted by that night, still dead! I called yesterday for a update, got the same response, this is the 3rd day now that my line is dead?? I've logged a fault (344CRK301214) on the 30th December, but no feedback so far.

I am in the Johannesburg, Roodepoort (Wilropark) area.

@Telkomza PM Sent.

MickZA · Dec 31, 2014

MickZA said:
View attachment 178773

View attachment 178769

View attachment 178771

The 580kB/s p2p limit was set at 23:30 and a new session for nightsurfer was started at 23:45. As can be seen from the graph 580kB/s was maintained until about 01:00 and then dwindled to virtually 0kB/s until a new session was started at 06:45, speed climbed back to 580kB/s dropping to 285kB/s at 07:00 when the lower p2p speed limits kicked in.

285kB/s was maintained until 08:00 when I enabled the 580kB/s limit which was only maintained for a short period before dying at which point I enabled the 285kB/s limit which is still running smoothly.

No new torrents were started during the test period and only one completed.

Last nights graph with upper p2p download limit set at 485kB/s.

Nightsurfer performance is better but still does not achieve a constant 485kB/s however since I enabled the 485kB/s limit at 08:00 the speed has been maintained.

... also yesterdays business hours torrents ran at a constant 285kB/s until I killed them.

@ranger - is it possible that nightsurfer has become so popular that shaping is kicking in?

d0b33 · Jan 1, 2015

My TI uncapped is unable to authenticate/connect, 3 days ago I got no throughput so thought I was being throttled, switched to my backup account but tried my TI today and no luck.

Edit:
Seems to be up now.

Join the MyBroadband community

Get started

Telkom Internet Capped/Uncapped User Feedback (Pt2)

Executive Member

Expert Member

Expert Member

Senior Member

Well-Known Member

Expert Member

Well-Known Member

Expert Member

Well-Known Member

Executive Member

Attachments

Expert Member

Well-Known Member

Expert Member

Well-Known Member

Expert Member

Honorary Master

Well-Known Member

Expert Member

Executive Member

Honorary Master