Afrihost Uncapped ADSL Feedback (Pt3)

Status
Not open for further replies.
AfriMan said:
YouTube was working pretty nicely this weekend in the North when I tested on Saturday.

Which region are you in and what time were you testing?
Click to expand...

La Montagne (Pretoria East) It was still very slow last night. Will be able to test again once I get home, but I see on AH's website that you guys have taken notice of the issue :)
 
Well I entered my line number and it says the speed on my line and the speed available in my area
 
Vexarus said:
La Montagne (Pretoria East) It was still very slow last night. Will be able to test again once I get home, but I see on AH's website that you guys have taken notice of the issue :)
Click to expand...

Yeah, just had that posted now :(
Run some tests though, I know we're working on a few things to have this fixed up.

Sorry dude, I know slow DSL sucks.
 
AfriGuy said:
Yeah, just had that posted now :(
Run some tests though, I know we're working on a few things to have this fixed up.

Sorry dude, I know slow DSL sucks.
Click to expand...

Any specific test I should run to help pinpoint the issue? I saw something about running traceroutes, anywhere specific that would be a good place I should trace to?
 
Vexarus said:
Any specific test I should run to help pinpoint the issue? I saw something about running traceroutes, anywhere specific that would be a good place I should trace to?
Click to expand...

It'll be a bit tough to pinpoint something with the notice up, a few speedtests and traceroutes should indicate something though :)
 
Right.

Getting heavy packet loss on Afrihost's 3rd and 4th IPC CT hops.

Code: 
C:\Windows\system32>tracert google.com

Tracing route to google.com [74.125.230.226]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     7 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    22 ms    18 ms    29 ms  41.181.221.254
  5    15 ms    12 ms    11 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    18 ms    11 ms    11 ms  compj-cpt-1.mtnns.net [196.44.18.2]
  7   220 ms   183 ms   177 ms  ls-cr-2--tb-cr-1.uk-b.mtnns.net [196.44.31.113]
  8   158 ms   152 ms   156 ms  ls-pr-2.uk--ls-cr-2.uk-a.mtn.net [209.212.111.187]
  9   162 ms   162 ms   152 ms  google-peering-ls-pr-2.uk.mtnns.net [209.212.99.13]
 10   177 ms   194 ms     *     209.85.255.78
 11   161 ms   164 ms   159 ms  209.85.250.169
 12   182 ms   188 ms   183 ms  lhr08s06-in-f2.1e100.net [74.125.230.226]

Trace complete.

C:\Windows\system32>tracert youtube.com

Tracing route to youtube.com [74.125.230.231]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     6 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    14 ms    15 ms    24 ms  ipc-recieve-tb-1a.mtnbusiness.net [41.181.53.150]
  5    42 ms    22 ms    14 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    14 ms    13 ms    10 ms  compj-cpt-1.mtnns.net [196.44.18.2]
  7   178 ms   186 ms   169 ms  ls-cr-2--tb-cr-1.uk-b.mtnns.net [196.44.31.113]
  8   155 ms   155 ms   161 ms  ls-pr-2.uk--ls-cr-2.uk-a.mtn.net [209.212.111.187]
  9   155 ms   157 ms   163 ms  google-peering-ls-pr-2.uk.mtnns.net [209.212.99.13]
 10   169 ms   167 ms   178 ms  209.85.255.78
 11   167 ms   158 ms   153 ms  209.85.250.169
 12   155 ms   155 ms   156 ms  lhr08s06-in-f7.1e100.net [74.125.230.231]

Trace complete.

C:\Windows\system32>tracert bbc.co.uk

Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     7 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    56 ms    29 ms    17 ms  41.181.51.182
  5    24 ms    17 ms    12 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    15 ms    24 ms    20 ms  unc-cpt-1.mtnns.net [196.44.18.8]
  7     9 ms     9 ms    10 ms  196.44.31.106
  8   185 ms   190 ms   168 ms  am-cr-1.am--lt-cr-1.uk-a.mtnns.net [196.44.31.221]
  9   159 ms   162 ms   152 ms  ls-pr-1.uk--ls-cr-1.uk-a.mtn.net [209.212.111.83]
 10   183 ms   159 ms   160 ms  bbc-linx.pr01.thdow.bbc.co.uk [195.66.224.103]
 11     *        *        *     Request timed out.
 12   169 ms   175 ms   163 ms  ae0.er02.cwwtf.bbc.co.uk [132.185.254.90]
 13   158 ms   159 ms   156 ms  132.185.255.165
 14   177 ms   175 ms   175 ms  fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]

Trace complete.

C:\Windows\system32>PAUSE
Press any key to continue . . .


As you can see my exchange is rock solid. Using Web-Africa free account does NOT give this issue either. I tested just to be 100% sure. Problem on your network.

PLEASE can this be looked at. Mumble is almost unusable and the loss is causing rubber banding. Please investigate this and fix.
 
Orihalcon said:
Right.

Getting heavy packet loss on Afrihost's 3rd and 4th IPC CT hops.

Code: 
C:\Windows\system32>tracert google.com

Tracing route to google.com [74.125.230.226]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     7 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    22 ms    18 ms    29 ms  41.181.221.254
  5    15 ms    12 ms    11 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    18 ms    11 ms    11 ms  compj-cpt-1.mtnns.net [196.44.18.2]
  7   220 ms   183 ms   177 ms  ls-cr-2--tb-cr-1.uk-b.mtnns.net [196.44.31.113]
  8   158 ms   152 ms   156 ms  ls-pr-2.uk--ls-cr-2.uk-a.mtn.net [209.212.111.187]
  9   162 ms   162 ms   152 ms  google-peering-ls-pr-2.uk.mtnns.net [209.212.99.13]
 10   177 ms   194 ms     *     209.85.255.78
 11   161 ms   164 ms   159 ms  209.85.250.169
 12   182 ms   188 ms   183 ms  lhr08s06-in-f2.1e100.net [74.125.230.226]

Trace complete.

C:\Windows\system32>tracert youtube.com

Tracing route to youtube.com [74.125.230.231]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     6 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    14 ms    15 ms    24 ms  ipc-recieve-tb-1a.mtnbusiness.net [41.181.53.150]
  5    42 ms    22 ms    14 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    14 ms    13 ms    10 ms  compj-cpt-1.mtnns.net [196.44.18.2]
  7   178 ms   186 ms   169 ms  ls-cr-2--tb-cr-1.uk-b.mtnns.net [196.44.31.113]
  8   155 ms   155 ms   161 ms  ls-pr-2.uk--ls-cr-2.uk-a.mtn.net [209.212.111.187]
  9   155 ms   157 ms   163 ms  google-peering-ls-pr-2.uk.mtnns.net [209.212.99.13]
 10   169 ms   167 ms   178 ms  209.85.255.78
 11   167 ms   158 ms   153 ms  209.85.250.169
 12   155 ms   155 ms   156 ms  lhr08s06-in-f7.1e100.net [74.125.230.231]

Trace complete.

C:\Windows\system32>tracert bbc.co.uk

Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     7 ms     7 ms     7 ms  105-236-5-1-esr-lo.mtnbusiness.co.za [105.236.5.1]
  4    56 ms    29 ms    17 ms  41.181.51.182
  5    24 ms    17 ms    12 ms  tb-dca-2.za--qux-a.za.mtnbusiness.net [41.181.184.28]
  6    15 ms    24 ms    20 ms  unc-cpt-1.mtnns.net [196.44.18.8]
  7     9 ms     9 ms    10 ms  196.44.31.106
  8   185 ms   190 ms   168 ms  am-cr-1.am--lt-cr-1.uk-a.mtnns.net [196.44.31.221]
  9   159 ms   162 ms   152 ms  ls-pr-1.uk--ls-cr-1.uk-a.mtn.net [209.212.111.83]
 10   183 ms   159 ms   160 ms  bbc-linx.pr01.thdow.bbc.co.uk [195.66.224.103]
 11     *        *        *     Request timed out.
 12   169 ms   175 ms   163 ms  ae0.er02.cwwtf.bbc.co.uk [132.185.254.90]
 13   158 ms   159 ms   156 ms  132.185.255.165
 14   177 ms   175 ms   175 ms  fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]

Trace complete.

C:\Windows\system32>PAUSE
Press any key to continue . . .


As you can see my exchange is rock solid. Using Web-Africa free account does NOT give this issue either. I tested just to be 100% sure. Problem on your network.

PLEASE can this be looked at. Mumble is almost unusable and the loss is causing rubber banding. Please investigate this and fix.
Click to expand...

Looks like you either have an internal firewall or are using your router in bridge mode. Your 3rd hop is a Telkom router on their network, which directs traffic to our IPC. If you are seeing packet loss here, it's outside our network.

Can you run a test like MTR so we can see where the packet loss and the extent of packet loss?
 
AfriMan said:
Looks like you either have an internal firewall or are using your router in bridge mode. Your 3rd hop is a Telkom router on their network, which directs traffic to our IPC. If you are seeing packet loss here, it's outside our network.

Can you run a test like MTR so we can see where the packet loss and the extent of packet loss?
Click to expand...

Which is why I don't count my second hop - I should have clarified that. Please replace 3rd and 4th with 4th and 5th then.

And per the IP lookups - 41.181.221.254, 41.181.51.182 and 41.181.53.150 belong to Afrihost and this where the problem is occurring. My post was unclear. Problem still remains on your network. As can be seen by the latency being introduced there.
 
Orihalcon said:
Which is why I don't count my second hop - I should have clarified that. Please replace 3rd and 4th with 4th and 5th then.

And per the IP lookups - 41.181.221.254, 41.181.51.182 and 41.181.53.150 belong to Afrihost and this where the problem is occurring. My post was unclear. Problem still remains on your network. As can be seen by the latency being introduced there.
Click to expand...

I can definitely see the jumps, which could be a result of the slow speeds we're seeing. But there shouldn't be packet loss, so I'd like to see that in an MTR so I can escalate to our technical team.
 
AfriMan said:
I can definitely see the jumps, which could be a result of the slow speeds we're seeing. But there shouldn't be packet loss, so I'd like to see that in an MTR so I can escalate to our technical team.
Click to expand...

I will install and run MTR tests when this happens again.
 
Sweet mother of pearl...

85% packet loss...

packetloss.png

Aaaaaaaaaaaaaand here we have a Web Africa account doing what WA does best...working.

packetloss.png


Now can I please draw your attention to the UDP packets received...Notice the massive difference here? Afrihost - please clarify your policy now on UDP traffic. My mumble was working perfectly the last few weeks...only the last 3 days have things gone completely belly up. Whatever you did your network management software screwed this up. Please roll back!


What the hell -here is the same test using 1gb capped account. Not as perfect as WA, but a HELL of a lot better than the uncapped one.

Untitled.png


So there you have it folks. Afrihost's shaper is at it again. Shaping the hell out of UDP voice traffic...

*sigh* I'll use my WA account for the rest of the month and top it up when needed with working data and hope this gets fixed as gaming is absolutely im-bloody-possible right now.
 
Last edited:
Can't connect to my IRC bouncer from afrihost, works fine from webafrica capped account.

[19:30:56] * Looking up yoloswag.in
[19:30:56] * Connecting to yoloswag.in (74.117.157.234:6969)
[19:31:17] * Connection failed (Connection timed out)

Friend on afrihost tried, can't connect either. Friend on mweb tried, works fine. Why is this? Also seems to only happen at certain times? I have resorted to setting up a local port forward over ssh in the meantime since I can ssh to my box fine, its just connections on port 6969 that fail.
 
No throughput on news servers or torrents. What's going on Afrihost?
Ping Test:

ping 197.242.144.102

64 bytes from 197.242.144.102: icmp_req=1 ttl=58 time=34 ms
64 bytes from 197.242.144.102: icmp_req=2 ttl=58 time=33 ms
64 bytes from 197.242.144.102: icmp_req=3 ttl=58 time=32 ms
64 bytes from 197.242.144.102: icmp_req=4 ttl=58 time=33 ms
64 bytes from 197.242.144.102: icmp_req=5 ttl=58 time=34 ms


ping 8.8.8.8

64 bytes from 8.8.8.8: icmp_req=1 ttl=44 time=159 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=44 time=159 ms
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5


Trace Test:

traceroute -n 197.242.144.102

1 10.0.0.1 1 ms 1 ms 1 ms
2 105.236.4.1 9 ms 8 ms 9 ms
3 41.181.54.8 26 ms 10 ms 9 ms
4 41.181.198.1 10 ms 9 ms 10 ms
5 196.44.18.2 11 ms 10 ms 10 ms
6 196.44.31.1 14 ms 11 ms 11 ms
7 196.44.31.6 34 ms 35 ms 33 ms
8 196.44.31.9 33 ms
196.44.0.2 32 ms
196.30.1.5 32 ms
9 196.30.1.5 32 ms 32 ms
196.31.220.2 32 ms
10 196.31.220.2 32 ms 31 ms
196.31.63.2 33 ms
11 196.31.63.2 33 ms 33 ms
196.30.42.1 34 ms
12 196.30.42.1 34 ms 33 ms
197.242.144.1 32 ms
13 197.242.144.1 32 ms 32 ms


traceroute -n 8.8.8.8

1 10.0.0.1 1 ms 1 ms
2 105.236.4.1 8 ms 8 ms
3 41.181.221.2 10 ms 9 ms
4 41.181.184.2 11 ms 10 ms
5 196.44.18.2 10 ms 18 ms
6 209.212.111.1 154 ms 154 ms
7 209.212.99.1 154 ms
209.85.255.7 154 ms
8 66.249.95.2 154 ms
216.239.51.1 160 ms
9 216.239.47.7 160 ms
Request timed out *
10 Request timed out *
8.8.8.8 160 ms
11 8.8.8.8 160 ms


DNS Test:

nslookup www.afrihost.com

Name: www.afrihost.com
Address: 197.242.144.102


nslookup www.google.com

Name: www.google.com
Address: 74.125.230.146
Name: www.google.com
Address: 74.125.230.145
Name: www.google.com
Address: 74.125.230.144
Name: www.google.com
Address: 74.125.230.148
Name: www.google.com
Address: 74.125.230.147


nslookup thishouldfail.afrihost.com

** server can't find thisshouldfail.com: NXDOMAIN
 
Still shaped at 25% Download/6.5% P2P at 4.38 am. I've been checking every half an hour since midnight. First few nights after the capacity upgrade were great, but tonight and last night have been the same as before the upgrade. Anyone else experiencing similar problems?
 
Two nights in a row that P2P's been running at 6.5% - even at 4am / 5am in the morning (Cape Town)
On the verge of sticking it to Afrihost finally now.
 
jxharding said:
Two nights in a row that P2P's been running at 6.5% - even at 4am / 5am in the morning (Cape Town)
On the verge of sticking it to Afrihost finally now.
Click to expand...

What is going on Afrihost, even in morning been shaped... :mad: . And Please don't tell use the same old story. Because you told us everything is unshaped between 10pm - 8am.
 
Orihalcon said:
Sweet mother of pearl...

85% packet loss...

View attachment 166623

Aaaaaaaaaaaaaand here we have a Web Africa account doing what WA does best...working.

View attachment 166629


Now can I please draw your attention to the UDP packets received...Notice the massive difference here? Afrihost - please clarify your policy now on UDP traffic. My mumble was working perfectly the last few weeks...only the last 3 days have things gone completely belly up. Whatever you did your network management software screwed this up. Please roll back!


What the hell -here is the same test using 1gb capped account. Not as perfect as WA, but a HELL of a lot better than the uncapped one.

View attachment 166633


So there you have it folks. Afrihost's shaper is at it again. Shaping the hell out of UDP voice traffic...

*sigh* I'll use my WA account for the rest of the month and top it up when needed with working data and hope this gets fixed as gaming is absolutely im-bloody-possible right now.
Click to expand...

We had our consultants who developed our shaping updates, as well as our overseas specialists on call, working on this through the night and most of yesterday, so live changes were being made to make improvements. It's very likely that during periods when the changes were rolled out the network was dropping packets. From what I can see, there were several rollouts through the night.

I don't think we can really use last night's performance as a benchmark, or at least until they have concluded their work and feel that we should expect improvement. From an overall perspective, the network was looking better (especially in the North) but I think there is still a lot more to do here.
 
Bl1zz4rd said:
Still shaped at 25% Download/6.5% P2P at 4.38 am. I've been checking every half an hour since midnight. First few nights after the capacity upgrade were great, but tonight and last night have been the same as before the upgrade. Anyone else experiencing similar problems?
Click to expand...

I think we can't expect the network to perform completely normally at the moment, while we're making changes and working on it. As far as I know the team worked through the night, so I think all the automated features like shaping changes may have been suspended while they do their work.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X