SeaSickMama
Expert Member
Yeah this LoadShedding is probably the biggest nightmare all the telco networks could have
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: Will you be subscribing to the new Disney+ R49 streaming package?
Cool Ideas Fibre ISP - Feedback
- Thread starter paulosouthafrica
- Start date
- Status
detritus
Senior Member
My fibre came back on around 9:30pm, router managed to get some ntp traffic and set it's internal clock. My wifi only tablet shows some notifications from 11 to 12pm.
This morning though, everything is offline again.
This morning though, everything is offline again.
DuckKnuckle
Expert Member
Vumatel trenched in Brackenfell down again
Praeses
Executive Member
@TheRoDent
It's like the more times I run the iperf, the worse the results become?
It's like the more times I run the iperf, the worse the results become?
Code:
D:\Temp>iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M -l 1400 --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-10.0 Praeses 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Tue, 12 Feb 2019 05:06:47 GMT
Connecting to host trcvmh01.cisp.co.za, port 17001
Reverse mode, remote host trcvmh01.cisp.co.za is sending
Cookie: Praeses.1549948007.176475.5ecf74bf56
[ 4] local 192.168.0.2 port 62313 connected to 154.0.15.181 port 17001
Starting Test: protocol: UDP, 1 streams, 1400 byte blocks, omitting 2 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.24 MBytes 10.4 Mbits/sec 0.164 ms 0/927 (0%) (omitted)
[ 4] 1.00-1.00 sec 1.19 MBytes 5.00 Mbits/sec 0.173 ms 0/1787 (0%)
[ 4] 1.00-2.00 sec 1.19 MBytes 9.99 Mbits/sec 0.260 ms 0/892 (0%)
[ 4] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 0.146 ms 0/894 (0%)
[ 4] 3.00-4.00 sec 1.19 MBytes 10.0 Mbits/sec 0.153 ms 0/893 (0%)
[ 4] 4.00-5.00 sec 1.19 MBytes 9.99 Mbits/sec 0.168 ms 0/893 (0%)
[ 4] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 0.166 ms 0/893 (0%)
[ 4] 6.00-7.00 sec 1.19 MBytes 9.99 Mbits/sec 0.156 ms 0/892 (0%)
[ 4] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 0.192 ms 0/893 (0%)
[ 4] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 0.200 ms 0/893 (0%)
[ 4] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 0.398 ms 0/893 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 0.221 ms 0/8949 (0%)
[ 4] Sent 8949 datagrams
CPU Utilization: local/receiver 2.8% (0.9%u/1.9%s), remote/sender 0.0% (0.0%u/0.0%s)
iperf Done.
D:\Temp>iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M -l 1400 --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-10.0 Praeses 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Tue, 12 Feb 2019 05:07:02 GMT
Connecting to host trcvmh01.cisp.co.za, port 17001
Reverse mode, remote host trcvmh01.cisp.co.za is sending
Cookie: Praeses.1549948022.288126.2e84be1139
[ 4] local 192.168.0.2 port 63438 connected to 154.0.15.181 port 17001
Starting Test: protocol: UDP, 1 streams, 1400 byte blocks, omitting 2 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.24 MBytes 10.4 Mbits/sec 0.203 ms 0/928 (0%) (omitted)
[ 4] 1.00-1.00 sec 1.19 MBytes 5.00 Mbits/sec 0.142 ms 0/1787 (0%)
[ 4] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 0.150 ms 0/893 (0%)
[ 4] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 0.179 ms 0/893 (0%)
[ 4] 3.00-4.00 sec 1.19 MBytes 9.98 Mbits/sec 0.179 ms 0/892 (0%)
[ 4] 4.00-5.00 sec 1.14 MBytes 9.55 Mbits/sec 0.189 ms 41/893 (4.6%)
[ 4] 5.00-6.00 sec 1.19 MBytes 9.99 Mbits/sec 0.189 ms 0/892 (0%)
[ 4] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 0.235 ms 0/893 (0%)
[ 4] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 0.304 ms 0/894 (0%)
[ 4] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 0.375 ms 0/893 (0%)
[ 4] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 0.512 ms 0/892 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 0.254 ms 41/8949 (0.46%)
[ 4] Sent 8949 datagrams
CPU Utilization: local/receiver 3.2% (1.4%u/1.8%s), remote/sender 1.6% (0.2%u/1.4%s)
iperf Done.
D:\Temp>iperf3 --verbose --port 17001 -c trcvmh01.cisp.co.za --bandwidth 10M -l 1400 --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-10.0 Praeses 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Tue, 12 Feb 2019 05:07:18 GMT
Connecting to host trcvmh01.cisp.co.za, port 17001
Reverse mode, remote host trcvmh01.cisp.co.za is sending
Cookie: Praeses.1549948037.908801.68c0fe5733
[ 4] local 192.168.0.2 port 53504 connected to 154.0.15.181 port 17001
Starting Test: protocol: UDP, 1 streams, 1400 byte blocks, omitting 2 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 1.24 MBytes 10.4 Mbits/sec 0.170 ms 0/929 (0%) (omitted)
iperf3: OUT OF ORDER - incoming packet = 1198 and received packet = 1210 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1199 and received packet = 1210 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1200 and received packet = 1210 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1201 and received packet = 1210 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1202 and received packet = 1210 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1203 and received packet = 1211 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 1204 and received packet = 1211 AND SP = 4
[ 4] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 0.200 ms 7/893 (0.78%) (omitted)
[ 4] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 0.184 ms 0/893 (0%)
iperf3: OUT OF ORDER - incoming packet = 3304 and received packet = 3353 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3305 and received packet = 3353 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3306 and received packet = 3353 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3307 and received packet = 3353 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3308 and received packet = 3353 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3309 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3310 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3311 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3312 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3313 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3314 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3315 and received packet = 3354 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3316 and received packet = 3355 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3317 and received packet = 3355 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3318 and received packet = 3355 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3319 and received packet = 3355 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3320 and received packet = 3356 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3321 and received packet = 3356 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3322 and received packet = 3356 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3323 and received packet = 3356 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3324 and received packet = 3356 AND SP = 4
iperf3: OUT OF ORDER - incoming packet = 3325 and received packet = 3356 AND SP = 4
[ 4] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 0.186 ms 22/893 (2.5%)
[ 4] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 0.182 ms 0/893 (0%)
[ 4] 3.00-4.00 sec 1.19 MBytes 9.99 Mbits/sec 0.162 ms 0/892 (0%)
[ 4] 4.00-5.00 sec 1.19 MBytes 10.0 Mbits/sec 0.141 ms 0/893 (0%)
[ 4] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 0.133 ms 0/894 (0%)
[ 4] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 0.158 ms 0/892 (0%)
[ 4] 7.00-8.00 sec 1.19 MBytes 9.99 Mbits/sec 0.152 ms 0/892 (0%)
[ 4] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 0.140 ms 0/894 (0%)
[ 4] 9.00-10.00 sec 1.19 MBytes 10.0 Mbits/sec 0.144 ms 0/893 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 12.0 MBytes 10.1 Mbits/sec 0.160 ms 22/8949 (0.25%)
[ 4] Sent 8949 datagrams
[SUM] 0.0-10.0 sec 22 datagrams received out-of-order
CPU Utilization: local/receiver 4.0% (1.0%u/3.0%s), remote/sender 1.7% (0.2%u/1.5%s)
iperf Done.
Sukkafool
Well-Known Member
I’m in Parow north but everything is still off. Came on again during the course of last night but as of waking up this morning it’s all off. Friends in edgemead also offline still.
Vumatel trenched down in Tyger Valley area (Durbanville / Bellville). Looks like some seriously dodgy things happened overnight as well if I look at the smokeping graphs - 21 % packet loss to the first hop in the last 3 hours.
alwaysthankful
Well-Known Member
- Joined
- Oct 30, 2013
- Messages
- 411
- Reaction score
- 223
Stage 3 loadshedding at 8. So the cycle starts again.
eltherza
Expert Member
It did come back during the early hours of the morning (was working at 5am), seemed to have died some time after then.
DeatheCore
Senior Member
Yeah, vuma trenched completely offline here in Panorama too...
Tinuva
The Magician
I see the same issues to CISP during the night. Basically super heavy packet loss just after 2am, 4am and again at 7am.
However, interesting, the underlying Vumatel network is 100% fine at the same times.
Trace showing the different route for above:
Code:
~ % mtr shop.vumatel.co.za --report-wide --show-ips
Start: 2019-02-12T07:40:42+0200
HOST: turbot Loss% Snt Last Avg Best Wrst StDev
1.|-- router.lan (192.168.241.1) 0.0% 10 0.6 0.7 0.3 1.1 0.2
2.|-- 155.93.246.1 0.0% 10 18.1 32.1 18.1 71.1 14.4
3.|-- 203.0.113.5 0.0% 10 29.4 28.6 24.0 49.0 7.7
4.|-- vumaweb-joburg.venturanext.se (41.193.178.54) 0.0% 10 22.7 22.9 22.2 23.3 0.4
I see you're doing test on 10mb bandwidth. Not sure what your linespeed is but CISP has indicated previously you should run it at 80% of line speed. That will affect your stats.
Praeses
Executive Member
I'm running it at 10M as that's what @TheRoDent said I should test it at. I did test it at 18M though and it gave only slightly worse results, but probably not statistically significant as I didn't run it enough times.
eltherza
Expert Member
Looks like back on here
bHOLDher
Well-Known Member
Log a ticket with Cool Ideas, asking that they ask Vumatel to check the UPS hardware in your area, we had the same issue in our area last year some time, and Vumatel fixed it.
TheRoDent
Cool Ideas Rep
Some loss is to be expected now and again. These results actually look pretty decent.
TheRoDent
Cool Ideas Rep
That is interesting. 155.93.248.1 and 155.93.252.1 are our IP's deployed on Vumatel switches/routers, so that's still within their network.
The fact that end destination pings are fine, leads me to believe that there might be some ICMP rate limiting happening at times. Many devices do this to avoid CPU overload by people pinging things to death.
Saw a post somewhere on how the number of new connections coming back online affects causes a bottleneck in the system, but maybe the solution is to connect a UPS to your routers so you don't go offline? My brother and I have done this and we happily surf the internet during load shedding from our phones/tablets, and since your connection never goes down you don't have to deal with getting back onto the network.
Tinuva
The Magician
When it happened at 7am it affected more than just ICMP. I suspect something really happened more than just rate limiting on ICMP.
The good news is, doesn't look like it happened again, so all good for now.
- Status