Afrihost Uncapped ADSL Feedback (Pt2)

Status
Not open for further replies.
Dade Murphy said:
Does that mean that people who use the most amount of bandwidth will be shaped more than the rest?

I didn't know that AH has this type of policy.
Click to expand...

Yes, we start shaping from the heaviest users to manage demand, as demand increases, we start going down the ladder to the lightest users. You can read about it in our AUP.
 
Zertop said:
Well... If you used 2gb and I used 30gb, I would be shaped first (I think)
Click to expand...

'First' meaning that lighter users will be shaped after heavy users are shaped?

Edit: Looks like it works on intensity of shaping and not time

AUP:
Non-real time services will be shaped on a sliding scale, with our higher bandwidth users getting shaped more than lower bandwidth users, only on these services (NEVER on real time services)
Click to expand...
 
Last edited:
Zertop said:
Well... If you used 2gb and I used 30gb, I would be shaped first (I think)
Click to expand...

It works on projected usage. You could be using 20GB in 4 hours and the other person can be using 2GB every 5 minutes, the 2GB person's projected usages will classify him as a heavy user.
 
Anyone else having really bad ping to South african servers.. DayZ local servers 180ms
 
Afrigirl said:
Not sure if you had a change to read our shaping rules, we shape to manage demand. The new capacity has helped ease the shaping but if network demand grows again, we will need to shape more but the same rules apply - heaviest users to the lightest.
Click to expand...

This is what I do not understand.. Some say we shape heavy to lighter first, others say shape according to load no matter what your usage is on. So which one is it?
 
Type RSA said:
This is what I do not understand.. Some say we shape heavy to lighter first, others say shape according to load no matter what your usage is on. So which one is it?
Click to expand...

When the network starts coming under load they start shaping users from heaviest to lightest, until they are blanket shaping across the board if needs be.
 
Afrigirl said:
You can post a traceroute and we can try see where the delay is.
Click to expand...

Tracing route to 196-28-169-11.adsl.mweb.co.za [196.28.169.11]
over a maximum of 30 hops:

1 1 ms <1 ms 1 ms 192.168.1.1
2 214 ms 69 ms 50 ms 105-236-1-129-esr-lo.mtnbusiness.co.za [105.236.
1.129]
3 139 ms 100 ms 11 ms 41.181.221.246
4 65 ms 50 ms 43 ms qux-jh-dca-2.za-b.za.mtnbusiness.net [41.181.165
.115]
5 19 ms 25 ms 67 ms jh-dca-2.za--qux-b.za.mtnbusiness.net [41.181.16
5.114]
6 104 ms 38 ms 34 ms 41.181.180.10
7 35 ms 39 ms * 196.44.0.72
8 13 ms 10 ms 13 ms postfix.wipronet.co.za [196.22.161.133]
9 52 ms 43 ms 75 ms 197-80-7-34.jhb.mweb.co.za [197.80.7.34]
10 97 ms 48 ms 87 ms tengige0-0-0-0.cpt-p-1.mweb.co.za [197.84.4.34]

11 78 ms 51 ms 32 ms 197-84-5-238.cpt.mweb.co.za [197.84.5.238]
12 34 ms 49 ms 147 ms 196.28.178.66
13 116 ms 189 ms 259 ms gig5-1-cpt-opt-65-1.optinet.net [196.41.133.234]

14 39 ms 51 ms 72 ms OPTI-CPT-N1-Hosting.optinet.net [197.84.196.6]
15 * * * Request timed out.
16 86 ms 67 ms 110 ms 196-28-169-11.adsl.mweb.co.za [196.28.169.11]

Trace complete.
 
Okay, not sure what was going on, but I basically received the same crap speeds as what I was receiving at my previous ISP. (2.08Mbps for local and International on a 4Mbps line).
The latency was just better.

I eventually received my call back from their cancellation department and after it was confirmed that I really, really want to cancel, the call ended.

A few minutes later I suddenly received the speeds that I'm used to on this line for local and international.
At last I'm also a happy AH customer.
Haven't seen these speeds since late December.

3301509789.png
[/URL][/IMG]

It is almost if I was still locked into my old ISP policies, although I had Afrihost details in my router?
Not sure if it makes sense?
 
AfriMan said:
Sorry that you're battling with your line. What do you Network Test App results look like?
Click to expand...

ing Test:

ping 197.242.144.102

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


ping 8.8.8.8

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



Trace Test:

traceroute -n 197.242.144.102

1 192.168.0.1 1 ms 1 ms
2 105.236.234.6 7 ms 6 ms
3 41.181.51.1 11 ms 10 ms
4 41.181.198.1 10 ms 9 ms
5 196.44.18.2 8 ms 8 ms
6 196.44.31.1 9 ms 9 ms
7 196.44.31.6 32 ms 35 ms
8 196.44.31.9 30 ms
196.44.0.2 37 ms
9 196.31.220.1 32 ms
196.31.220.2 31 ms
10 196.31.220.2 32 ms
196.31.63.1 32 ms
11 197.242.144.1 31 ms 33 ms


traceroute -n 8.8.8.8

1 192.168.0.1 1 ms 1 ms
2 105.236.234.6 7 ms 22 ms
3 41.181.53.1 8 ms 8 ms
4 41.181.198.1 8 ms 10 ms
5 196.44.18.2 11 ms 9 ms
6 196.44.31.1 11 ms 9 ms
7 196.44.31.6 32 ms 33 ms
8 72.14.194.7 35 ms
41.181.139.1 29 ms
9 Request timed out *
72.14.194.7 37 ms
10 66.249.95.8 174 ms
11 Request timed out *



DNS Test:

nslookup www.afrihost.com

Name: www.afrihost.com
Address: 197.242.144.102


nslookup www.google.com

Name: www.google.com
Address: 173.194.34.145
Name: www.google.com
Address: 173.194.34.146
Name: www.google.com
Address: 173.194.34.147
Name: www.google.com
Address: 173.194.34.148
Name: www.google.com
Address: 173.194.34.144


nslookup thishouldfail.afrihost.com

** server can't find thisshouldfail.com: NXDOMAIN
 
Type RSA said:
This is what I do not understand.. Some say we shape heavy to lighter first, others say shape according to load no matter what your usage is on. So which one is it?
Click to expand...

Basically we look at demand first. If demand is not higher than available capacity - we don't shape (except maybe the very heaviest users who just need to be shaped all the time or they'll topple governments)

If we see that demand is higher than capacity, we start shaping from the most aggressive users, so that we shape the least number of users on the assumption that starting from the heaviest users will yield faster results. So we basically shape until demand falls in line with capacity and then we wait to see if the network settles (when I say wait, we're talking about a few seconds to minutes here). If there is room to unshape as demand settles we do. If we see demand picking up again, we shape more, until we effectively reach a sweet spot where we're giving away maximum bandwidth but preserving real-time throughput and keeping latencies steady.
 
wingnut771 said:
When the network starts coming under load they start shaping users from heaviest to lightest, until they are blanket shaping across the board if needs be.
Click to expand...

See my explanation below - but yours is much simpler. The only time we shape across the board is when demand is excessively high. With our current upgrade in place, this will probably not happen for some time :)
 
KoKaRoT said:
Tracing route to 196-28-169-11.adsl.mweb.co.za [196.28.169.11]
over a maximum of 30 hops:

1 1 ms <1 ms 1 ms 192.168.1.1
2 214 ms 69 ms 50 ms 105-236-1-129-esr-lo.mtnbusiness.co.za [105.236.
1.129]
3 139 ms 100 ms 11 ms 41.181.221.246
4 65 ms 50 ms 43 ms qux-jh-dca-2.za-b.za.mtnbusiness.net [41.181.165
.115]
5 19 ms 25 ms 67 ms jh-dca-2.za--qux-b.za.mtnbusiness.net [41.181.16
5.114]
6 104 ms 38 ms 34 ms 41.181.180.10
7 35 ms 39 ms * 196.44.0.72
8 13 ms 10 ms 13 ms postfix.wipronet.co.za [196.22.161.133]
9 52 ms 43 ms 75 ms 197-80-7-34.jhb.mweb.co.za [197.80.7.34]
10 97 ms 48 ms 87 ms tengige0-0-0-0.cpt-p-1.mweb.co.za [197.84.4.34]

11 78 ms 51 ms 32 ms 197-84-5-238.cpt.mweb.co.za [197.84.5.238]
12 34 ms 49 ms 147 ms 196.28.178.66
13 116 ms 189 ms 259 ms gig5-1-cpt-opt-65-1.optinet.net [196.41.133.234]

14 39 ms 51 ms 72 ms OPTI-CPT-N1-Hosting.optinet.net [197.84.196.6]
15 * * * Request timed out.
16 86 ms 67 ms 110 ms 196-28-169-11.adsl.mweb.co.za [196.28.169.11]

Trace complete.
Click to expand...

2nd hop looks terrible. Seeing that none of our networks are currently seeing latency, I would have to say this looks like it could be congestion on your local exchange :(
 
RoMark said:
Okay, not sure what was going on, but I basically received the same crap speeds as what I was receiving at my previous ISP. (2.08Mbps for local and International on a 4Mbps line).
The latency was just better.

I eventually received my call back from their cancellation department and after it was confirmed that I really, really want to cancel, the call ended.

A few minutes later I suddenly received the speeds that I'm used to on this line for local and international.
At last I'm also a happy AH customer.
Haven't seen these speeds since late December.

3301509789.png
[/URL][/IMG]

It is almost if I was still locked into my old ISP policies, although I had Afrihost details in my router?
Not sure if it makes sense?
Click to expand...

It's a bit weird I must admit. I can't see how an ISP account that you're not using could affect your bandwidth with us ... but I'm gonna go with the "If it ain't broke" thing here ;)
 
ClintonExsteen said:
ing Test:

ping 197.242.144.102

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


ping 8.8.8.8

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



Trace Test:

traceroute -n 197.242.144.102

1 192.168.0.1 1 ms 1 ms
2 105.236.234.6 7 ms 6 ms
3 41.181.51.1 11 ms 10 ms
4 41.181.198.1 10 ms 9 ms
5 196.44.18.2 8 ms 8 ms
6 196.44.31.1 9 ms 9 ms
7 196.44.31.6 32 ms 35 ms
8 196.44.31.9 30 ms
196.44.0.2 37 ms
9 196.31.220.1 32 ms
196.31.220.2 31 ms
10 196.31.220.2 32 ms
196.31.63.1 32 ms
11 197.242.144.1 31 ms 33 ms


traceroute -n 8.8.8.8

1 192.168.0.1 1 ms 1 ms
2 105.236.234.6 7 ms 22 ms
3 41.181.53.1 8 ms 8 ms
4 41.181.198.1 8 ms 10 ms
5 196.44.18.2 11 ms 9 ms
6 196.44.31.1 11 ms 9 ms
7 196.44.31.6 32 ms 33 ms
8 72.14.194.7 35 ms
41.181.139.1 29 ms
9 Request timed out *
72.14.194.7 37 ms
10 66.249.95.8 174 ms
11 Request timed out *



DNS Test:

nslookup www.afrihost.com

Name: www.afrihost.com
Address: 197.242.144.102


nslookup www.google.com

Name: www.google.com
Address: 173.194.34.145
Name: www.google.com
Address: 173.194.34.146
Name: www.google.com
Address: 173.194.34.147
Name: www.google.com
Address: 173.194.34.148
Name: www.google.com
Address: 173.194.34.144


nslookup thishouldfail.afrihost.com

** server can't find thisshouldfail.com: NXDOMAIN
Click to expand...

Your pings, when they complete, seem pretty normal. But the timeouts are concerning. Do you have an MTR test? Would be interesting to see if you are seeing packet loss intermittently on a trace :(
 
AfriMan said:
See my explanation below - but yours is much simpler. The only time we shape across the board is when demand is excessively high. With our current upgrade in place, this will probably not happen for some time :)
Click to expand...

I try follow the K.I.S.S. rule ;)
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X