WLAN External vs. Internal Speed Mystery
up vote
0
down vote
favorite
First and foremost I'm not a network engineer, I'm a software developer. But my general knowledge about networking is oooookay :)
My main problem currently is really understanding WLAN.
OK first the setup.
Modem: Icotera i6850
Broadband: Fiber optic, 300Mbit/sec down, 40Mbit/sec up.
WLAN AP: Ubiquiti Nano HD
PC WLAN Card: Asus AC68
Next the Raw Stats:
These stats are meassured with IPerf 3.1.3 between a Windows 10 PC and a MacBook running macOS.
Server: MacBook Pro (2018) connected via USB-C to Ethernet 1Gbit/sec
Client: Windows 10 x64 connected via ASUS AC68 WLAN Card
Server command: ./iperf3 -s -F ...zip *(the zip file is ~20GB in size)*
Client command: .iperf3.exe -c 192.... -t 1000 -M 1000
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-218.75 sec 9.21 GBytes 362 Mbits/sec sender
[ 4] 0.00-218.75 sec 0.00 Bytes 0.00 bits/sec receiver
WLAN Stats
- 2.4GHz deactivated
- 5GHz channel width = VHT160
- 5GHz channel = 36
- Transmit power = High
Utilization when using iperf is ~80 %. The PC is connected with about -59dBm signal strength
Okay now to my issue:
When issuing a speed test with speedtest.net, over WLAN I can only achieve ~240 Mbit/sec. When plugging in the cable I instantly run to 295Mbit/sec. I'm using Nessus (10G) as Server.
It even gets worse when like checking the download speed with Steam for example, I only achieve about ~150Mbit/sec.
A colleague of mine told me that this is because of the difference on the window scaling on TCP when comparing internal vs. external where the MTU can be 7000 or even higher internal and on external max 1500. But that is why I use the iperf parameter -M and set the MSS to 1000. Including the TCP header of 40 bytes that simulates an MTU of 1040, thus smaller than on external traffic.
Basically I wonder, I have some IPerf stats, that I'm not able to achieve anywhere in any real life application on my PC. Is the iperf benchmarking the wrong scenario for real life traffic or what is going on?
I have already tried disabling Nagle's Algorithm on Windows 10 with registry, but no changes.
Any advice is highly anticipated and I'm grateful if someone can simply explain me why this will not happen as wished.
wireless-networking wireless-access-point
edited Nov 16 at 16:43
Spiff
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
add a comment |
up vote
0
down vote
favorite
First and foremost I'm not a network engineer, I'm a software developer. But my general knowledge about networking is oooookay :)
My main problem currently is really understanding WLAN.
OK first the setup.
Modem: Icotera i6850
Broadband: Fiber optic, 300Mbit/sec down, 40Mbit/sec up.
WLAN AP: Ubiquiti Nano HD
PC WLAN Card: Asus AC68
Next the Raw Stats:
These stats are meassured with IPerf 3.1.3 between a Windows 10 PC and a MacBook running macOS.
Server: MacBook Pro (2018) connected via USB-C to Ethernet 1Gbit/sec
Client: Windows 10 x64 connected via ASUS AC68 WLAN Card
Server command: ./iperf3 -s -F ...zip *(the zip file is ~20GB in size)*
Client command: .iperf3.exe -c 192.... -t 1000 -M 1000
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-218.75 sec 9.21 GBytes 362 Mbits/sec sender
[ 4] 0.00-218.75 sec 0.00 Bytes 0.00 bits/sec receiver
WLAN Stats
- 2.4GHz deactivated
- 5GHz channel width = VHT160
- 5GHz channel = 36
- Transmit power = High
Utilization when using iperf is ~80 %. The PC is connected with about -59dBm signal strength
Okay now to my issue:
When issuing a speed test with speedtest.net, over WLAN I can only achieve ~240 Mbit/sec. When plugging in the cable I instantly run to 295Mbit/sec. I'm using Nessus (10G) as Server.
It even gets worse when like checking the download speed with Steam for example, I only achieve about ~150Mbit/sec.
A colleague of mine told me that this is because of the difference on the window scaling on TCP when comparing internal vs. external where the MTU can be 7000 or even higher internal and on external max 1500. But that is why I use the iperf parameter -M and set the MSS to 1000. Including the TCP header of 40 bytes that simulates an MTU of 1040, thus smaller than on external traffic.
Basically I wonder, I have some IPerf stats, that I'm not able to achieve anywhere in any real life application on my PC. Is the iperf benchmarking the wrong scenario for real life traffic or what is going on?
I have already tried disabling Nagle's Algorithm on Windows 10 with registry, but no changes.
Any advice is highly anticipated and I'm grateful if someone can simply explain me why this will not happen as wished.
wireless-networking wireless-access-point
edited Nov 16 at 16:43
Spiff
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
1
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with-win iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).
– Spiff
Nov 16 at 17:10
Also, what's up with the-Fyou're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify-R(reverse direction) on the client.
– Spiff
Nov 16 at 17:10
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
First and foremost I'm not a network engineer, I'm a software developer. But my general knowledge about networking is oooookay :)
My main problem currently is really understanding WLAN.
OK first the setup.
Modem: Icotera i6850
Broadband: Fiber optic, 300Mbit/sec down, 40Mbit/sec up.
WLAN AP: Ubiquiti Nano HD
PC WLAN Card: Asus AC68
Next the Raw Stats:
These stats are meassured with IPerf 3.1.3 between a Windows 10 PC and a MacBook running macOS.
Server: MacBook Pro (2018) connected via USB-C to Ethernet 1Gbit/sec
Client: Windows 10 x64 connected via ASUS AC68 WLAN Card
Server command: ./iperf3 -s -F ...zip *(the zip file is ~20GB in size)*
Client command: .iperf3.exe -c 192.... -t 1000 -M 1000
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-218.75 sec 9.21 GBytes 362 Mbits/sec sender
[ 4] 0.00-218.75 sec 0.00 Bytes 0.00 bits/sec receiver
WLAN Stats
- 2.4GHz deactivated
- 5GHz channel width = VHT160
- 5GHz channel = 36
- Transmit power = High
Utilization when using iperf is ~80 %. The PC is connected with about -59dBm signal strength
Okay now to my issue:
When issuing a speed test with speedtest.net, over WLAN I can only achieve ~240 Mbit/sec. When plugging in the cable I instantly run to 295Mbit/sec. I'm using Nessus (10G) as Server.
It even gets worse when like checking the download speed with Steam for example, I only achieve about ~150Mbit/sec.
A colleague of mine told me that this is because of the difference on the window scaling on TCP when comparing internal vs. external where the MTU can be 7000 or even higher internal and on external max 1500. But that is why I use the iperf parameter -M and set the MSS to 1000. Including the TCP header of 40 bytes that simulates an MTU of 1040, thus smaller than on external traffic.
Basically I wonder, I have some IPerf stats, that I'm not able to achieve anywhere in any real life application on my PC. Is the iperf benchmarking the wrong scenario for real life traffic or what is going on?
I have already tried disabling Nagle's Algorithm on Windows 10 with registry, but no changes.
Any advice is highly anticipated and I'm grateful if someone can simply explain me why this will not happen as wished.
wireless-networking wireless-access-point
edited Nov 16 at 16:43
Spiff
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
First and foremost I'm not a network engineer, I'm a software developer. But my general knowledge about networking is oooookay :)
My main problem currently is really understanding WLAN.
OK first the setup.
Modem: Icotera i6850
Broadband: Fiber optic, 300Mbit/sec down, 40Mbit/sec up.
WLAN AP: Ubiquiti Nano HD
PC WLAN Card: Asus AC68
Next the Raw Stats:
These stats are meassured with IPerf 3.1.3 between a Windows 10 PC and a MacBook running macOS.
Server: MacBook Pro (2018) connected via USB-C to Ethernet 1Gbit/sec
Client: Windows 10 x64 connected via ASUS AC68 WLAN Card
Server command: ./iperf3 -s -F ...zip *(the zip file is ~20GB in size)*
Client command: .iperf3.exe -c 192.... -t 1000 -M 1000
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-218.75 sec 9.21 GBytes 362 Mbits/sec sender
[ 4] 0.00-218.75 sec 0.00 Bytes 0.00 bits/sec receiver
WLAN Stats
- 2.4GHz deactivated
- 5GHz channel width = VHT160
- 5GHz channel = 36
- Transmit power = High
Utilization when using iperf is ~80 %. The PC is connected with about -59dBm signal strength
Okay now to my issue:
When issuing a speed test with speedtest.net, over WLAN I can only achieve ~240 Mbit/sec. When plugging in the cable I instantly run to 295Mbit/sec. I'm using Nessus (10G) as Server.
It even gets worse when like checking the download speed with Steam for example, I only achieve about ~150Mbit/sec.
A colleague of mine told me that this is because of the difference on the window scaling on TCP when comparing internal vs. external where the MTU can be 7000 or even higher internal and on external max 1500. But that is why I use the iperf parameter -M and set the MSS to 1000. Including the TCP header of 40 bytes that simulates an MTU of 1040, thus smaller than on external traffic.
Basically I wonder, I have some IPerf stats, that I'm not able to achieve anywhere in any real life application on my PC. Is the iperf benchmarking the wrong scenario for real life traffic or what is going on?
I have already tried disabling Nagle's Algorithm on Windows 10 with registry, but no changes.
Any advice is highly anticipated and I'm grateful if someone can simply explain me why this will not happen as wished.
wireless-networking wireless-access-point
wireless-networking wireless-access-point
edited Nov 16 at 16:43
Spiff
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
edited Nov 16 at 16:43
Spiff
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
edited Nov 16 at 16:43
Spiff
76k10116158
edited Nov 16 at 16:43
Spiff
76k10116158
edited Nov 16 at 16:43
Spiff
76k10116158
76k10116158
asked Nov 16 at 14:07
Yosh Synergi
1
asked Nov 16 at 14:07
Yosh Synergi
1
asked Nov 16 at 14:07
Yosh Synergi
1
1
1
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with-win iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).
– Spiff
Nov 16 at 17:10
Also, what's up with the-Fyou're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify-R(reverse direction) on the client.
– Spiff
Nov 16 at 17:10
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52
add a comment |
1
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with-win iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).
– Spiff
Nov 16 at 17:10
Also, what's up with the-Fyou're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify-R(reverse direction) on the client.
– Spiff
Nov 16 at 17:10
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52
1
1
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with
-w in iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).– Spiff
Nov 16 at 17:10
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with
-w in iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).– Spiff
Nov 16 at 17:10
Also, what's up with the
-F you're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify -R (reverse direction) on the client.– Spiff
Nov 16 at 17:10
Also, what's up with the
-F you're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify -R (reverse direction) on the client.– Spiff
Nov 16 at 17:10
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1376004%2fwlan-external-vs-internal-speed-mystery%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Are you sure that the wireless connection is currently using VHT160 channel width, and not being limited to 80 or 40 (interference, regulatory settings, etc)?
– grawity
Nov 16 at 14:22
The Asus AC68 is only 80 max, the Ubiquiti AP runs on 160
– Yosh Synergi
Nov 16 at 14:46
TCP receive window scaling is a different thing from MTU/MSS. Overriding the default TCP receive window size is done with
-win iperf. You don't actually get 7k MTUs internally because Wi-Fi doesn't support them (and jumbo frames are disabled by default on almost all network endpoint devices).– Spiff
Nov 16 at 17:10
Also, what's up with the
-Fyou're doing on the iperf server side? I'm pretty sure iperf sends data from the client to the server by default (think of it as an upload test). I'm not sure what specifying a file on the server side would do, but it probably doesn't cause the server to send that file, unless you specify-R(reverse direction) on the client.– Spiff
Nov 16 at 17:10
The usecase of the file with -F was to reduce compression algorythm on the AP. But I never saw a difference when using this or the default random data. And I will give the -w a try to check If I can simulate the values better thx
– Yosh Synergi
Nov 16 at 17:52