Cool Ideas Fibre ISP - Feedback

[Praeses]

Unfortunately this is here to stay until they get their tarriff increase or more bailout from the SA taxpayer. This is embargo in the purest form, the vile, despicable strong-arm tactics the ANC loves using on its people.

I just hope the unbundling will allow for private producers to start up and then only rent the parts it needs from Eskom to get the power to its clients.

 

[alwaysthankful]

Well done, and great job to proving the Fibre providers to be the fault (as we suspected). I pretty much maintained the problem was never with CISP
Unfortunately it won't help me, as what is done is done, its just a sad situation to be in but such is life.

Unfortunately this is here to stay until they get their tarriff increase or more bailout from the SA taxpayer. This is embargo in the purest form, the vile, despicable strong-arm tactics the ANC loves using on its people.

Sometimes it is best to say nothing at all. If I have to express my thoughts about this government in words....

 

[ryanrich]

Damn I love fibre! Had to upload some large files to Dropbox this morning. Downloading a torrent at 3MB/sec and uploading to DB at 6MB/sec simultaneously. My biggest pain with ADSL was the horrendous upload speeds.

 

[Hype]

Damn I love fibre! Had to upload some large files to Dropbox this morning. Downloading a torrent at 3MB/sec and uploading to DB at 6MB/sec simultaneously. My biggest pain with ADSL was the horrendous upload speeds.

One of the big draw cards for us. We upload artwork to printers and that used to take 4-5 hours on the DSL line where its a matter of 2-5 minutes at worst case.

 

[ArtyLoop]

Damn I love fibre! Had to upload some large files to Dropbox this morning. Downloading a torrent at 3MB/sec and uploading to DB at 6MB/sec simultaneously. My biggest pain with ADSL was the horrendous upload speeds.

Lucky you... for Octotel clients that will likely never be the case

 

[Hype]

I was wondering the same. On my 20Mbps line with a 18Mbps iperf I get 50% loss...

This is my iperf

200/200 Vumatel trenched JHB

C:\Users\iperf-3.1.3-win64>iperf3.exe -u -b 200M -p 17001 -c queen.cisp.co.za
Connecting to host queen.cisp.co.za, port 17001
[ 4] local 192.168.0.48 port 49323 connected to 62.233.65.195 port 17001
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 22.6 MBytes 190 Mbits/sec 2899
[ 4] 1.00-2.00 sec 23.2 MBytes 195 Mbits/sec 2976
[ 4] 2.00-3.00 sec 25.0 MBytes 209 Mbits/sec 3195
[ 4] 3.00-4.00 sec 22.5 MBytes 189 Mbits/sec 2885
[ 4] 4.00-5.01 sec 25.2 MBytes 211 Mbits/sec 3225
[ 4] 5.01-6.01 sec 22.4 MBytes 187 Mbits/sec 2865
[ 4] 6.01-7.00 sec 24.6 MBytes 208 Mbits/sec 3144
[ 4] 7.00-8.00 sec 24.6 MBytes 207 Mbits/sec 3152
[ 4] 8.00-9.00 sec 23.0 MBytes 193 Mbits/sec 2943
[ 4] 9.00-10.00 sec 24.1 MBytes 201 Mbits/sec 3082
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 237 MBytes 199 Mbits/sec 0.030 ms 2/30365 (0.0066%)
[ 4] Sent 30365 datagrams

iperf Done.

 

[image132]

Wow, absolutely shocking to say the least ! Now that's some next level troubleshooting right there. Hats off to you guys for going the extra mile. Here's hoping more struggling CISP users will partake in identifying areas on poor performing FLP's.

I think I found out why I can't watch twitch in the evenings

I was wondering the same. On my 20Mbps line with a 18Mbps iperf I get 50% loss...

I think therodent is trying not to utilize my entire line when he runs those tests so he brings the value down. I can tell you that if I run a normal iperf test at 80mb during the evenings 2-5% packet loss is normal.

Here, this one is from the 9th:

Connecting to host iperf.cisp.co.za, port 17001
Reverse mode, remote host iperf.cisp.co.za is sending
[ 4] local 192.168.1.247 port 51268 connected to 172.104.157.197 port 17001
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 9.63 MBytes 80.8 Mbits/sec 0.233 ms 43/1276 (3.4%)
[ 4] 1.00-2.00 sec 9.41 MBytes 78.9 Mbits/sec 0.189 ms 16/1221 (1.3%)
iperf3: OUT OF ORDER - incoming packet = 3373 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3374 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3375 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3376 and received packet = 3385 AND SP = 4
[ 4] 2.00-3.00 sec 9.37 MBytes 78.6 Mbits/sec 0.254 ms 25/1220 (2%)
[ 4] 3.00-4.00 sec 9.24 MBytes 77.6 Mbits/sec 0.132 ms 38/1221 (3.1%)
[ 4] 4.00-5.00 sec 9.38 MBytes 78.7 Mbits/sec 0.197 ms 20/1221 (1.6%)
iperf3: OUT OF ORDER - incoming packet = 6425 and received packet = 6436 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6426 and received packet = 6436 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6427 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6428 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6429 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6430 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7035 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7036 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7037 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7038 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7039 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7040 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7041 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7042 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7043 and received packet = 7048 AND SP = 4
[ 4] 5.00-6.00 sec 9.34 MBytes 78.4 Mbits/sec 0.198 ms 40/1221 (3.3%)
[ 4] 6.00-7.00 sec 9.43 MBytes 79.1 Mbits/sec 0.197 ms 12/1219 (0.98%)
[ 4] 7.00-8.00 sec 9.34 MBytes 78.3 Mbits/sec 0.206 ms 27/1222 (2.2%)
[ 4] 8.00-9.00 sec 9.44 MBytes 79.2 Mbits/sec 0.216 ms 11/1219 (0.9%)
[ 4] 9.00-10.00 sec 9.43 MBytes 79.0 Mbits/sec 0.184 ms 15/1222 (1.2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 97.3 MBytes 81.6 Mbits/sec 0.190 ms 247/12451 (2%)
[ 4] Sent 12451 datagrams
[SUM] 0.0-10.0 sec 19 datagrams received out-of-order

iperf Done.

I'm just so happy I have some validation and that a solution might be on the horizon.

 

[TranQ]

This is my iperf

200/200 Vumatel trenched JHB

C:\Users\iperf-3.1.3-win64>iperf3.exe -u -b 200M -p 17001 -c queen.cisp.co.za
Connecting to host queen.cisp.co.za, port 17001
[ 4] local 192.168.0.48 port 49323 connected to 62.233.65.195 port 17001
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 22.6 MBytes 190 Mbits/sec 2899
[ 4] 1.00-2.00 sec 23.2 MBytes 195 Mbits/sec 2976
[ 4] 2.00-3.00 sec 25.0 MBytes 209 Mbits/sec 3195
[ 4] 3.00-4.00 sec 22.5 MBytes 189 Mbits/sec 2885
[ 4] 4.00-5.01 sec 25.2 MBytes 211 Mbits/sec 3225
[ 4] 5.01-6.01 sec 22.4 MBytes 187 Mbits/sec 2865
[ 4] 6.01-7.00 sec 24.6 MBytes 208 Mbits/sec 3144
[ 4] 7.00-8.00 sec 24.6 MBytes 207 Mbits/sec 3152
[ 4] 8.00-9.00 sec 23.0 MBytes 193 Mbits/sec 2943
[ 4] 9.00-10.00 sec 24.1 MBytes 201 Mbits/sec 3082
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 237 MBytes 199 Mbits/sec 0.030 ms 2/30365 (0.0066%)
[ 4] Sent 30365 datagrams

iperf Done.

I can only dream of this! With international is basically dead as a result of packet loss and I'm getting less than half of my line speed on domestic traffic. It sucks but I can do absolutely nothing about it and it is the most frustrating feeling. So I'm just hoping that @PBCool and @TheRoDent is fighting a good fight on my behalf with Netstream.

I think I found out why I can't watch twitch in the evenings



I think therodent is trying not to utilize my entire line when he runs those tests so he brings the value down. I can tell you that if I run a normal iperf test at 80mb during the evenings 2-5% packet loss is normal.

Here, this one is from the 9th:

Connecting to host iperf.cisp.co.za, port 17001
Reverse mode, remote host iperf.cisp.co.za is sending
[ 4] local 192.168.1.247 port 51268 connected to 172.104.157.197 port 17001
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 9.63 MBytes 80.8 Mbits/sec 0.233 ms 43/1276 (3.4%)
[ 4] 1.00-2.00 sec 9.41 MBytes 78.9 Mbits/sec 0.189 ms 16/1221 (1.3%)
iperf3: OUT OF ORDER - incoming packet = 3373 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3374 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3375 and received packet = 3385 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3376 and received packet = 3385 AND SP = 4
[ 4] 2.00-3.00 sec 9.37 MBytes 78.6 Mbits/sec 0.254 ms 25/1220 (2%)
[ 4] 3.00-4.00 sec 9.24 MBytes 77.6 Mbits/sec 0.132 ms 38/1221 (3.1%)
[ 4] 4.00-5.00 sec 9.38 MBytes 78.7 Mbits/sec 0.197 ms 20/1221 (1.6%)
iperf3: OUT OF ORDER - incoming packet = 6425 and received packet = 6436 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6426 and received packet = 6436 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6427 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6428 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6429 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 6430 and received packet = 6437 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7035 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7036 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7037 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7038 and received packet = 7047 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7039 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7040 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7041 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7042 and received packet = 7048 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 7043 and received packet = 7048 AND SP = 4
[ 4] 5.00-6.00 sec 9.34 MBytes 78.4 Mbits/sec 0.198 ms 40/1221 (3.3%)
[ 4] 6.00-7.00 sec 9.43 MBytes 79.1 Mbits/sec 0.197 ms 12/1219 (0.98%)
[ 4] 7.00-8.00 sec 9.34 MBytes 78.3 Mbits/sec 0.206 ms 27/1222 (2.2%)
[ 4] 8.00-9.00 sec 9.44 MBytes 79.2 Mbits/sec 0.216 ms 11/1219 (0.9%)
[ 4] 9.00-10.00 sec 9.43 MBytes 79.0 Mbits/sec 0.184 ms 15/1222 (1.2%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 97.3 MBytes 81.6 Mbits/sec 0.190 ms 247/12451 (2%)
[ 4] Sent 12451 datagrams
[SUM] 0.0-10.0 sec 19 datagrams received out-of-order

iperf Done.

I'm just so happy I have some validation and a solution might be on the horizon.

Yeah I can imagine it must be a huge relief knowing that they are actively monitoring your line and doing the necessary tests to take it further. Hopefully it will be enough proof for them to fix whatever is the problem.

 

[teeceekay]

Unfortunately not.

Also getting timeouts and major packet loss on international and Google services this morning. Southern Suburbs, Cape Town, Octotel.

 

[Sabre]

I keep getting random disconnects on P2P (playing Destiny 2), I see someone else had similar issue on 2 Oct ... PBCOOL can you please help?

I've blocked the Google DNS 1.1.1.1 in order to use a US DNS service .. not sure if this will contribute?

 

[TheRoDent]

That's some appalling packet loss! Is there a specific reason that you ran the test using 30Mbps on a 100Mbps line? Is that to just give an underestimation of the network issue?

It's simply to make sure that the loss isn't due to line capacity. If one gets loss at a 30mbps rate on a 100mbps line then that indicates a network issue for sure.

 

[MDE]

It's simply to make sure that the loss isn't due to line capacity. If one gets loss at a 30mbps rate on a 100mbps line then that indicates a network issue for sure.

This is done on my 20mb line with Octotel, Claremont...


mde@xxx:~$ iperf3 -u -b 10M -p 17001 -c iperf.cisp.co.za
Connecting to host iperf.cisp.co.za, port 17001
[ 4] local 192.168.1.8 port 36086 connected to 172.104.157.197 port 17001
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 1.09 MBytes 9.11 Mbits/sec 139
[ 4] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 6.00-7.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 7.00-8.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 152
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 11.8 MBytes 9.91 Mbits/sec 18.426 ms 587/1503 (39%)
[ 4] Sent 1503 datagrams

iperf Done.

 

[Praeses]

It's simply to make sure that the loss isn't due to line capacity. If one gets loss at a 30mbps rate on a 100mbps line then that indicates a network issue for sure.

Thanks for the reply. Do you suspect that my low international single threaded speeds (and buffering twitch streaming) on Frogfoot can also be related to packet loss? I've posted some iperf results in ticket #COOL-20190103-194897 on 15 January if you want to check. Please consider me for one of your testing boxes in the future - I'll be more than happy to help out!

 

[TheRoDent]

This is done on my 20mb line with Octotel, Claremont...


mde@xxx:~$ iperf3 -u -b 10M -p 17001 -c iperf.cisp.co.za
Connecting to host iperf.cisp.co.za, port 17001
[ 4] local 192.168.1.8 port 36086 connected to 172.104.157.197 port 17001
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 1.09 MBytes 9.11 Mbits/sec 139
[ 4] 1.00-2.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 2.00-3.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 3.00-4.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 4.00-5.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 5.00-6.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 6.00-7.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 7.00-8.00 sec 1.19 MBytes 9.96 Mbits/sec 152
[ 4] 8.00-9.00 sec 1.20 MBytes 10.0 Mbits/sec 153
[ 4] 9.00-10.00 sec 1.19 MBytes 9.96 Mbits/sec 152
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 11.8 MBytes 9.91 Mbits/sec 18.426 ms 587/1503 (39%)
[ 4] Sent 1503 datagrams

iperf Done.

Thanks MDE, we have seen from the other stats that around 10am in the mornings is also a peak time.

 

[TheRoDent]

Thanks for the reply. Do you suspect that my low international single threaded speeds (and buffering twitch streaming) on Frogfoot can also be related to packet loss? I've posted some iperf results in ticket #COOL-20190103-194897 on 15 January if you want to check. Please consider me for one of your testing boxes in the future - I'll be more than happy to help out!

As soon as we receive additional probes I'll send one out to you.

In the meantime, can you send me the results of

"iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M --omit 2 -R -u "

 

[ryanrich]

As soon as we receive additional probes I'll send one out to you.

In the meantime, can you send me the results of

"iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M --omit 2 -R -u "

Here is mine for comparison, also on Frogfoot.

C:\Applications\iperf-3.1.3-win64>iperf3 --verbose --port 17001 -c trcvmh01.cisp
.co.za --bandwidth 10M --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-6.1 ********* 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Mon, 11 Feb 2019 08:59:28 GMT
Connecting to host trcvmh01.cisp.co.za, port 17001
Reverse mode, remote host trcvmh01.cisp.co.za is sending
      Cookie: *********
[  4] local 192.168.1.5 port 52390 connected to 154.0.15.181 port 17001
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 2 seconds, 1
0 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datag
rams
[  4]   0.00-1.00   sec  1.39 MBytes  11.7 Mbits/sec  0.219 ms  5/183 (2.7%)  (o
mitted)
[  4]   1.00-1.00   sec  1.19 MBytes  4.98 Mbits/sec  0.120 ms  0/305 (0%)
[  4]   1.00-2.00   sec  1.20 MBytes  10.0 Mbits/sec  0.030 ms  0/153 (0%)
[  4]   2.00-3.00   sec  1.20 MBytes  10.0 Mbits/sec  0.022 ms  0/153 (0%)
[  4]   3.00-4.00   sec  1.19 MBytes  9.96 Mbits/sec  0.014 ms  0/152 (0%)
[  4]   4.00-5.00   sec  1.20 MBytes  10.0 Mbits/sec  0.019 ms  0/153 (0%)
[  4]   5.00-6.00   sec  1.19 MBytes  9.96 Mbits/sec  0.027 ms  0/152 (0%)
[  4]   6.00-7.00   sec  1.20 MBytes  10.0 Mbits/sec  0.018 ms  0/153 (0%)
[  4]   7.00-8.00   sec  1.20 MBytes  10.0 Mbits/sec  0.014 ms  0/153 (0%)
[  4]   8.00-9.00   sec  1.19 MBytes  9.96 Mbits/sec  0.027 ms  0/152 (0%)
[  4]   9.00-10.00  sec  1.20 MBytes  10.0 Mbits/sec  0.019 ms  0/153 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datag
rams
[  4]   0.00-10.00  sec  12.2 MBytes  10.2 Mbits/sec  0.019 ms  0/1526 (0%)
[  4] Sent 1526 datagrams
CPU Utilization: local/receiver 2.0% (0.5%u/1.5%s), remote/sender 0.9% (0.1%u/0.
8%s)

iperf Done.

 

[TheRoDent]

Here is mine for comparison, also on Frogfoot.

C:\Applications\iperf-3.1.3-win64>iperf3 --verbose --port 17001 -c trcvmh01.cisp
.co.za --bandwidth 10M --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-6.1 ********* 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Mon, 11 Feb 2019 08:59:28 GMT
Connecting to host trcvmh01.cisp.co.za, port 17001
Reverse mode, remote host trcvmh01.cisp.co.za is sending
      Cookie: *********
[  4] local 192.168.1.5 port 52390 connected to 154.0.15.181 port 17001
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 2 seconds, 1
0 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datag
rams
[  4]   0.00-1.00   sec  1.39 MBytes  11.7 Mbits/sec  0.219 ms  5/183 (2.7%)  (o
mitted)
[  4]   1.00-1.00   sec  1.19 MBytes  4.98 Mbits/sec  0.120 ms  0/305 (0%)
[  4]   1.00-2.00   sec  1.20 MBytes  10.0 Mbits/sec  0.030 ms  0/153 (0%)
[  4]   2.00-3.00   sec  1.20 MBytes  10.0 Mbits/sec  0.022 ms  0/153 (0%)
[  4]   3.00-4.00   sec  1.19 MBytes  9.96 Mbits/sec  0.014 ms  0/152 (0%)
[  4]   4.00-5.00   sec  1.20 MBytes  10.0 Mbits/sec  0.019 ms  0/153 (0%)
[  4]   5.00-6.00   sec  1.19 MBytes  9.96 Mbits/sec  0.027 ms  0/152 (0%)
[  4]   6.00-7.00   sec  1.20 MBytes  10.0 Mbits/sec  0.018 ms  0/153 (0%)
[  4]   7.00-8.00   sec  1.20 MBytes  10.0 Mbits/sec  0.014 ms  0/153 (0%)
[  4]   8.00-9.00   sec  1.19 MBytes  9.96 Mbits/sec  0.027 ms  0/152 (0%)
[  4]   9.00-10.00  sec  1.20 MBytes  10.0 Mbits/sec  0.019 ms  0/153 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datag
rams
[  4]   0.00-10.00  sec  12.2 MBytes  10.2 Mbits/sec  0.019 ms  0/1526 (0%)
[  4] Sent 1526 datagrams
CPU Utilization: local/receiver 2.0% (0.5%u/1.5%s), remote/sender 0.9% (0.1%u/0.
8%s)

iperf Done.

That's a healthy fibre line right there.

 

[TheRoDent]

As soon as we receive additional probes I'll send one out to you.

In the meantime, can you send me the results of

"iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M -l 1400 --omit 2 -R -u "

Please add the -l 1400 parameter so we're sure we don't get too lengthy packets.

 

[ArtyLoop]

That's a healthy fibre line right there.

Nice, just a real tragedy not all of us can get a healthy fibre line. C'est la Vie!

 

[TheRoDent]

Nice, just a real tragedy not all of us can get a healthy fibre line. C'est la Vie!

Arty, I'm thinking of sending you the unit I used in Claremont, to install. Can you PM me your name, contact number and address details please.