Afrihost CAPPED ADSL Feedback (MTN)

Status
Not open for further replies.
Just want to chime in and say that the entire MTN business ADSL network in the South has an inherent packet loss issue. It's one of the main reasons I left Afrihost.

Both Axxess and Afrihost show the same consistent packet loss on my end. I thought they would have figured this out by now though.

Don't think they were aware of it until yesterday. :/
 
+1 During Gaming, I find that Afrihost is the worst.

The unidentifiable issue with packet loss on Heroes of the Storm as well as League of Legends now again is rather frustrating.

Yeah, having issues with LoL/Smite for the last week.


Local, within Cape Town (SAIX):
4205532788.png
International (Vienna, ping used to be ~170-180, have throughput issues, sometimes better, sometimes worse according to graph):
4205524987.png
International (Vienna again, this has a better ping, but still has throughput issues, the graph goes up/down, up/down):
4205528509.png

The local one is done after, I have randomly terrible ping/throughput for a while, then it is good again.
 
Last edited:
I get what you say, and that is true. Right now however, something definitely is not right, as you can see those graphs in my previous post speak wonders about the packet loss on Afrihost, vs on Cybersmart where there is almost none.

If your IPCs are not at capacity, its fairly simple, it is the shaping devices that is throttling the traffic, so a normal MRTG graph will show you have loads of capacity available, when in reality the shaping device is actually artificially making it look lower than what the actual demand for traffic is. That would very well explain why there is so much packet loss issues right now.

Just look at those latency/packet loss graphs in my previous post again, and tell me if that is something you are proud off, knowing it is red on afrihost, and green on cybersmart. Same dsl line, same exchange, same routers, only different PPPoE sessions to different ISPs, both capped accounts.

Again, I think we need to see the packet loss to know exactly where you believe this is occurring. If you are pinging the BRAS, it means your traffic still goes through our network and then goes back to the BRAS (you're not simply pinging the device directly from your router) so it still does not demonstrate where you are saying packet loss occurs. Packet loss can't just occur everywhere, you will see it in specific places where there are either overloaded resources or high latency is introduced. I think we need to see specific information we can replicate, otherwise there is not much to go on.
 
Just with regard to comments on packet loss, I think we may be blurring the issue. If there is no packet loss on traceroute MTR's, it may be latency introduced in game that causes the packets used for testing packet loss to exceed their TTL. We need to see exactly which part of our route to the content server is dropping packets or we're pretty much shooting in the dark here.
 
Been like this on my end for well over a year, probably longer.

For sure, mines been like that too. Been using my Telkom account for gaming for quite some time now.

Although this is the first time I've seen them take it beyond "it's your line" type thing. How they are unable to replicate this, despite basically everyone from the South having the problem, is beyond me and quite worrying.
 
For sure, mines been like that too. Been using my Telkom account for gaming for quite some time now.

Although this is the first time I've seen them take it beyond "it's your line" type thing. How they are unable to replicate this, despite basically everyone from the South having the problem, is beyond me and quite worrying.

We have clients testing in the South for us and we're providing them with the same steps. It's not that we're saying we don't care or there's no problem, but we need to know exactly what the problem is by replicating it first and then troubleshooting to isolate the specific cause.
 
We have clients testing in the South for us and we're providing them with the same steps. It's not that we're saying we don't care or there's no problem, but we need to know exactly what the problem is by replicating it first and then troubleshooting to isolate the specific cause.

Ask them to boot up CSGO and play on ANY server between 19:00 - 21:00. As to how to track down where the issue is, that I have no idea.

If I can help at all let me know.
 
Just with regard to comments on packet loss, I think we may be blurring the issue. If there is no packet loss on traceroute MTR's, it may be latency introduced in game that causes the packets used for testing packet loss to exceed their TTL. We need to see exactly which part of our route to the content server is dropping packets or we're pretty much shooting in the dark here.
Lots of data to work with. Latency increases prior to the gaming cross connects. So IPC load balancing, capacity, or traffic tagging issues. Should be very easy to replicate. If you recently updated allot shaper then look there. If not, look at the load balancers. They'll also indicate a capacity problem if it exists. Happens on local and international, so not a routing problem moving out of the core. Happens across regions, so points to the core network (incoming), rather than backhaul routing issues as well. Ask customers to force UDP or TCP for traces and you'll start to get better data to work with as well, because contrary to what's been posted, it's priority tagged on traffic class and then moves into layer 7 bandwidth management. Should be easy to resolve.

Hope this helps...
 
Lots of data to work with. Latency increases prior to the gaming cross connects. So IPC load balancing, capacity, or traffic tagging issues. Should be very easy to replicate. If you recently updated allot shaper then look there. If not, look at the load balancers. They'll also indicate a capacity problem if it exists. Happens on local and international, so not a routing problem moving out of the core. Happens across regions, so points to the core network (incoming), rather than backhaul routing issues as well. Ask customers to force UDP or TCP for traces and you'll start to get better data to work with as well, because contrary to what's been posted, it's priority tagged on traffic class and then moves into layer 7 bandwidth management. Should be easy to resolve.

Hope this helps...

Definitely!

I'll pass this onto our Gamers running the tests for us.
 
Again, I think we need to see the packet loss to know exactly where you believe this is occurring. If you are pinging the BRAS, it means your traffic still goes through our network and then goes back to the BRAS (you're not simply pinging the device directly from your router) so it still does not demonstrate where you are saying packet loss occurs. Packet loss can't just occur everywhere, you will see it in specific places where there are either overloaded resources or high latency is introduced. I think we need to see specific information we can replicate, otherwise there is not much to go on.
Thank you for the template reply.
 
Last edited:
Thank you for the template reply, it doesn;t helps you or me. If you can't see by now that the issue is very much protocol based on your shaping devices...then I am afraid there is nothing anyone can do to help you fix the issue. Either you get updated protocol packs that fix it for the various affected services, or you look into the suggestions in the post with the graphs.

The protocol shaping would only affect our Uncapped users though. Our Capped and Business Uncapped user's traffic isn't passed through the system that handles the shaping for Uncapped accounts.

This is a high priority for us, I need to reiterate this, and we are in the process of making a few changes which we hope will improve our Gamers experience.
 
Just finished playing a CSGO matchmaking game with no loss. It was glorious.

Not exactly peak yet but so far so good.
 
Status
Not open for further replies.
Top
Sign up to the MyBroadband newsletter
X