Web Squad ISP

[sand_man]

@sand_man

Run this and send result:

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

C:\WINDOWS\system32>iperf3.exe -R -u -b 160M --verbose -p 17001 -c queen.cisp.co.za
iperf 3.6
CYGWIN_NT-10.0 Brentsw3PC 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
warning: Ignoring nonsense TCP MSS -2146493952
Control connection MSS 0
Setting UDP block size to 1460
Time: Tue, 05 Mar 2019 16:20:06 GMT
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
Cookie: n7ea5v6ushzakp6un3lkoohtsvt53orlrf3p
[ 5] local 10.10.10.246 port 61495 connected to 62.233.65.195 port 17001
Starting Test: protocol: UDP, 1 streams, 1460 byte blocks, omitting 0 seconds, 10 second test, tos 0
iperf3: error - control socket has closed unexpectedly

C:\WINDOWS\system32>iperf3.exe -R -u -b 160M --verbose -p 17001 -c queen.cisp.co.za
iperf 3.6
CYGWIN_NT-10.0 Brentsw3PC 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
warning: Ignoring nonsense TCP MSS -2146493952
Control connection MSS 0
Setting UDP block size to 1460
Time: Tue, 05 Mar 2019 16:20:10 GMT
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
Cookie: odwi2fhtnblzdbhusozxxz7epbw6sisk5fmt
[ 5] local 10.10.10.246 port 50058 connected to 62.233.65.195 port 17001
Starting Test: protocol: UDP, 1 streams, 1460 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 1.58 MBytes 13.3 Mbits/sec 0.120 ms 12913/14049 (92%)
[ 5] 1.00-2.00 sec 781 KBytes 6.41 Mbits/sec 0.095 ms 13149/13697 (96%)
[ 5] 2.00-3.00 sec 776 KBytes 6.35 Mbits/sec 0.098 ms 13156/13700 (96%)
[ 5] 3.00-4.00 sec 771 KBytes 6.32 Mbits/sec 0.119 ms 13158/13699 (96%)
[ 5] 4.00-5.00 sec 808 KBytes 6.62 Mbits/sec 0.124 ms 13263/13830 (96%)
[ 5] 5.00-6.00 sec 818 KBytes 6.71 Mbits/sec 0.096 ms 12997/13571 (96%)
[ 5] 6.00-7.00 sec 894 KBytes 7.32 Mbits/sec 0.108 ms 13072/13699 (95%)
[ 5] 7.00-8.00 sec 934 KBytes 7.65 Mbits/sec 0.101 ms 13170/13825 (95%)
[ 5] 8.00-9.00 sec 818 KBytes 6.71 Mbits/sec 0.091 ms 12993/13567 (96%)
[ 5] 9.00-10.00 sec 754 KBytes 6.18 Mbits/sec 0.117 ms 13169/13698 (96%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.20 sec 194 MBytes 160 Mbits/sec 0.000 ms 0/139678 (0%) sender
[SUM] 0.0-10.2 sec 3 datagrams received out-of-order
[ 5] 0.00-10.00 sec 8.76 MBytes 7.35 Mbits/sec 0.117 ms 131040/137335 (95%) receiver
CPU Utilization: local/receiver 3.1% (1.9%u/1.2%s), remote/sender 15.4% (2.0%u/13.3%s)

iperf Done.

C:\WINDOWS\system32>

 

[Mr Scratch]

1460 byte blocks

So you're already using well below 1500 MTU, please list your network configuration from your PC to the ONT, include any switch or router that may be in between.

 

[sand_man]

That 1492 MTU is what's worrying me. https://www.speedguide.net/analyzer.php and let me know what you're getting there.

PPPoE over Vuma is only capable of 1480 as the ethernet port is limited to 1500. If your computer believed this to be 1492, then that will have influenced your tests adversely as the server learns this from you.

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2019.03.05 11:27
IP address: 102.165.xxx.xxx
Client OS/browser: Windows 10 (Chrome 72.0.3626.121)

TCP options string: 020405a00103030801010402
MSS: 1440
MTU: 1480
TCP Window: 263424 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 1029
Recommended RWINs: 63360, 126720, 253440, 506880, 1013760
BDP limit (200ms): 10537kbps (1317KBytes/s)
BDP limit (500ms): 4215kbps (527KBytes/s)
MTU Discovery: ON
TTL: 52
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)

 

[websquadza]

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

C:\WINDOWS\system32>iperf3.exe -R -u -b 160M --verbose -p 17001 -c queen.cisp.co.za
iperf 3.6
CYGWIN_NT-10.0 Brentsw3PC 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
warning: Ignoring nonsense TCP MSS -2146493952
Control connection MSS 0
Setting UDP block size to 1460
Time: Tue, 05 Mar 2019 16:20:06 GMT
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
Cookie: n7ea5v6ushzakp6un3lkoohtsvt53orlrf3p
[ 5] local 10.10.10.246 port 61495 connected to 62.233.65.195 port 17001
Starting Test: protocol: UDP, 1 streams, 1460 byte blocks, omitting 0 seconds, 10 second test, tos 0
iperf3: error - control socket has closed unexpectedly

C:\WINDOWS\system32>iperf3.exe -R -u -b 160M --verbose -p 17001 -c queen.cisp.co.za
iperf 3.6
CYGWIN_NT-10.0 Brentsw3PC 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64
warning: Ignoring nonsense TCP MSS -2146493952
Control connection MSS 0
Setting UDP block size to 1460
Time: Tue, 05 Mar 2019 16:20:10 GMT
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
Cookie: odwi2fhtnblzdbhusozxxz7epbw6sisk5fmt
[ 5] local 10.10.10.246 port 50058 connected to 62.233.65.195 port 17001
Starting Test: protocol: UDP, 1 streams, 1460 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 1.58 MBytes 13.3 Mbits/sec 0.120 ms 12913/14049 (92%)
[ 5] 1.00-2.00 sec 781 KBytes 6.41 Mbits/sec 0.095 ms 13149/13697 (96%)
[ 5] 2.00-3.00 sec 776 KBytes 6.35 Mbits/sec 0.098 ms 13156/13700 (96%)
[ 5] 3.00-4.00 sec 771 KBytes 6.32 Mbits/sec 0.119 ms 13158/13699 (96%)
[ 5] 4.00-5.00 sec 808 KBytes 6.62 Mbits/sec 0.124 ms 13263/13830 (96%)
[ 5] 5.00-6.00 sec 818 KBytes 6.71 Mbits/sec 0.096 ms 12997/13571 (96%)
[ 5] 6.00-7.00 sec 894 KBytes 7.32 Mbits/sec 0.108 ms 13072/13699 (95%)
[ 5] 7.00-8.00 sec 934 KBytes 7.65 Mbits/sec 0.101 ms 13170/13825 (95%)
[ 5] 8.00-9.00 sec 818 KBytes 6.71 Mbits/sec 0.091 ms 12993/13567 (96%)
[ 5] 9.00-10.00 sec 754 KBytes 6.18 Mbits/sec 0.117 ms 13169/13698 (96%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.20 sec 194 MBytes 160 Mbits/sec 0.000 ms 0/139678 (0%) sender
[SUM] 0.0-10.2 sec 3 datagrams received out-of-order
[ 5] 0.00-10.00 sec 8.76 MBytes 7.35 Mbits/sec 0.117 ms 131040/137335 (95%) receiver
CPU Utilization: local/receiver 3.1% (1.9%u/1.2%s), remote/sender 15.4% (2.0%u/13.3%s)

iperf Done.

C:\WINDOWS\system32>

Is this MTU set at 1480 or lower?

Let's see what MTU you can actually get:

ping -f -l xxxx 8.8.8.8
where xxxx is an MTU between 1400 and 1480 (test in 10 byte increments)

-f flag forces no fragement
-l flag specifies packet size

 

[Mr Scratch]

Is this MTU set at 1480 or lower?

Let's see what MTU you can actually get:

ping -f -l xxxx 8.8.8.8
where xxxx is an MTU between 1400 and 1480 (test in 10 byte increments)

-f flag forces no fragement
-l flag specifies packet size

I'd wager 1472

 

[sand_man]

So you're already using well below 1500 MTU, please list your network configuration from your PC to the ONT, include any switch or router that may be in between.

Well, currently I have Home-connect monitoring the line so ONT connected to Mikrotik CCR 1016 via Cat 6 ethernet cable, then I got cat6 connecting TPLINK C5400 router to the Mikrotik (ethernet port 1) and pc connected to the TPLINK via cat6 (ethernet port 2).

DHCP set to off on the TPLINK, TPLINK currently running as a wireless access point.

 

[sand_man]

Is this MTU set at 1480 or lower?

Let's see what MTU you can actually get:

ping -f -l xxxx 8.8.8.8
where xxxx is an MTU between 1400 and 1480 (test in 10 byte increments)

-f flag forces no fragement
-l flag specifies packet size

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

C:\WINDOWS\system32>ping -f -l 1400 8.8.8.8

Pinging 8.8.8.8 with 1400 bytes of data:
Reply from 8.8.8.8: bytes=1400 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1400 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1400 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1400 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\WINDOWS\system32>ping -f -l 1420 8.8.8.8

Pinging 8.8.8.8 with 1420 bytes of data:
Reply from 8.8.8.8: bytes=1420 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1420 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1420 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1420 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\WINDOWS\system32>ping -f -l 1430 8.8.8.8

Pinging 8.8.8.8 with 1430 bytes of data:
Reply from 8.8.8.8: bytes=1430 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1430 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1430 time=2ms TTL=122
Reply from 8.8.8.8: bytes=1430 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms

C:\WINDOWS\system32>ping -f -l 1440 8.8.8.8

Pinging 8.8.8.8 with 1440 bytes of data:
Reply from 8.8.8.8: bytes=1440 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1440 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1440 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1440 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\WINDOWS\system32>ping -f -l 1450 8.8.8.8

Pinging 8.8.8.8 with 1450 bytes of data:
Reply from 8.8.8.8: bytes=1450 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1450 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1450 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1450 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms

C:\WINDOWS\system32>ping -f -l 1460 8.8.8.8

Pinging 8.8.8.8 with 1460 bytes of data:
Reply from 10.10.10.1: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

C:\WINDOWS\system32>ping -f -l 1470 8.8.8.8

Pinging 8.8.8.8 with 1470 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\WINDOWS\system32>

 

[Mr Scratch]

@sand_man in CMD type

netsh interface ipv4 show subinterface

 

[sand_man]

I'd wager 1472

Seems to be 1452...

Pinging 8.8.8.8 with 1452 bytes of data:
Reply from 8.8.8.8: bytes=1452 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1452 time=2ms TTL=122
Reply from 8.8.8.8: bytes=1452 time=1ms TTL=122
Reply from 8.8.8.8: bytes=1452 time=1ms TTL=122

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms


C:\WINDOWS\system32>ping -f -l 1453 8.8.8.8

Pinging 8.8.8.8 with 1453 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

 

[sand_man]

@sand_man in CMD type

C:\WINDOWS\system32>netsh interface ipv4 show subinterface

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 105150 Loopback Pseudo-Interface 1
1500 1 9259278244 275827484 Ethernet

 

[Mr Scratch]

C:\WINDOWS\system32>netsh interface ipv4 show subinterface

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 105150 Loopback Pseudo-Interface 1
1500 1 9259278244 275827484 Ethernet

Okay so you can now rule out iperf and your computer. So I think you're right in thinking its the ONT...

 

[sand_man]

Okay so you can now rule out iperf and your computer. So I think you're right in thinking its the ONT...

So MTU setting on ONT set to 1452? Or am I completely misinterpreting the data?

 

[sand_man]

Thanks for the help @websquadza and @Waylander

You teaching me some new tricks tonight... This also goes a long way to explaining my iperf anomaly. Very grateful!!

 

[websquadza]

So MTU setting on ONT set to 1452?

There's a bit of packet header overhead here. I'd say set your PPPoE session to 1460 and see if that helps?

 

[sand_man]

There's a bit of packet header overhead here. I'd say set your PPPoE session to 1460 and see if that helps?

Where? My router? TPlink? Doesn't whatever I input into the TPlink get superseded by what's set on the ONT?

 

[websquadza]

Where? My router? TPlink? Doesn't whatever I input into the TPlink get superseded by what's set on the ONT?

Yup, on your router. Servers interact with your IP (set on your router), which is where the MTU is important. If you're forcing larger packets through the upstream interface (ONT), the ONT will start fragmenting them. That's why when an ONT has a standard 1500, PPPoE defaults to 1480. Now that your ONT seems to have a lower MTU on the Ethernet port, forcing a lower MTU on PPPoE should reduce the fragmentation you're picking up. Servers you connect to will learn the lower 1460 MTU and send you data based 1460 Byte packet sizes.

 

[sand_man]

I get it, kind of....

Right now I cannot access my router settings on account of the Mikrotik CCR. IN effect the Mikrotik is my router and I don't have access to the UI.

 

[SFW007]

any promo codes

 

[Sopbeen]

By the way @websquadza - In another... 50 or so months, you owe me a chappie bro. All them 1 cents count up....

 

[ipv6_warrior]

@websquadza do you have any transit going over WACS or any other of the west coast cables or does all traffic from CPT transit through JHB and east coast?
Any plans on peering with Amazon in CPT?

Basically trying to understand what latency to Europe/US I would be looking at if I switch over from CISP.