Shocking service from OpenWeb

Indeed. Here are the tracerts that I sent to OpenWeb:

Local (via OpenWeb) -

ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.624 ms 2.439 ms 2.450 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 30.125 ms 42.802 ms 40.120 ms
3 cdsl1-ctn-vl2173.ip.isnet.net (196.38.72.113) 38.641 ms 34.033 ms 38.604 ms
4 196.35.115.128 (196.35.115.128) 30.698 ms 26.997 ms 24.610 ms
5 core2a-ctn-gi0-1.ip.isnet.net (168.209.2.6) 36.480 ms 27.081 ms 32.363 ms
6 168.209.2.131 (168.209.2.131) 32.132 ms 25.024 ms 23.604 ms
7 mweb-2.cinx.net.za (196.223.22.25) 21.768 ms 24.746 ms 19.797 ms
8 197-84-4-224.cpt.mweb.co.za (197.84.4.224) 51.958 ms 49.894 ms 51.382 ms
9 tengig0-0-0-0.vic-p-2.mweb.co.za (197.84.4.35) 56.190 ms 54.310 ms 49.167 ms
10 vl-12.vic-hscore-2.mweb.co.za (196.22.169.243) 52.061 ms 58.884 ms 71.468 ms
11 tengig-3-2.vic-core-sw2.mweb.co.za (196.22.169.70) 57.587 ms 59.705 ms 62.071 ms
12 197-81-229-4.jhb.mweb.co.za (197.81.229.4) 53.655 ms 48.716 ms 65.318 ms
13 197-81-229-11.jhb.mweb.co.za (197.81.229.11) 52.278 ms 54.699 ms 56.198 ms
14 164.75.28.196.netactive.net (196.28.75.164) 50.035 ms 48.670 ms 51.656 ms
15 vz8-jnb.vps.za-dns.com (41.86.113.70) 49.784 ms 60.517 ms 51.268 ms
16 geartri.be (41.86.113.44) 53.112 ms 49.436 ms 55.142 ms

International (via OpenWeb) -

ric-mac:~ ric$ traceroute rp.geartri.be
traceroute to rp.geartri.be (94.102.50.54), 64 hops max, 52 byte packets
1 home (10.0.0.2) 4.156 ms 2.090 ms 2.075 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 43.641 ms 44.383 ms 45.604 ms
3 cdsl2-ctn-vl2276.ip.isnet.net (196.38.72.125) 45.109 ms 41.564 ms 39.107 ms
4 196.35.115.136 (196.35.115.136) 38.541 ms 38.434 ms 38.356 ms
5 core2b-ctn-gi0-2.ip.isnet.net (168.209.6.3) 39.229 ms 41.033 ms 39.441 ms
6 168.209.246.3 (168.209.246.3) 196.779 ms 194.237 ms 412.359 ms
7 xe-0-4-0-6.r02.londen03.uk.bb.gin.ntt.net (83.231.235.221) 232.670 ms 381.369 ms 218.404 ms
8 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) 204.766 ms 203.544 ms
ae-4.r22.londen03.uk.bb.gin.ntt.net (129.250.5.24) 208.148 ms
9 linx.lon12.ip.tiscali.net (195.66.224.32) 197.456 ms
linx.lon20.ip.tiscali.net (195.66.236.32) 399.286 ms 217.714 ms
10 m247-gw.ip4.tinet.net (141.136.96.230) 191.356 ms 204.733 ms
xe-3-1-2.lon10.ip4.tinet.net (89.149.185.169) 217.319 ms
11 m247-gw.ip4.tinet.net (141.136.96.230) 208.331 ms
po-7-0-0.bb1.lon1.uk.m247.com (193.27.64.157) 404.364 ms 232.254 ms
12 po-7-0-0.bb1.lon1.uk.m247.com (193.27.64.157) 382.230 ms 257.543 ms
te-4-3-0.bb1.ams3.nl.m247.com (77.243.180.49) 458.436 ms
13 * * *
14 * * 94.102.50.54 (94.102.50.54) 391.638 ms

Local (via WebAfrica) -

ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.573 ms 2.331 ms 2.280 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 113.219 ms 118.877 ms 111.829 ms
3 cdsl2-ctn-vl2276.ip.isnet.net (196.38.72.125) 112.613 ms 98.111 ms 96.882 ms
4 196.35.115.136 (196.35.115.136) 93.417 ms 85.653 ms 87.232 ms
5 core2a-ctn-gi0-2.ip.isnet.net (168.209.6.6) 92.244 ms 90.391 ms 99.052 ms
6 168.209.2.131 (168.209.2.131) 99.892 ms 92.778 ms 78.113 ms
7 mweb-2.cinx.net.za (196.223.22.25) 90.300 ms 93.305 ms 88.851 ms
8 197-84-4-224.cpt.mweb.co.za (197.84.4.224) 115.080 ms 121.547 ms 128.878 ms
9 tengig0-0-0-0.vic-p-2.mweb.co.za (197.84.4.35) 142.748 ms 149.185 ms 141.472 ms
10 vl-12.vic-hscore-2.mweb.co.za (196.22.169.243) 144.982 ms 136.785 ms 151.015 ms
11 tengig-3-2.vic-core-sw2.mweb.co.za (196.22.169.70) 159.754 ms 161.029 ms 155.485 ms
12 197-81-229-4.jhb.mweb.co.za (197.81.229.4) 144.729 ms 138.668 ms 131.723 ms
13 197-81-229-15.jhb.mweb.co.za (197.81.229.15) 122.906 ms 125.553 ms 117.270 ms
14 164.75.28.196.netactive.net (196.28.75.164) 123.651 ms 115.185 ms 116.558 ms
15 vz8-jnb.vps.za-dns.com (41.86.113.70) 122.839 ms 118.304 ms 124.982 ms
16 geartri.be (41.86.113.44) 127.843 ms 135.946 ms 130.386 ms

International (via WebAfrica) -

ric-mac:~ ric$ traceroute rp.geartri.be
traceroute to rp.geartri.be (94.102.50.54), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.524 ms 2.227 ms 2.257 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 120.828 ms 122.251 ms 137.068 ms
3 cdsl1-ctn-vl2173.ip.isnet.net (196.38.72.113) 132.842 ms 134.708 ms 136.790 ms
4 196.35.115.128 (196.35.115.128) 128.021 ms 123.722 ms 143.143 ms
5 core1b-ctn-gi0-2.ip.isnet.net (168.209.6.4) 129.490 ms 135.403 ms 114.319 ms
6 168.209.246.3 (168.209.246.3) 287.726 ms 258.231 ms 246.297 ms
7 xe-0-4-0-6.r02.londen03.uk.bb.gin.ntt.net (83.231.235.221) 240.157 ms 249.768 ms 249.797 ms
8 ae-4.r22.londen03.uk.bb.gin.ntt.net (129.250.5.24) 243.019 ms 236.911 ms
ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) 211.664 ms
9 linx.lon20.ip.tiscali.net (195.66.236.32) 237.832 ms
linx.lon12.ip.tiscali.net (195.66.224.32) 410.716 ms 284.073 ms
10 xe-5-2-0.lon10.ip4.tinet.net (89.149.185.74) 432.258 ms
xe-2-2-1.lon10.ip4.tinet.net (89.149.180.94) 256.980 ms
m247-gw.ip4.tinet.net (141.136.96.230) 263.801 ms
11 po-7-0-0.bb1.lon1.uk.m247.com (193.27.64.157) 262.232 ms
m247-gw.ip4.tinet.net (141.136.96.230) 256.743 ms 267.419 ms
12 te-4-3-0.bb1.ams3.nl.m247.com (77.243.180.49) 476.604 ms 257.835 ms
po-7-0-0.bb1.lon1.uk.m247.com (193.27.64.157) 231.711 ms
13 te-4-3-0.bb1.ams3.nl.m247.com (77.243.180.49) 431.161 ms 232.162 ms 381.818 ms
14 94.102.50.54 (94.102.50.54) 235.199 ms 378.910 ms *

And here is typical behavior when connected to OpenWeb:

ric-mac:~ ric$ ping openweb.co.za
PING openweb.co.za (41.72.150.7): 56 data bytes
64 bytes from 41.72.150.7: icmp_seq=0 ttl=51 time=256.125 ms
64 bytes from 41.72.150.7: icmp_seq=1 ttl=51 time=128.281 ms
64 bytes from 41.72.150.7: icmp_seq=2 ttl=51 time=138.995 ms
64 bytes from 41.72.150.7: icmp_seq=3 ttl=51 time=157.123 ms
64 bytes from 41.72.150.7: icmp_seq=4 ttl=51 time=125.274 ms
64 bytes from 41.72.150.7: icmp_seq=5 ttl=51 time=134.179 ms
64 bytes from 41.72.150.7: icmp_seq=6 ttl=51 time=134.996 ms
64 bytes from 41.72.150.7: icmp_seq=7 ttl=51 time=127.122 ms
64 bytes from 41.72.150.7: icmp_seq=8 ttl=51 time=71.285 ms
64 bytes from 41.72.150.7: icmp_seq=9 ttl=51 time=78.350 ms
64 bytes from 41.72.150.7: icmp_seq=10 ttl=51 time=126.051 ms
64 bytes from 41.72.150.7: icmp_seq=11 ttl=51 time=103.863 ms
64 bytes from 41.72.150.7: icmp_seq=12 ttl=51 time=150.119 ms
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24

C O N G E S T I O N.
And it's not only on your OW account.
 
Fluffy, please post a copy of "tracert -d 8.8.8.8" while the openweb account pings time out "drop".

I've submitted notice of immediate termination of the account last week; whether they keep the account active or not is their own prerogative. Also, it would be traceroute -n on *nix:)
 
Why [-]Larry[/-] fluffy, why?

Because I had hoped that this would be sorted out very quickly, and it would fly from there. I don't mind paying a few hundred Rand if the ISP is busy resolving the matter, but that was evidently not the case.
 
C O N G E S T I O N.
And it's not only on your OW account.

Be that as it may, a congested line would not cause all traffic to null-route for several minutes after intervals of it working fine. So arguing that congestion is "in play" is fine, but arguing that congestion caused the issue makes no sense.
 
Fluffy!

I believe you have made a huge mistake. You cannot use something like tracert or traceroute to troubleshoot connectivity issues. Download pingplotter instead.

You will most likely quickly realize that the problem with your latency is on your first hop. The issues you describe and the traceroute posted look exactly like the kind of problems I am having. I have looked at so many of this by now that I am almost certain that you are experiencing some form of telkom exchange screwup.

The reason I say this is I have not come across any explanations about what exactly is going on in these exchanges. How are they set up? OpenWeb came after those other ISPs, so maybe the way that they implement it causes the last one to lose out.

Also, I am convinced that whoever is running these telkom exchanges don't know what they are doing.

Go run that proggy and check. You will notice crazy random lag on your first hop that is worse at certain times of the day.


PS - Ashara! Is Trath organizing a reunion? ;)

PingPlotter is a Windows program, I'm a BSD/Linux/OS X user. I have used smokeping and munin to effectively graph the traffic. It actually doesn't matter what the problem was/is, the bottom line is that OpenWeb did not resolve it, and didn't really even try that hard. It stands unresolved, and as I have already switched away to AfriHost (who are doing just fine, thank you) the onus is no longer on me or on OpenWeb to fix anything.

Also, OpenWeb did not come after anyone - they are simply an IS reseller with, presumably, their own traffic management suite on the IS infrastructure. They are, effectively, IS as far as Telkom are concerned.
 
This post brings back ghosts from the past from my Gold Uncapped account! I was with these guys for over a year with on and off problems similar to OP. Each time, I was assigned a new username and that would rectify the problem. Then out of the blue, I get assigned a username on another network after complaining of 1/4 linespeed. The new network was worse, so I was assigned to another network. That network was as bad as the previous one. I was then given a Telkom guest account - which worked at full line speed. I responded by saying Now that is what I'm talking about! Perfect! I was again moved back to the first network which was at 1/4 line speed again. After complaining, I was told to report a fault with Telkom.

I refuted this by mentioning that I have used a Telkom test account which works pretty much the same as the backup Telkom account I had (ie full speed) With each complaint for each network I was moved to, I would send them screenshots detailing how their network was behaving in comparison with my Telkom account. I was eventually told that they do not accept responsibility as they have advised me to log a fault with Telkom and had gone beyond the call of duty by moving me across all 3 of their networks - all of which they said have no issues.

Somewhere in my second last response, I mentioned that I am not getting the service I am paying for - Their response was highlighting that wording in bold and writing 'would you like me to terminate your account?' So, naturally, my last response was HELL YES! Ok, so I was not that abrasive.. I merely replied that, if they could not provide me with the service I am paying in advance for, that I would be left with no alternative but to request termination of my account. The immediate reply was that my account would be terminated by month end.

Over the period I had the account and by reading in their thread, I find Openweb too trigger happy with the Please Log a fault with Telkom bit. The day I cancelled my account, I contacted MWeb and was on full line speed within the hour. So much for Telkom being at fault. Not to mention that Telkom bill you if a fault is not found.
 
Last edited:
This post brings back ghosts from the past from my Gold Uncapped account! I was with these guys for over a year with on and off problems similar to OP.

Too many people in this thread and contacting me outside of it for my experience to be coincidental or my "fault". There is clearly an underlying problem here.
 
I've submitted notice of immediate termination of the account last week; whether they keep the account active or not is their own prerogative. Also, it would be traceroute -n on *nix:)
Sure it doesn't matter what OS you use, but since you are on *nix, why not use "mtr"?

Too bad you won't be able to do such a traceroute anymore. Why you didn't do it initially after seeing a timeout on ping...makes me question just how tech savvy you are, maybe you are a bit, but your troubleshooting skills must be lacking. A traceroute when things are working doesn't say much, a traceroute when it is broken can tell one a lot more.

How on earth did you expect OpenWeb to get the problem sorted with useless information? and/or missing/incomplete information.

Edit: And before you come bash on me, let me highlight a few facts:
1. OpenWeb stated in this thread the support query is still open, which means the account is still active because they are willing to help you. Yet you refuse to do a simple test.
2. I had to ask 2 times for a test, before you let me know with a friendly smile, because you submitted a cancellation, you won't do the test, without even checking if the account is active.
3. You have given them barely a week to try and resolve the issue, let me tell you now, some issues just don't get fixed in that amount of time, hell even for Telkom it sometimes takes months (yes months, not weeks) to fix an issue, look a the congested exchanges, and just how long it take those to get fixed.
4. I personally dislike Openweb, but now I starting to think I should side with them. Even after how they decided to pull their disclaimer card here, which I btw very much dislike. Yet they are still willing to help, by keeping the support ticket open.
 
Last edited:
Sure it doesn't matter what OS you use, but since you are on *nix, why not use "mtr"?

Too bad you won't be able to do such a traceroute anymore. Why you didn't do it initially after seeing a timeout on ping...makes me question just how tech savvy you are, maybe you are a bit, but your troubleshooting skills must be lacking. A traceroute when things are working doesn't say much, a traceroute when it is broken can tell one a lot more.

How on earth did you expect OpenWeb to get the problem sorted with useless information? and/or missing/incomplete information.

I did what I had to in order to establish that my router was sending packets out, but after that, I don't see why I should proactively diagnose the problem to the nth degree? I logged the fault with the ISP, they asked for a traceroute from both (working) environments. I fully agree that a traceroute from the dead environment would have been more useful. And had they asked for output from mtr or netcat -g I would, obviously, have provided it. But they didn't, and they didn't really do much to assist me in solving the problem, so this is a moot discussion.
 
Sure it doesn't matter what OS you use, but since you are on *nix, why not use "mtr"?

Too bad you won't be able to do such a traceroute anymore. Why you didn't do it initially after seeing a timeout on ping...makes me question just how tech savvy you are, maybe you are a bit, but your troubleshooting skills must be lacking. A traceroute when things are working doesn't say much, a traceroute when it is broken can tell one a lot more.

How on earth did you expect OpenWeb to get the problem sorted with useless information? and/or missing/incomplete information.

Therein lies the problem. No one should need to be 'Tech Savvy' to get a service advertised. All the 'Tech' stuff should be the ISP's responsibility. No mater how tech savvy you may be - or not. That is all part of a service we as users pay for. Imagine my Granny being told she must do a traceroute! She will show the ISP the traceroute of her veiny middle finger...

It really is the problem with ISP's who are resellers. They are constantly needing you to figure out why their product is failing. Although MWeb are not too different either. The point of selling is apply and deliver. Not apply and 'oh well, that;s not delivering, so why don't you do a traceroute and contact Telkom (PS... thanx 4 tha prompt payment:).

Reason number 1 that I am on Telkom's uncapped over any other ISP. So far, it's working out just fine. That, and they won't try to steer me into 'terminating a problem' which is actually their own.
 
Last edited:
Because I had hoped that this would be sorted out very quickly, and it would fly from there. I don't mind paying a few hundred Rand if the ISP is busy resolving the matter, but that was evidently not the case.
But R19/gb is also available. R40 more that you pay per gig and you can get 10gb from Telkom or elsewhere.
 
Sure it doesn't matter what OS you use, but since you are on *nix, why not use "mtr"?

Too bad you won't be able to do such a traceroute anymore. Why you didn't do it initially after seeing a timeout on ping...makes me question just how tech savvy you are, maybe you are a bit, but your troubleshooting skills must be lacking. A traceroute when things are working doesn't say much, a traceroute when it is broken can tell one a lot more.

How on earth did you expect OpenWeb to get the problem sorted with useless information? and/or missing/incomplete information.

Edit: And before you come bash on me, let me highlight a few facts:
1. OpenWeb stated in this thread the support query is still open, which means the account is still active because they are willing to help you. Yet you refuse to do a simple test.
2. I had to ask 2 times for a test, before you let me know with a friendly smile, because you submitted a cancellation, you won't do the test, without even checking if the account is active.
3. You have given them barely a week to try and resolve the issue, let me tell you now, some issues just don't get fixed in that amount of time, hell even for Telkom it sometimes takes months (yes months, not weeks) to fix an issue, look a the congested exchanges, and just how long it take those to get fixed.
4. I personally dislike Openweb, but now I starting to think I should side with them. Even after how they decided to pull their disclaimer card here, which I btw very much dislike. Yet they are still willing to help, by keeping the support ticket open.

Did you miss the part that they started ignoring his emails? So there's no point in them saying the ticket is one in this thread when they stopped responding almost a week ago.

My experience with openweb is identical to subxero...
 
Last edited:
Indeed. Here are the tracerts that I sent to OpenWeb:

Local (via OpenWeb) -

ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.624 ms 2.439 ms 2.450 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 30.125 ms 42.802 ms 40.120 ms
3 cdsl1-ctn-vl2173.ip.isnet.net (196.38.72.113) 38.641 ms 34.033 ms 38.604 ms
4 196.35.115.128 (196.35.115.128) 30.698 ms 26.997 ms 24.610 ms
5 core2a-ctn-gi0-1.ip.isnet.net (168.209.2.6) 36.480 ms 27.081 ms 32.363 ms
6 168.209.2.131 (168.209.2.131) 32.132 ms 25.024 ms 23.604 ms
...............

Local (via WebAfrica) -

ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.573 ms 2.331 ms 2.280 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 113.219 ms 118.877 ms 111.829 ms
3 cdsl2-ctn-vl2276.ip.isnet.net (196.38.72.125) 112.613 ms 98.111 ms 96.882 ms
4 196.35.115.136 (196.35.115.136) 93.417 ms 85.653 ms 87.232 ms
5 core2a-ctn-gi0-2.ip.isnet.net (168.209.6.6) 92.244 ms 90.391 ms 99.052 ms
6 168.209.2.131 (168.209.2.131) 99.892 ms 92.778 ms 78.113 ms

..............

fluffy, post some speedtest results here. Local and international on both the OW and WA accounts. Looks to me like both those accounts are using exactly the same routes.

Check the traceroutes on page 3 - it is exactly the same route. So it is not congestion or the backhaul or Telkom.

not sure if significant - but hops 3,4 and 5 is different...

*edit*

quoted from earlier in thread - notice that you are not able to trace anymore.

but have to agree - its with the ISP to provide step by step troubleshooting steps in order to allow them to focus in on the problem.
(and not respond to emails on a 12 hourly basis .... :O :O :O ( that was freaky - seeing an email in the morning, and then only after a follow up before 5pm is some action given.
support center congested maybe? ( or problematic escalation system......) (and nope - they were not requesting or waiting for info form fluffy for more than 10minutes at a time

TIA ? ? ? ( sometimes i wonder if people think they need to stick to the africa level of service
 
Last edited:
Whoa... Loads of pitchforks and fire torches here!

Let's hope it all gets resolved asap.

Who is next I wonder? :o

Peace.
 
Edit: And before you come bash on me, let me highlight a few facts:
1. OpenWeb stated in this thread the support query is still open, which means the account is still active because they are willing to help you. Yet you refuse to do a simple test.
2. I had to ask 2 times for a test, before you let me know with a friendly smile, because you submitted a cancellation, you won't do the test, without even checking if the account is active.
3. You have given them barely a week to try and resolve the issue, let me tell you now, some issues just don't get fixed in that amount of time, hell even for Telkom it sometimes takes months (yes months, not weeks) to fix an issue, look a the congested exchanges, and just how long it take those to get fixed.
4. I personally dislike Openweb, but now I starting to think I should side with them. Even after how they decided to pull their disclaimer card here, which I btw very much dislike. Yet they are still willing to help, by keeping the support ticket open.

Dude what planet are you living on?!

1. I don't care, I've cancelled it, I am not required to problem solve the account when it has escalated to this point. Your insinuation that I should continue troubleshooting the problem when they have ignored my emails is, frankly, insulting.

2. Aaaaand...who are you? I don't need to drop my pants and traceroute because you ask me to - see point 1.

3. This is 110% about managing the customer. Had they kept me updated with regularity, explained what they were doing (in brief, laymen's terms even) to resolve the issue, and taken positive steps towards identifying the problem I would not have become frustrated and moved elsewhere. Bear in mind, too, that I have many choices when it comes to an ISP, so I am not forced to wait for them to resolve the issue. They were given ample opportunity and they chose, instead, not to resolve the problem.

4. Keeping the support ticket open after I've cancelled my account is of no use to anyone. It's a poor play after they've been shown up, and it doesn't help on any level.
 
Indeed. Here are the tracerts that I sent to OpenWeb:

Local (via OpenWeb) -
ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.624 ms 2.439 ms 2.450 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 30.125 ms 42.802 ms 40.120 ms

International (via OpenWeb) -
ric-mac:~ ric$ traceroute rp.geartri.be
traceroute to rp.geartri.be (94.102.50.54), 64 hops max, 52 byte packets
1 home (10.0.0.2) 4.156 ms 2.090 ms 2.075 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 43.641 ms 44.383 ms 45.604 ms

Local (via WebAfrica) -
ric-mac:~ ric$ traceroute sexybikinis.co.za
traceroute to sexybikinis.co.za (41.86.113.44), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.573 ms 2.331 ms 2.280 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 113.219 ms 118.877 ms 111.829 ms

International (via WebAfrica) -
ric-mac:~ ric$ traceroute rp.geartri.be
traceroute to rp.geartri.be (94.102.50.54), 64 hops max, 52 byte packets
1 home (10.0.0.2) 2.524 ms 2.227 ms 2.257 ms
2 196-210-150-1.dynamic.isadsl.co.za (196.210.150.1) 120.828 ms 122.251 ms 137.068 ms

i have a question regarding these traceroutes that you pasted earlier.

we all know that the 2nd hop is an indication of congestion within the telkom exchange so did you do your tests at the same time, or close to each other, seeing that your webafrica testing shows much higher latency on the 2nd hop than with the openweb account.

j.
 
Top
Sign up to the MyBroadband newsletter
X