Latency on web africa

S

somescrub

Well-Known Member
Joined
May 10, 2010
Messages
100
Reaction score
0
So I swopped from unshaped WA account to a 10gb account.
I only use WA for playing world of warcraft, no torrents downloads or even much browsing.
Since changing to this account I am getting random lag spikes.
Now I know that the way wow communicates now is looking like torrents to ISP's and hence will be subject to their shaping policies. This is the likely cause of the lag spikes.

I used to have 1GB unshaped which just wasnt enough cap for a month. I had no latency or lag spikes on this account. I was told by the sales consultant that WA does not offer unshaped anymore.

I have spoken to a few guilides who are also having these issues.
90% of our guild uses WA because of the superior performance. but if this continues we will be looking elsewhere for our premium bandwidth!

Why can WA not simply put in shaping exceptions for wow traffic. it is on specific ports, not used by anything else. It is low throughput so it is not going to effect network performance.
Or create a wow proxy service as a ancillary revenue stream, this way you know it's only used for wow!

since WA bandwidth comes at a premium price why even bother shaping it, surely if users spunk their cap at such a premium price that is good business.

Anyone who downloads torrents ect uses a uncapped service like mweb!

come on guys wheres the common sense gone at WA? you used to be so good!?

I and many others are happy to pay a premium for a premium service, but paying more and getting the same crap as on mweb uncapped just isnt fair.
 
somescrub said:
So I swopped from unshaped WA account to a 10gb account.
I only use WA for playing world of warcraft, no torrents downloads or even much browsing.
Since changing to this account I am getting random lag spikes.
Now I know that the way wow communicates now is looking like torrents to ISP's and hence will be subject to their shaping policies. This is the likely cause of the lag spikes.

I used to have 1GB unshaped which just wasnt enough cap for a month. I had no latency or lag spikes on this account. I was told by the sales consultant that WA does not offer unshaped anymore.

I have spoken to a few guilides who are also having these issues.
90% of our guild uses WA because of the superior performance. but if this continues we will be looking elsewhere for our premium bandwidth!

Why can WA not simply put in shaping exceptions for wow traffic. it is on specific ports, not used by anything else. It is low throughput so it is not going to effect network performance.
Or create a wow proxy service as a ancillary revenue stream, this way you know it's only used for wow!

since WA bandwidth comes at a premium price why even bother shaping it, surely if users spunk their cap at such a premium price that is good business.

Anyone who downloads torrents ect uses a uncapped service like mweb!

come on guys wheres the common sense gone at WA? you used to be so good!?

I and many others are happy to pay a premium for a premium service, but paying more and getting the same crap as on mweb uncapped just isnt fair.
Click to expand...

Morning somescrub,

Can you let me know which 10GB account you're using at the moment?
You're correct on the shaped vs. unshaped accounts - bandwidth prioritisation is far superior over shaping/ unshaped.

Have you had a look at our bandwidth profiles? Gaming should not be affected as the priority level is set to "medium" on our lowest packages.

What is your in-game latency looking like currently?
 
Hi Jeff.
I am on home complete smart 10GB at 599 (399 for 1st 3 months). I have a 512 line.
The issue isn't with latency, it's with spikes in it.
generally the latency is around 250ms-350ms.
I am using battelping to get from around 600ms down to what I said above.
Only since changing my package has these spikes started.
The game will freeze up and them burst through. so this is either prioritisation or packet loss. I have done a ping test and it isnt packet loss.
without battleping the spikes are even more pronounced and latency is much higher.

Wow server communication was changed in the last expansion to (edit: look like p2p activity ). this means that it is falling foul to your "Best effort" prioritisation.
whereas this is gameing traffic and should be on the medium prioritisation. What I'm saying is a special exclusion should be added for wow traffic.
There are many articles on the web about this and people complaining about this with ISP's all over the world

From Virgin UK:

Since the latest World of Warcraft update we have seen that the type of packets used by Blizzard to deliver the on-line gaming has changed significantly. This means that Virgin Media's National (ADSL) traffic management system is unable to recognise the packets as gaming traffic and assumes that they are peer to peer traffic. Due to this the traffic management system does not place the packets within the gaming queue which has the highest priority and lowest latency within the VM network, instead they fall into the peer to peer class which gets a low level of priority within our network and by default a higher level of latency.

We are working to try and rectify this as soon as we can with our traffic management supplier however it will take us a few weeks to upgrade the traffic manage solution so that is can recognise the new traffic class and correctly classify it as gaming. Unfortunately due to the nature of most traffic management solutions we can not manually move these packets into the gaming queue as the solution can not work out which ones to move.

We appreciate that some customers will have noticed a similar issue with the previous World of Warcraft update. The reason behind this is because gaming companies are not prepared to share the updates with Virgin Media or traffic management suppliers prior to its release and so the first time we see the new packets is when people start to use the new updates. We are trying to change this view point of the gaming companies however at present they are un-willing to work with us.

We apologise for the affect that this has on your gaming experience and we will update you when we have a confirmed fix date for this.
 
Last edited:
600ms isn't great at all, and should never be experienced on our network.
The packets sent by WoW have been addressed mid last year from what I can recall with changes being made to our network to resolve this. Things have been quiet from then - but might need a re-look again.

Can you please drop me a PM with your client code and DSL username so I can have this looked into?
 
Last night was especially horrendous,had to swap to a shaped account at another ISP to play even :(
 
there is a big difference between WA Cpt and WA jhb.
completely different data centres, and routes to the landing point.

WA jhb has issues, WA cpt is much better quality from what I see reported and from speaking to people. This is also common knowledge.
 
somescrub said:
there is a big difference between WA Cpt and WA jhb.
completely different data centres, and routes to the landing point.

WA jhb has issues, WA cpt is much better quality from what I see reported and from speaking to people. This is also common knowledge.
Click to expand...

PM received.
I've passed this on for some more digging to see what exactly is going wrong here.

JHB "issues" are more related to JINX peering than anything else. This is something that we're working on getting fully setup and functional soon :)
 
WAJeff said:
600ms isn't great at all, and should never be experienced on our network.
Click to expand...

I agree!

http://www.speedtest.net/result/1115314666.png

For weeks I was at 270, then for the last week or so it has increased to 570 and when I took the issue up with WA support they implied that everything was OK, which I found really annoying as how can this poor reduction in performance be OK??

I am in Durban

I do not understand trace routes, but here is one to the New York Times:


Tracing route to www.nytimes.com [199.239.136.200]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms 192.168.0.1
2 11 ms 11 ms 10 ms ndn-ip-esr-3.ipnet.wa.co.za [41.185.66.1]
3 35 ms 35 ms 34 ms vl105.cr.gw.cpt.za.wa.co.za [196.220.59.250]
4 35 ms 34 ms 34 ms vl31.er.gw.cpt.za.wa.co.za [41.185.0.153]
5 35 ms 35 ms 35 ms 41.66.150.177
6 185 ms 184 ms 185 ms 41.66.132.49
7 187 ms * 185 ms vl467.mpd01.lon01.atlas.cogentco.com [149.6.146.
157]
8 186 ms 185 ms 185 ms te3-2.ccr01.lon01.atlas.cogentco.com [130.117.1.
73]
9 266 ms 266 ms 265 ms te0-0-0-4.ccr22.bos01.atlas.cogentco.com [130.11
7.0.46]
10 266 ms 265 ms 266 ms 154.54.44.53
11 266 ms 266 ms 266 ms te2-2.ccr01.jfk07.atlas.cogentco.com [154.54.1.2
18]
12 265 ms 267 ms 265 ms ntt.jfk07.atlas.cogentco.com [154.54.11.66]
13 265 ms 263 ms 264 ms ae-2.r23.nycmny01.us.bb.gin.ntt.net [129.250.4.1
48]
14 265 ms 266 ms 266 ms po-3.r02.nycmny01.us.bb.gin.ntt.net [129.250.2.4
1]
15 365 ms 406 ms 412 ms ge-1-1.a00.nycmny01.us.da.verio.net [129.250.30.
113]
16 * * * Request timed out.
17 * * * Request timed out.
18 128.241.244.54 reports: Destination net unreachable.

Trace complete.


Hopefully this matter can be sorted out and I can get back to decent browsing
 
Tinuva said:
Those having problems, give us some traceroutes, it will help show where the problem is.
Click to expand...

Traceroutes to WHERE?! (sorry, frustrated). Doesn't seem to matter whether it is international or local, my speeds have been appalling since we opened last week for work. I could spend my day giving you traceroutes. Look at my speedtest results - I couldn't even get the pingtest to find a server to test with, that's how bad it is. I'll gladly give traceroutes if it will help, but I need something specific to trace, bearing in mind the general spread of the problem, else it's just a waste of my time - I have work to do. Surely if speeds are so bad (I think WAJeff mentioned JINX problems?) the issue must be known already?
 
You can literally trace anything, but sure trace bbc.co.uk. The 1st point of troubleshooting is to see if the problem is

1. Your line
2. Your exchange
3. Your exchange to WA network (this would be the SAIX IPC backhaul and can be different for any IPC based ISP which includes M-Web/IS/XDSL/Sainet/Cybersmart/MTN-B) ect.
4. The ISP network, again can be any of the above
5. Upstream prodiver to the network (this becomes a more diverse issue)

Now since you have a problem with everything, chances are good your problem can be anything from 1-4, surely a good starting point is to figure which one of those 4 it is.

If that doesn't explain why a traceroute is a good starting point for a test, be my guest and tell me how you would have it done?
 
Tinuva said:
You can literally trace anything, but sure trace bbc.co.uk. The 1st point of troubleshooting is to see if the problem is

1. Your line
2. Your exchange
3. Your exchange to WA network (this would be the SAIX IPC backhaul and can be different for any IPC based ISP which includes M-Web/IS/XDSL/Sainet/Cybersmart/MTN-B) ect.
4. The ISP network, again can be any of the above
5. Upstream prodiver to the network (this becomes a more diverse issue)

Now since you have a problem with everything, chances are good your problem can be anything from 1-4, surely a good starting point is to figure which one of those 4 it is.

If that doesn't explain why a traceroute is a good starting point for a test, be my guest and tell me how you would have it done?
Click to expand...

Kewl, will give it a go. What is the trace route command again...I've gone blank. Oh wait, goddit.
 
Tracing route to bbc.co.uk [212.58.224.138]
over a maximum of 30 hops:

1 * * * Request timed out.
2 11 ms 10 ms 10 ms tprn-ip-esr-2.ipnet.wa.co.za [41.185.76.1]
3 32 ms 32 ms 31 ms vl105.cr.gw.cpt.za.wa.co.za [196.220.59.250]
4 52 ms 70 ms 65 ms vl31.er.gw.cpt.za.wa.co.za [41.185.0.153]
5 96 ms 84 ms 119 ms 41.66.150.177
6 217 ms 217 ms 237 ms 41.66.132.49
7 379 ms 515 ms 567 ms vl467.mpd01.lon01.atlas.cogentco.com [149.6.146.
157]
8 202 ms 183 ms 183 ms te3-1.mpd02.lon01.atlas.cogentco.com [130.117.2.
26]
9 186 ms 275 ms 186 ms ldn-b4-link.telia.net [213.248.70.237]
10 320 ms 184 ms 183 ms ldn-bb2-link.telia.net [80.91.252.209]
11 219 ms 221 ms 184 ms ldn-b3-link.telia.net [80.91.247.88]
12 592 ms 549 ms 335 ms siemens-ic-119241-ldn-b2.c.telia.net [213.248.10
4.70]
13 405 ms 360 ms 405 ms 212.58.238.133
14 417 ms 356 ms 383 ms virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.
 
Tracing route to webafrica.co.za [196.220.58.66]
over a maximum of 30 hops:

1 * * * Request timed out.
2 16 ms 23 ms 19 ms tprn-ip-esr-2.ipnet.wa.co.za [41.185.76.1]
3 32 ms 32 ms 33 ms vl105.cr.gw.cpt.za.wa.co.za [196.220.59.250]
4 89 ms 90 ms 84 ms fe0.er1.gw.cpt.za.wadns.net [41.185.0.4]
5 50 ms 33 ms 33 ms wa-acc1.wadns.net [196.220.39.253]
6 35 ms 35 ms 36 ms 196.220.58.66

Trace complete.
 
Last one


Tracing route to cnn.com [157.166.255.18]
over a maximum of 30 hops:

1 * * * Request timed out.
2 93 ms 107 ms 96 ms tprn-ip-esr-2.ipnet.wa.co.za [41.185.76.1]
3 218 ms 213 ms 165 ms vl108.cr.gw.cpt.za.wa.co.za [196.220.59.238]
4 128 ms 135 ms 145 ms vl30.er.gw.cpt.za.wa.co.za [41.185.0.145]
5 81 ms 113 ms 127 ms 41.66.150.41
6 224 ms 218 ms 227 ms 41.66.132.49
7 235 ms 238 ms 230 ms vl467.mpd01.lon01.atlas.cogentco.com [149.6.146.
157]
8 262 ms 258 ms 252 ms te2-1.3493.mpd02.lon01.atlas.cogentco.com [130.1
17.2.18]
9 296 ms 291 ms 285 ms te0-3-0-4.ccr21.bos01.atlas.cogentco.com [154.54
.30.129]
10 274 ms 265 ms 268 ms 154.54.44.5
11 292 ms 292 ms 309 ms te0-2-0-7.mpd21.dca01.atlas.cogentco.com [154.54
.41.17]
12 283 ms 273 ms 273 ms te0-3-0-5.mpd21.iad02.atlas.cogentco.com [154.54
.41.246]
13 280 ms 273 ms 291 ms 206.111.0.229.ptr.us.xo.net [206.111.0.229]
14 290 ms 297 ms 288 ms vb2000d1.rar3.washington-dc.us.xo.net [207.88.13
.62]
15 326 ms 289 ms 289 ms ae0d0.mcr2.smyrna-ga.us.xo.net [216.156.0.70]
16 300 ms 317 ms 324 ms ae1d0.mcr1.smyrna-ga.us.xo.net [216.156.1.33]
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.
 
Now see, in that trace it looks like the problem is on the ISP's network, in which case you have full right to complain to them.

On hop 2 your line looks good (which looks like SAIX IPC network), hop 3 looks like the WA network, still solid albeit higher since you are in Pretoria North vs Cape Town which would explain that 20ms jump. Then hop 4 things start to become less solid up to hop 7 where it looks very wrong.

Could be shaping on your account type or a problem on their network, however I don't see the same from Cape Town, so probably your account.

Now looking at a trace on my account, I would say hop7 just generally look bad, but you have more later hops that all look bad.

As reference what it can look like:

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

  1     8 ms    <1 ms    <1 ms  [10.0.0.1]
  2     1 ms     1 ms    <1 ms  [192.168.1.254]
  3     8 ms     7 ms     7 ms  wblv-ip-esr-3.ipnet.wa.co.za [41.185.83.1]
  4     9 ms     8 ms     8 ms  vl105.cr.gw.cpt.za.wa.co.za [196.220.59.250]
  5     9 ms     8 ms     9 ms  vl30.er.gw.cpt.za.wa.co.za [41.185.0.145]
  6     9 ms     9 ms     8 ms  41.66.150.41
  7   161 ms   160 ms   160 ms  41.66.132.49
  8   267 ms   552 ms   185 ms  vl467.mpd01.lon01.atlas.cogentco.com [149.6.146.157]
  9   168 ms   161 ms   160 ms  te2-1.3493.mpd02.lon01.atlas.cogentco.com [130.117.2.18]
 10   177 ms   160 ms   161 ms  ldn-b4-link.telia.net [213.248.70.237]
 11   161 ms   160 ms   161 ms  ldn-bb2-link.telia.net [80.91.250.169]
 12   161 ms   161 ms   162 ms  ldn-b3-link.telia.net [80.91.251.237]
 13   161 ms   160 ms   161 ms  siemens-ic-119241-ldn-b2.c.telia.net [213.248.104.70]
 14   161 ms   162 ms   160 ms  212.58.238.149
 15   161 ms   160 ms   160 ms  virtual-vip.thdo.bbc.co.uk [212.58.224.138]

Trace complete.
 
Durandal said:
Last one


Tracing route to cnn.com [157.166.255.18]
over a maximum of 30 hops:

1 * * * Request timed out.
2 93 ms 107 ms 96 ms tprn-ip-esr-2.ipnet.wa.co.za [41.185.76.1]
3 218 ms 213 ms 165 ms vl108.cr.gw.cpt.za.wa.co.za [196.220.59.238]
4 128 ms 135 ms 145 ms vl30.er.gw.cpt.za.wa.co.za [41.185.0.145]
Click to expand...
Only saw this post now. That looks like the problem can already be on your line or exchange, and it just gets worse as it gets to the ISP's network. Hop 2 is your exchange, as it shows you are in Pretoria North. Problem for you could be your line, if not your line definitely your exchange that is over-utilized, and that will affect all your traffic.

Now, it also looks like the link from your exchange to the ISP's network is heavily over-utilized, since it gets 2x worse at the ISP's network.
 
Tinuva said:
Only saw this post now. That looks like the problem can already be on your line or exchange, and it just gets worse as it gets to the ISP's network. Hop 2 is your exchange, as it shows you are in Pretoria North. Problem for you could be your line, if not your line definitely your exchange that is over-utilized, and that will affect all your traffic.

Now, it also looks like the link from your exchange to the ISP's network is heavily over-utilized, since it gets 2x worse at the ISP's network.
Click to expand...

Strange that it shows us in Pretoria North, as we are based in the Randburg CBD, Johannesburg. Maybe that's where WA's Gauteng connection is based. We were also told at the time that the whole peering thing with MWEB would affect us here, as WA had two separate ...for lack of better word, 'bases'. The CT one was okay because they could peer there, but not so the JHB one, so we were going to be slower. Don't know if that is still applicable, because the whole peering thing seems to have gone quiet.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X