Web Squad ISP

Status
Not open for further replies.
websquadza said:
First result shows a few packet fragments coming in out of order (I'm guessing you used a fixed packet size? -l? Second shows a test that lets iperf calculate the packet size, and no datagrams out of order. 1.8% at 200M seems right considering packet header at 200M and our speed limiter kicking in.
Click to expand...
Sorry I redid it at -l 1452 -b 200M getting 2% loss.

Same RD 20GB file is running at 2MB which would point to congestion, sigh.

Well done Vumatel, your network isn't a month old yet and it's broken already.
 
-l 1500 -b 200M

[ 4] 8.00-9.00 sec 21.2 MBytes 178 Mbits/sec 0.090 ms 2054/16668 (12%)

[ 4] 9.00-10.00 sec 21.6 MBytes 181 Mbits/sec 0.047 ms 1549/16665 (9.3%
)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 247 MBytes 207 Mbits/sec 0.106 ms 17118/169509 (10
%)
[ 4] Sent 169509 datagrams
[SUM] 0.0-10.0 sec 402 datagrams received out-of-order
CPU Utilization: local/receiver 29.5% (8.5%u/21.0%s), remote/sender 1.6% (0.2%u/
1.4%s)

iperf Done.
 
wingnut771 said:
-l 1500 -b 200M

[ 4] 8.00-9.00 sec 21.2 MBytes 178 Mbits/sec 0.090 ms 2054/16668 (12%)

[ 4] 9.00-10.00 sec 21.6 MBytes 181 Mbits/sec 0.047 ms 1549/16665 (9.3%
)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag
rams
[ 4] 0.00-10.00 sec 247 MBytes 207 Mbits/sec 0.106 ms 17118/169509 (10
%)
[ 4] Sent 169509 datagrams
[SUM] 0.0-10.0 sec 402 datagrams received out-of-order
CPU Utilization: local/receiver 29.5% (8.5%u/21.0%s), remote/sender 1.6% (0.2%u/
1.4%s)

iperf Done.
Click to expand...

Run -l 1400 and 180M
 
wingnut771 said:
Yesterday I did -b 400M with 25% loss, now it's 50.
Click to expand...

You're going to see losses at anything over 200M because of the speed limitation of 200M International on the service. That's why you need to run Iperf at less than 200 to allow for header.
 
What is the correct block size to use? Isn't it the maximum packet size which is 1500?
 
wingnut771 said:
Seems to have cleared.

So 5-6pm is peak in my area.
Click to expand...

Will enquire with Vumatel if they're seeing congestion between your POP and Teraco. Will get a reply of no (as always), but will let them know we're seeing it - usually speeds up upgrades.
 
websquadza said:
Will enquire with Vumatel if they're seeing congestion between your POP and Teraco. Will get a reply of no (as always), but will let them know we're seeing it - usually speeds up upgrades.
Click to expand...
I haven't really been keeping an eye on it and being scientific, but will start monitoring.

At least I know what normal looks like.
 
wingnut771 said:
What is the correct block size to use? Isn't it the maximum packet size which is 1500?
Click to expand...

Not from your PC, you have to account for your LAN headers - usually you get 1472 odd at your PC. You can calculate this using ping -l 14xx -f 8.8.8.8 - the -l flag specifies packet size and -f forces no fragmenting. That's why tests are usually run at 1400 to eliminate any possible issues across all networks (packet size won't affect your speed), or without the -l tag as iperf will report the correct MTU at your pc to the server (unless you're @sand_man). 1500 is the Frame on your public IP.
 
websquadza said:
Not from your PC, you have to account for your LAN headers - usually you get 1472 odd at your PC. You can calculate this using ping -l 14xx -f 8.8.8.8 - the -l flag specifies packet size and -f forces no fragmenting. That's why tests are usually run at 1400 to eliminate any possible issues across all networks (packet size won't affect your speed), or without the -l tag as iperf will report the correct MTU at your pc to the server (unless you're @sand_man). 1500 is the Frame on your public IP.
Click to expand...

If I understand that correctly, @sand_man won't see an improvement if the MTU setting is changed in the ONT, as it's just an iperf error as it's reporting wrong mtu so if he uses -l then it's ok = test passed.

@sand_man do -l 1400 -b 180M
 
I can see it now, RD throttles to 100mb/s on continuous downloads at certain times like now.

I'm ok with that as long as I know what it is and how it works.
 
ipv6_warrior said:
Just wondering if you managed to solve it? I know it can get complex especially with small prefixes so if I should be checking to another IP let me know.
Click to expand...

Still trying to understand what Amazon is doing here. speedtest.jhb and speedtest.cpt are both exactly 171ms from a server hosted in EU. So not routing via JHB for CPT. But would also expect a small reduction in latency to CPT from EU.

Will keep you posted.
 
wingnut771 said:
If I understand that correctly, @sand_man won't see an improvement if the MTU setting is changed in the ONT, as it's just an iperf error as it's reporting wrong mtu so if he uses -l then it's ok = test passed.

@sand_man do -l 1400 -b 180M
Click to expand...

Microsoft Windows [Version 10.0.17763.379]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>iperf3.exe -R -u -b 180M -l 1400 -p 17001 -c queen.cisp.co.za
warning: Ignoring nonsense TCP MSS 0
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
[ 5] local 192.168.1.147 port 57977 connected to 62.233.65.195 port 17001
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 21.5 MBytes 181 Mbits/sec 0.039 ms 567/16689 (3.4%)
[ 5] 1.00-2.00 sec 21.4 MBytes 180 Mbits/sec 0.022 ms 18/16071 (0.11%)
[ 5] 2.00-3.00 sec 21.5 MBytes 180 Mbits/sec 0.024 ms 0/16074 (0%)
[ 5] 3.00-4.00 sec 21.5 MBytes 180 Mbits/sec 0.032 ms 0/16069 (0%)
[ 5] 4.00-5.00 sec 21.5 MBytes 180 Mbits/sec 0.019 ms 0/16071 (0%)
[ 5] 5.00-6.00 sec 21.5 MBytes 180 Mbits/sec 0.031 ms 0/16073 (0%)
[ 5] 6.00-7.00 sec 21.5 MBytes 180 Mbits/sec 0.031 ms 0/16072 (0%)
[ 5] 7.00-8.00 sec 21.5 MBytes 180 Mbits/sec 0.031 ms 0/16070 (0%)
[ 5] 8.00-9.00 sec 21.5 MBytes 180 Mbits/sec 0.028 ms 0/16072 (0%)
[ 5] 9.00-10.00 sec 21.5 MBytes 180 Mbits/sec 0.032 ms 0/16071 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.20 sec 219 MBytes 180 Mbits/sec 0.000 ms 0/163935 (0%) sender
[SUM] 0.0-10.2 sec 22 datagrams received out-of-order
[ 5] 0.00-10.00 sec 215 MBytes 180 Mbits/sec 0.032 ms 585/161332 (0.36%) receiver

iperf Done.

C:\WINDOWS\system32>
 
wingnut771 said:
If I understand that correctly, @sand_man won't see an improvement if the MTU setting is changed in the ONT, as it's just an iperf error as it's reporting wrong mtu so if he uses -l then it's ok = test passed.

@sand_man do -l 1400 -b 180M
Click to expand...
I take that back, he would see a difference because his ONT is advertising the wrong MTU setting, causing problems with other services the same way it makes iperf fail.
 
Status
Not open for further replies.
Back
Top
Sign up to the MyBroadband newsletter
X