Cool Ideas Fibre ISP - Feedback

Status
Not open for further replies.
International looking a bit unimpressive this morning. Packet loss on all iperfs

############## iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c lnms.cisp.co.za
[ 4] 0.00-10.00 sec 95.8 MBytes 80.4 Mbits/sec 0.173 ms 38/71465 (0.053%)

############## iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c trcvmh01.cisp.co.za
[ 4] 0.00-10.00 sec 96.0 MBytes 80.5 Mbits/sec 0.194 ms 33/71600 (0.046%)

############## iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c cptspeedtest.cisp.co.za
[ 4] 0.00-10.00 sec 96.0 MBytes 80.5 Mbits/sec 0.185 ms 90/71603 (0.13%)

############## iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c queen.cisp.co.za
[ 4] 0.00-10.00 sec 97.3 MBytes 81.6 Mbits/sec 0.175 ms 17/72614 (0.023%)


############## Randburg - Cool Ideas Multi
speedtest-cli --simple --server 6591 --secure
Ping: 6.657 ms
Download: 88.81 Mbit/s
Upload: 50.52 Mbit/s
############## Randburg - Cool Ideas Single
speedtest-cli --simple --server 6591 --secure --single
Ping: 5.836 ms
Download: 88.11 Mbit/s
Upload: 46.75 Mbit/s

############## London - Coreix Multi
speedtest-cli --simple --server 8066 --secure
Ping: 192.982 ms
Download: 45.20 Mbit/s
Upload: 30.61 Mbit/s
############## London - Coreix Single
speedtest-cli --simple --server 8066 --secure --single
Ping: 163.586 ms
Download: 9.49 Mbit/s
Upload: 6.18 Mbit/s

############## London - Vodafone UK Multi
speedtest-cli --simple --server 2789 --secure
Ping: 255.536 ms
Download: 24.71 Mbit/s
Upload: 38.31 Mbit/s
############## London - Vodafone UK Single
speedtest-cli --simple --server 2789 --secure --single
Ping: 165.087 ms
Download: 7.68 Mbit/s
Upload: 10.71 Mbit/s
 
Surely this is not normal. Octotel 100/100. Send test is fine from CPT to JHB.

Code: 
iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c lnms.cisp.co.za
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  96.0 MBytes  80.5 Mbits/sec  1.181 ms  28796/71516 (40%)
[  4] Sent 71516 datagrams
[SUM]  0.0-10.0 sec  27314 datagrams received out-of-order

iperf Done.

Some math. Out of the odd 43K packets received, 27K was out of order.

Not sure how to interpret this, but it looks like something is forwarding me duplicate packets and just dropping others.

Code: 
iperf3: OUT OF ORDER - incoming packet = 86000 and received packet = 86001 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86010 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86011 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86013 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86025 and received packet = 86026 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86039 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86041 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86043 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86047 and received packet = 86050 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86049 and received packet = 86052 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86051 and received packet = 86052 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86053 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86055 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86057 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86061 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86063 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86065 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86069 and received packet = 86074 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86071 and received packet = 86074 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86073 and received packet = 86074 AND SP = 4
 
Ummm, connection just died completely in North Riding (Evotel), what's wrong now? Is it typical CISP holiday issues?
 
leppie said:
Surely this is not normal. Octotel 100/100. Send test is fine from CPT to JHB.

Code: 
iperf3 --port 17001 --bandwidth 80M -l 1400 --omit 2 -R -u -c lnms.cisp.co.za
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  96.0 MBytes  80.5 Mbits/sec  1.181 ms  28796/71516 (40%)
[  4] Sent 71516 datagrams
[SUM]  0.0-10.0 sec  27314 datagrams received out-of-order

iperf Done.

Some math. Out of the odd 43K packets received, 27K was out of order.

Not sure how to interpret this, but it looks like something is forwarding me duplicate packets and just dropping others.

Code: 
iperf3: OUT OF ORDER - incoming packet = 86000 and received packet = 86001 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86010 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86011 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86013 and received packet = 86014 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86025 and received packet = 86026 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86039 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86041 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86043 and received packet = 86044 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86047 and received packet = 86050 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86049 and received packet = 86052 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86051 and received packet = 86052 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86053 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86055 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86057 and received packet = 86058 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86061 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86063 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86065 and received packet = 86066 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86069 and received packet = 86074 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86071 and received packet = 86074 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 86073 and received packet = 86074 AND SP = 4
Click to expand...

I have it too along with nearly 2% packet loss.

Octotel 100/25. Cape Town, Southern Suburbs.

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 95.9 MBytes 80.5 Mbits/sec 0.092 ms 232/12278 (1.9%)
[ 4] Sent 12278 datagrams
[SUM] 0.0-10.0 sec 211 datagrams received out-of-order

iperf Done.
 
image132 said:
I have it too along with nearly 2% packet loss.

Octotel 100/25. Cape Town, Southern Suburbs.

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 95.9 MBytes 80.5 Mbits/sec 0.092 ms 232/12278 (1.9%)
[ 4] Sent 12278 datagrams
[SUM] 0.0-10.0 sec 211 datagrams received out-of-order

iperf Done.
Click to expand...

My connection is running just fine but I get the same "out of order" packets, although 0.27% isnt that much.. - MTN CPT

Code: 
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  7]   0.00-10.05  sec  95.9 MBytes  80.0 Mbits/sec  0.000 ms  0/72099 (0%)  sender
[SUM]  0.0-10.1 sec  3897 datagrams received out-of-order
[  7]   0.00-10.00  sec  95.0 MBytes  79.7 Mbits/sec  0.198 ms  194/71359 (0.27%)  receiver

iperf Done.
 
PBCool said:
It doesn't matter if it's cached or not really, Google manages their own transit for content so if it isn't cached it uses their capacity to deliver it to its local peer. Did you try run a trace to the source at all?
Click to expand...
I have a question for you, at what point did every customer here sign up to be a beta tester?

There are so many of us who have complained about international speeds, giving iperf, tracer, ping tests etc. And yet nothing changed. At what point did we go from customer who showed they had a problem, hoping for a quick fix, to beta testers of an ISP network as we seem to have to keep providing tests with no improvement for months, with us being the ones having to run after your support for follow up?

Router arrived yesterday, I'll set it up tomorrow. Doubt it will make a difference though, since I have you performance tests while being directly connected to the ONT which showed bad throughput as well.
 
This is Octotel's Southern Suburbs FB page:
https://www.facebook.com/groups/1110500752416804/

I think the major issue here is that complaints aren't public - they're going to CISP, who are banging their heads against Octotel's wall. Perhaps if everyone having issues in this area starts making a fuss on a public forum, like their FB page or Twitter, we may get some attention?
 
Should take a poll of people who are experiencing connectivity problems on CISP as to what provider they are on.. seems like it's just Octotel with a touch of Vuma.
 
Seeyou said:
This is Octotel's Southern Suburbs FB page:
https://www.facebook.com/groups/1110500752416804/

I think the major issue here is that complaints aren't public - they're going to CISP, who are banging their heads against Octotel's wall. Perhaps if everyone having issues in this area starts making a fuss on a public forum, like their FB page or Twitter, we may get some attention?
Click to expand...

I've been posting for ages...hasn't got me anywhere...
 
image132 said:
Maybe we should all start registering our interest with vumatel?
Click to expand...

Octotel and Vumatel seem to have an almost scientifically precise mutual exclusion zone on their coverage maps. If one has already rolled out in an area, the other avoids it. I doubt they'd see the profit in rolling out in an area where Octotel or Openserve already have a large footprint. Bad press however..
 
blunt said:
My connection is running just fine but I get the same "out of order" packets, although 0.27% isnt that much.. - MTN CPT

Code: 
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  7]   0.00-10.05  sec  95.9 MBytes  80.0 Mbits/sec  0.000 ms  0/72099 (0%)  sender
[SUM]  0.0-10.1 sec  3897 datagrams received out-of-order
[  7]   0.00-10.00  sec  95.0 MBytes  79.7 Mbits/sec  0.198 ms  194/71359 (0.27%)  receiver

iperf Done.
Click to expand...
drop to 70
 
MDE said:
Only if they promise to do trenched, none of this GPON ****...
Click to expand...

I'd take anything over Octotel right now. I'd even take TTconnect.

Seeyou said:
Octotel and Vumatel seem to have an almost scientifically precise mutual exclusion zone on their coverage maps. If one has already rolled out in an area, the other avoids it. I doubt they'd see the profit in rolling out in an area where Octotel or Openserve already have a large footprint. Bad press however..
Click to expand...

I agree with you its unlikely but I don't know what else to do at this point. CISP seem to be avoiding the issue here too so I guess I'll just try to live with 60% packet loss in the evenings.
 
  • Like
Reactions: MDE
image132 said:
I'd take anything over Octotel right now. I'd even take TTconnect.



I agree with you its unlikely but I don't know what else to do at this point. CISP seem to be avoiding the issue here too so I guess I'll just try to live with 60% packet loss in the evenings.
Click to expand...
wireless?
 
image132 said:
No.

Wireless is the same, towers get congested in the evenings, you get packet loss and throughput dies and then you have the joy of paying out your a** for 20gb of data.
Click to expand...
yes but there are multiple providers and networks, just setup is expensive.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X