Any Wondernet (used to be Seacom) clients on here?

Tralfamadore

Member
Joined
Jul 11, 2019
Messages
17
I'm also on Openserve.

The fact that during the day I can't watch any twitch (even 360p fails sometimes).

But then later its back to being somewhat normal. This was done now at 11:05

MAQNLrC.png


edit: 3:46 am

firefox_FRTEJDDYMg.png


edit 2:

After their fix, the past week has been fantastic. Pretty much always around the 90+ range (last few Mbps is probably due to my QoS settings)
 
Last edited:

whatever_sa

Well-Known Member
Joined
Feb 3, 2015
Messages
219
I have been on Macrolan/Seacom for a few months now with Octotel. It has been very bad compared to the past few years of VDSL.

The support of Seacom is super bad and pretty slow.

For a week now I have packet loss... They take days to ask a follow up question like a ping test.. then days later they ask for a trace route...

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

1 <1 ms <1 ms <1 ms 192.168.0.1
2 4 ms 2 ms 2 ms er-06-cpt.za.macrolan.co.za [129.205.159.44]
3 3 ms 1 ms 2 ms 105.22.65.125
4 * 20 ms 20 ms ce-0-3-0-0.cr-02-cpt.za.seacomnet.com [105.16.31.2]
5 25 ms 24 ms 24 ms xe-0-1-0-9.cr-02-jnb.za.seacomnet.com [105.16.11.105]
6 * * 24 ms ae-3-0.pp-01-jnb.za.seacomnet.com [105.16.28.8]
7 26 ms 26 ms 27 ms 74.125.51.130
8 27 ms 28 ms 28 ms 172.253.65.179
9 25 ms 24 ms 24 ms 216.239.40.199
10 28 ms 27 ms 29 ms jnb02s04-in-f3.1e100.net [172.217.170.67]


Trace complete.

Pinging www.google.co.za [172.217.170.67] with 32 bytes of data:
Ping statistics for 172.217.170.67:
Packets: Sent = 10, Received = 7, Lost = 3 (30% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 28ms, Average = 26ms




When Octotel had significant congestion when lockdown started, Seacom support did not investigate and told me its probably just the undersea cables... I had to do the research and tell them that lots of people are reporting Octotel issues in my area and Octotel confirmed they need to do upgrades. Once those upgrades were eventually done, problem solved.

Then there is the multiple hour outage a few months back (not load shedding related)...

I suppose it's time to find another ISP.


Update: Today I had to call in to get this current issue escalated to their NOC team after 1 week... They read the first line about packet loss and thought its Octotel - I had to point out that I sent them an MTR test showing all the packet loss is on seacom hosts.... Another fail...
 
Last edited:

Nutcracker

Active Member
Joined
Dec 19, 2005
Messages
56
I have a sneaking suspicion that selective peering policy is starting to come to play, at least for us based in CPT.
They are having to punt everything up to JHB and their NLD's are probably getting a little busy.

Octotel are clean as a whistle and so is Seacom's CPT network, but as soon as you leave the region it goes for a ball of chalk.

Here are my tests showing CPT as clean, but JHB as lossy:

Code:
[user@Untitled device] > tool traceroute 1.1.1.1
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 129.205.159.44 0% 135 1.5ms 7.5 1 260.4 31.2
2 105.22.65.125 0% 135 1.1ms 8.8 1 314.7 37.5
3 105.16.31.2 19.. 135 54.2ms 50.4 33.1 334.2 36.2
4 105.16.11.105 11.. 134 48.7ms 44.9 30.5 156.7 16
5 105.16.28.8 12.. 134 49.3ms 47.1 29.5 424.9 37.8
6 196.60.8.198 15.. 134 timeout 47.8 30.8 453.7 40.9
7 1.1.1.1 16.. 134 46.1ms 50.4 34.4 480.7 42.9


  980 1.1.1.1                                    56  59 52ms
981 1.1.1.1 56 59 51ms
982 1.1.1.1 56 59 49ms
983 1.1.1.1 56 59 53ms
984 1.1.1.1 56 59 52ms
985 1.1.1.1 timeout
986 1.1.1.1 56 59 51ms
987 1.1.1.1 56 59 52ms
988 1.1.1.1 56 59 55ms
989 1.1.1.1 timeout
990 1.1.1.1 timeout
991 1.1.1.1 56 59 53ms
992 1.1.1.1 56 59 52ms
993 1.1.1.1 56 59 52ms
994 1.1.1.1 56 59 51ms
995 1.1.1.1 56 59 53ms
996 1.1.1.1 timeout
997 1.1.1.1 56 59 49ms
998 1.1.1.1 56 59 52ms
999 1.1.1.1 56 59 53ms
sent=1000 received=804 packet-loss=19% min-rtt=25ms avg-rtt=36ms max-rtt=55ms

  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                                        
980 196.25.1.1 56 241 3ms
981 196.25.1.1 56 241 3ms
982 196.25.1.1 56 241 3ms
983 196.25.1.1 56 241 5ms
984 196.25.1.1 56 241 3ms
985 196.25.1.1 56 241 3ms
986 196.25.1.1 56 241 3ms
987 196.25.1.1 56 241 4ms
988 196.25.1.1 56 241 3ms
989 196.25.1.1 56 241 3ms
990 196.25.1.1 56 241 3ms
991 196.25.1.1 56 241 3ms
992 196.25.1.1 56 241 3ms
993 196.25.1.1 56 241 3ms
994 196.25.1.1 56 241 3ms
995 196.25.1.1 56 241 3ms
996 196.25.1.1 56 241 3ms
997 196.25.1.1 56 241 3ms
998 196.25.1.1 56 241 3ms
999 196.25.1.1 56 241 3ms
    sent=1000 received=1000 packet-loss=0% min-rtt=3ms avg-rtt=5ms max-rtt=48ms


C:\iperf-3.1.3-win64>iperf3.exe -R -V -t 15 -O 3 -c iperf.ct1.napafrica.net -u -b 10M
iperf 3.1.3
CYGWIN_NT-10.0 Nutty-PC 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Thu, 21 May 2020 19:35:55 GMT
Connecting to host iperf.ct1.napafrica.net, port 5201
Reverse mode, remote host iperf.ct1.napafrica.net is sending
Cookie: Nutty-PC.1590089755.874988.75a9e0507
[ 4] local 192.168.0.69 port 54689 connected to 196.10.99.34 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 3 seconds, 15 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.24 MBytes 10.4 Mbits/sec 1.019 ms 0/159 (0%) (omitted)
[ 4] 1.00-2.00 sec 1.19 MBytes 9.96 Mbits/sec 0.320 ms 0/152 (0%) (omitted)
[ 4] 2.00-3.00 sec 1.20 MBytes 10.0 Mbits/sec 0.410 ms 0/153 (0%) (omitted)
[ 4] 0.00-1.00 sec 1.20 MBytes 10.0 Mbits/sec 0.285 ms 0/153 (0%)
[ 4] 1.00-2.00 sec 1.19 MBytes 9.97 Mbits/sec 0.401 ms 0/152 (0%)
[ 4] 2.00-3.00 sec 1.20 MBytes 10.0 Mbits/sec 0.320 ms 0/153 (0%)
[ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 0.328 ms 0/153 (0%)
[ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 0.566 ms 0/152 (0%)
[ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 0.307 ms 0/153 (0%)
[ 4] 6.00-7.00 sec 1.20 MBytes 10.0 Mbits/sec 0.249 ms 0/153 (0%)
[ 4] 7.00-8.00 sec 1.19 MBytes 9.97 Mbits/sec 0.467 ms 0/152 (0%)
[ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 0.640 ms 0/153 (0%)
[ 4] 9.00-10.00 sec 1.19 MBytes 9.97 Mbits/sec 0.807 ms 0/152 (0%)
[ 4] 10.00-11.00 sec 1.20 MBytes 10.0 Mbits/sec 0.626 ms 0/153 (0%)
[ 4] 11.00-12.00 sec 1.19 MBytes 9.96 Mbits/sec 0.520 ms 0/152 (0%)
[ 4] 12.00-13.00 sec 1.20 MBytes 10.0 Mbits/sec 0.702 ms 0/153 (0%)
[ 4] 13.00-14.00 sec 1.19 MBytes 9.97 Mbits/sec 0.465 ms 0/152 (0%)
[ 4] 14.00-15.00 sec 1.20 MBytes 10.0 Mbits/sec 0.471 ms 0/153 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-15.00 sec 17.9 MBytes 10.0 Mbits/sec 0.443 ms 0/2290 (0%)
[ 4] Sent 2290 datagrams
CPU Utilization: local/receiver 1.2% (0.7%u/0.5%s), remote/sender 0.0% (0.0%u/0.0%s)

iperf Done.

C:\iperf-3.1.3-win64>iperf3.exe -R -V -t 15 -O 3 -c iperf.jb1.napafrica.net -u -b 10M
iperf 3.1.3
CYGWIN_NT-10.0 Nutty-PC 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Thu, 21 May 2020 19:36:20 GMT
Connecting to host iperf.jb1.napafrica.net, port 5201
Reverse mode, remote host iperf.jb1.napafrica.net is sending
Cookie: Nutty-PC.1590089780.085997.0b3e0a644
[ 4] local 192.168.0.69 port 53059 connected to 196.10.98.214 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 3 seconds, 15 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 880 KBytes 7.20 Mbits/sec 4.391 ms 49/159 (31%) (omitted)
[ 4] 1.00-2.00 sec 904 KBytes 7.41 Mbits/sec 0.564 ms 39/152 (26%) (omitted)
[ 4] 2.00-3.00 sec 920 KBytes 7.54 Mbits/sec 0.578 ms 38/153 (25%) (omitted)
[ 4] 0.00-1.00 sec 952 KBytes 7.78 Mbits/sec 0.693 ms 33/152 (22%)
[ 4] 1.00-2.00 sec 952 KBytes 7.80 Mbits/sec 0.839 ms 35/154 (23%)
[ 4] 2.00-3.00 sec 840 KBytes 6.89 Mbits/sec 0.553 ms 47/152 (31%)
[ 4] 3.00-4.00 sec 872 KBytes 7.14 Mbits/sec 0.656 ms 44/153 (29%)
[ 4] 4.00-5.00 sec 904 KBytes 7.40 Mbits/sec 0.702 ms 38/151 (25%)
[ 4] 5.00-6.00 sec 896 KBytes 7.34 Mbits/sec 0.736 ms 42/154 (27%)
[ 4] 6.00-7.00 sec 952 KBytes 7.80 Mbits/sec 0.640 ms 33/152 (22%)
[ 4] 7.00-8.00 sec 952 KBytes 7.81 Mbits/sec 0.917 ms 33/152 (22%)
[ 4] 8.00-9.00 sec 936 KBytes 7.67 Mbits/sec 1.262 ms 35/152 (23%)
[ 4] 9.00-10.00 sec 1000 KBytes 8.19 Mbits/sec 0.405 ms 29/154 (19%)
[ 4] 10.00-11.00 sec 928 KBytes 7.60 Mbits/sec 0.694 ms 36/152 (24%)
[ 4] 11.00-12.00 sec 960 KBytes 7.86 Mbits/sec 0.588 ms 32/152 (21%)
[ 4] 12.00-13.00 sec 904 KBytes 7.40 Mbits/sec 0.489 ms 41/154 (27%)
[ 4] 13.00-14.00 sec 936 KBytes 7.67 Mbits/sec 0.552 ms 36/153 (24%)
[ 4] 14.00-15.00 sec 952 KBytes 7.80 Mbits/sec 0.945 ms 33/152 (22%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-15.00 sec 18.0 MBytes 10.0 Mbits/sec 0.848 ms 548/2292 (24%)
[ 4] Sent 2292 datagrams
CPU Utilization: local/receiver 1.8% (0.9%u/0.9%s), remote/sender 0.0% (0.0%u/0.0%s)

iperf Done.

edit: limited to selective peering policy
 
Last edited:

tkburn

Well-Known Member
Joined
Aug 23, 2008
Messages
250
Switched over to my still active Octotel/SEACOM connection tonight when my Frogfoot/HC connection was under maintenance and the experience was appalling. Extremely high ping and packet loss, my experience was always good with them but the service seems to have gone to the dogs.
 

clickingbuttons

Expert Member
Joined
Mar 18, 2018
Messages
1,087
Switched over to my still active Octotel/SEACOM connection tonight when my Frogfoot/HC connection was under maintenance and the experience was appalling. Extremely high ping and packet loss, my experience was always good with them but the service seems to have gone to the dogs.

I'm in JHB On Vumatel Seacom.

I dont have packet loss but i do have 30+ms more latency at night as soon as traffic touches Seacoms routers.

I'll probably end up changing ISP's, again.
 

HeroNextDoor

Well-Known Member
Joined
Jul 12, 2014
Messages
179
Mweb JHB server 1591517789122.png
German Hetzner Server
1591517835882.png



Latency to Cape Town is fine
1591517904958.png

Latency to a Dutch dedicated server also fine
1591517972242.png
 

whatever_sa

Well-Known Member
Joined
Feb 3, 2015
Messages
219
I had a lot of problems with them, but after switching to Afrihost, it looks like the problem was that I used CloudFlare's DNS ... And on Afrihost even using Google's DNS server seems to lead to some other issues... So sticking to ISP DNS from now on.
 
Last edited:
Top