Afrihost POC Network - Afrigreen Feedback

[Igor III]

Not looking too bad, much better compared to the results you've previously posted

Agreed, it is no way near as stable as what it used to be, but it certainly is a huge improvement to what it was

 

[LaraC]

Doesn't look bad at all.
Would you be able to run another test at around 8pm tonight?

I shall.

 

[KillerBOB]

Were the network guys able to find the reason why business and uncapped customers had unsatisfactory throughput during evenings?

Good question, LaraC.

 

[electrofreeze]

i would say not enough ipc for peak times as the problem is still there

 

[LaraC]

Good question, LaraC.

Wow! A kind word from you. I'm almost speechless.

 

[AfriGuy]

Good question, LaraC.

I answered a little earlier

 

[AfriGuy]

i would say not enough ipc for peak times as the problem is still there

Also answered on the previous page, specifically for Afrigreen.

Demand generally increases in the evenings - so we're reaching some limitations on the network which causes slow throughput.
This should only really be affected P2P and downloads though.

 

[jmacc]

i would say not enough ipc for peak times as the problem is still there

I would say this sounds about right. There is an interesting post on MBB "Detecting-a-congested-ADSL-exchange-Guide"
The part in this post that I find particularly interesting is this: ".. technically a bad ISP can affect the first hop too since ISP IPC congestion will look the same. The easiest way around this is to re-do the test with a different ISP."

Most of us, at some point were told by Afrihost staff that when you run a tracert and the round trip times on the first hop (outside your walls) exceeds a certain millisecond count that it is Exchange congestion. This is obviously not correct.

 

[jmacc]

Account type: 10Mbps Home Capped.

Still very happy with AfriGreen’s performance.

View attachment 303834
View attachment 303836

Lara, would you mind running a tracert and posting your results.

 

[LaraC]

Lara, would you mind running a tracert and posting your results.

Is there a specific site I should test?

 

[Dianysis]

Demand generally increases in the evenings - so we're reaching some limitations on the network which causes slow throughput.
This should only really be affected P2P and downloads though.

Yeah but why does it seem to affect mostly uncapped and business uncapped?

 

[jmacc]

tracert www.google.co.za should be fine

 

[Igor III]

Agreed, it is no way near as stable as what it used to be, but it certainly is a huge improvement to what it was

Eeeeek, guess it was short lived



C:\Users\Mine> ping fweu1.en.perfectworld.eu -t

Pinging fweu1.en.perfectworld.eu [95.172.91.23] with 32 bytes of data:
Reply from 95.172.91.23: bytes=32 time=208ms TTL=37
Reply from 95.172.91.23: bytes=32 time=197ms TTL=37
Reply from 95.172.91.23: bytes=32 time=324ms TTL=37
Reply from 95.172.91.23: bytes=32 time=197ms TTL=37
Reply from 95.172.91.23: bytes=32 time=211ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=214ms TTL=37
Reply from 95.172.91.23: bytes=32 time=239ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=202ms TTL=37
Reply from 95.172.91.23: bytes=32 time=197ms TTL=37
Reply from 95.172.91.23: bytes=32 time=211ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=220ms TTL=37
Reply from 95.172.91.23: bytes=32 time=206ms TTL=37
Reply from 95.172.91.23: bytes=32 time=202ms TTL=37
Reply from 95.172.91.23: bytes=32 time=201ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=197ms TTL=37
Reply from 95.172.91.23: bytes=32 time=333ms TTL=37
Reply from 95.172.91.23: bytes=32 time=201ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=312ms TTL=37
Reply from 95.172.91.23: bytes=32 time=235ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=200ms TTL=37
Reply from 95.172.91.23: bytes=32 time=242ms TTL=37
Reply from 95.172.91.23: bytes=32 time=212ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=202ms TTL=37
Reply from 95.172.91.23: bytes=32 time=274ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=211ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=201ms TTL=37
Reply from 95.172.91.23: bytes=32 time=264ms TTL=37
Reply from 95.172.91.23: bytes=32 time=300ms TTL=37
Reply from 95.172.91.23: bytes=32 time=203ms TTL=37
Reply from 95.172.91.23: bytes=32 time=200ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=252ms TTL=37
Reply from 95.172.91.23: bytes=32 time=201ms TTL=37
Reply from 95.172.91.23: bytes=32 time=209ms TTL=37
Reply from 95.172.91.23: bytes=32 time=200ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=331ms TTL=37
Reply from 95.172.91.23: bytes=32 time=207ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=200ms TTL=37
Reply from 95.172.91.23: bytes=32 time=297ms TTL=37
Reply from 95.172.91.23: bytes=32 time=241ms TTL=37
Reply from 95.172.91.23: bytes=32 time=241ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=234ms TTL=37
Reply from 95.172.91.23: bytes=32 time=209ms TTL=37
Reply from 95.172.91.23: bytes=32 time=204ms TTL=37
Reply from 95.172.91.23: bytes=32 time=343ms TTL=37
Reply from 95.172.91.23: bytes=32 time=240ms TTL=37
Reply from 95.172.91.23: bytes=32 time=199ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=313ms TTL=37
Reply from 95.172.91.23: bytes=32 time=251ms TTL=37
Reply from 95.172.91.23: bytes=32 time=235ms TTL=37
Reply from 95.172.91.23: bytes=32 time=231ms TTL=37
Reply from 95.172.91.23: bytes=32 time=201ms TTL=37
Reply from 95.172.91.23: bytes=32 time=198ms TTL=37
Reply from 95.172.91.23: bytes=32 time=292ms TTL=37
Reply from 95.172.91.23: bytes=32 time=200ms TTL=37

Ping statistics for 95.172.91.23:
Packets: Sent = 73, Received = 73, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 197ms, Maximum = 343ms, Average = 223ms

 

[Dianysis]

I answered a little earlier

You still didn't answer why mostly uncapped and business uncapped seems to be affected.

 

[LaraC]

tracert www.google.co.za should be fine

Done.

Microsoft Windows [Version 10.0.10240]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\Lara>tracert google.co.za

Tracing route to google.co.za [216.58.223.35]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    46 ms    45 ms    46 ms  169-1-1-249.ip.afrihost.co.za [169.1.1.249]
  4    61 ms    49 ms    50 ms  169-1-1-250.ip.afrihost.co.za [169.1.1.250]
  5    67 ms    46 ms    45 ms  41.170.79.236
  6    44 ms    45 ms    45 ms  google.jb1.napafrica.net [196.46.25.166]
  7    49 ms    50 ms    50 ms  72.14.239.129
  8    46 ms    45 ms    45 ms  jnb01s08-in-f35.1e100.net [216.58.223.35]

Trace complete.

 

[jmacc]

Done.

Microsoft Windows [Version 10.0.10240]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\Lara>tracert google.co.za

Tracing route to google.co.za [216.58.223.35]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    46 ms    45 ms    46 ms  169-1-1-249.ip.afrihost.co.za [169.1.1.249]
  4    61 ms    49 ms    50 ms  169-1-1-250.ip.afrihost.co.za [169.1.1.250]
  5    67 ms    46 ms    45 ms  41.170.79.236
  6    44 ms    45 ms    45 ms  google.jb1.napafrica.net [196.46.25.166]
  7    49 ms    50 ms    50 ms  72.14.239.129
  8    46 ms    45 ms    45 ms  jnb01s08-in-f35.1e100.net [216.58.223.35]

Trace complete.

Those stats are not too good. According to the article on "Detecting a congested ADSL exchange - Guide" here on MBB Anything above 25 is suspicious and above 100 is pretty much guaranteed to be a problem. Note: seeing 100+ on later hops is normal if its an international site

 

[LaraC]

Those stats are not too good. According to the article on "Detecting a congested ADSL exchange - Guide" here on MBB Anything above 25 is suspicious and above 100 is pretty much guaranteed to be a problem.

Latency is high because I am routing via Johannesburg. AfriGreen doesn't have IPC in the south.
I'll do a trace to my local exchange.

 

[LaraC]

Local test.

Microsoft Windows [Version 10.0.10240]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\Lara>tracert bras.afrihost.com

Tracing route to bras.afrihost.com [155.239.255.250]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     6 ms     6 ms     6 ms  155.239.255.250

Trace complete.

 

[AfriGuy]

Yeah but why does it seem to affect mostly uncapped and business uncapped?

It doesn't. If Afrigreen's demand outweighs the capacity the experience will be poor across the board for resource intense protocols.
Either way - it's something that'll be fixed in production.

 

[AfriGuy]

Eeeeek, guess it was short lived



C:\Users\Mine> ping fweu1.en.perfectworld.eu -t

-snip

This matches what I'm seeing on monitoring. This is definitely something that will be fixed up in production.