Slow wired upload speed vs Linux on same hardware

Dawid Oosthuizen 26

Intel® Ethernet Controller X550-AT2, 10G network interface on ASRock Rack ROMED8-2T with AMD EPYC 7232P processor.
Windows 10 Pro for Workstations, 2004.
Latest Windows updates and Intel drivers installed as of 09/09/2020.

This machine is a dual boot, the above Windows version, and Ubuntu 20.04.
When doing a speed test, I get good performance from Ubuntu, but very poor uploads from Windows. This is on the same machine, the exact same hardware.

The WAN link is 1000Mbps down, 50Mbps up.

This is the Windows speedtest result:

This is the Ubuntu speedtest result:

I have tried to tweak the adapter's advanced driver settings in Windows, such as disabling LSO, etc. No luck, performance remains poor.

I've also noticed it on another PC running Windows 10 Pro, and a laptop running Windows 10 Pro for Workstations, both give the same poor upload performance. Whereas my other Ubuntu 20.04 Server machine, and also my phone connected via Wi-Fi, is getting good upload speeds.

I have even taken the Windows laptop and plugged it straight into my incoming WAN connection (bypassing router), and it still gets poor upload speeds.

Incidentally, when the speed test is running, I can see that the upload looks bursty on Windows, like it is only getting chunks of data here and there, while in Linux and on Android it looks the same as the download, the graph is drawn at a consistent high rate and with consistent high values.

franco d'esaro 25,181 Reputation points Volunteer Moderator

2020-09-09T12:47:10.917+00:00

Hello,
Firewall / Antivirus in use on Windows machines?
Try running and maintaining a Clean Boot on Windows machines:
https://support.microsoft.com/en-us/help/929135/how-to-perform-a-clean-boot-in-windows
Dawid Oosthuizen 26 Reputation points

2020-09-10T01:19:34.907+00:00
Thanks for the suggestions, unfortunately no luck:

I'm using Microsoft's Windows Defender, not a third party product. And disabling Defender (virus protection and firewall) had no effect.

Also did a clean boot (only MS services enabled), no effect.

I've added some more info in my original post, FWIW.
mensa84 6 Reputation points

2020-11-12T00:22:07.743+00:00

Did you find a solution? I habe exactly the same problem :(
Guery Illanes 1 Reputation point

2021-07-08T23:42:19.677+00:00

Hi,
Try with PDANET software. Must be installed in laptop with Windows and also in mobile. It works fine with this issue.

Guery
Guery Illanes 1 Reputation point

2021-07-08T23:42:45.823+00:00

Hi,
Try with PDANET software. Must be installed in laptop with Windows and also in mobile. It works fine with this issue.

Guery
@Live MiaoSKY 0 Reputation points

2025-03-31T01:57:03.21+00:00

This problem has been bothering me for a long time, and I finally found out that it was a problem with speedtest.net. It limits the user-agent of edge. If you use the user-agent of edge, the upload speed is only about 5mbps.

After I used the extension to change it to the user-agent of chrome, the upload speed went up.... Fuck speedtest.net!!!

这个问题让我头疼很久, 最后发现是speedtest.net的问题. 它限制了edge的user-agent, 如果你使用edge的user-agent, 上传速度就只有5mbps左右.

在我使用扩展插件修改成chrome的user-agent以后上传速度就上去了.... 真是fuck speedtest.net !!!

50 answers

Gary Nebbett 6,536 Reputation points

2020-12-11T13:31:29.307+00:00
Hello @mensa84 ,

Open a PowerShell window running as administrator. This image shows one way of doing that (right mouse clicking over the Windows PowerShell icon and choosing "Run as Administrator"):

Now get ready to run the speed test (but don't start it yet) and then paste the following four commands into the PowerShell window:
```
 New-NetEventSession -LocalFilePath $Env:TEMP\SlowUp.etl -Name SlowUp  
 Add-NetEventPacketCaptureProvider -TruncationLength 100 -Level 255 -SessionName SlowUp  
 Add-NetEventProvider -Name "Microsoft-Windows-TCPIP" -Level 255 -SessionName SlowUp  
 Start-NetEventSession -Name SlowUp  
```
Now start the speed test. As soon as it ends, paste the following two commands into the PowerShell window:
```
 Stop-NetEventSession -Name SlowUp  
 Remove-NetEventSession  
```
You should now have a file containing the trace data (%TEMP%\SlowUp.etl, i.e. a file named SlowUp.etl in your temporary files directory).

The file will be quite large, and the best way of sharing it is by copying it to a network storage service, such as Microsoft OneDrive, Google Drive, Dropbox, etc., and posting a link to the file.

Gary
Was this answer helpful?

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

mensa84 6

Here are the ping results where I saw, that the answering server is inside my country (Austria):

ping -n 100 ping.ubnt.com

Ping wird ausgeführt für d2cnv2pop2xy4v.cloudfront.net [99.86.244.96] mit 32 Bytes Daten:
Antwort von 99.86.244.96: Bytes=32 Zeit=24ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=31ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=24ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=27ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=19ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=33ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=29ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=22ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=23ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=21ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=13ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=22ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=19ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=21ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=26ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=21ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=22ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=29ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=19ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=29ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=27ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=23ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=26ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=19ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=19ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=28ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=14ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=24ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=23ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=31ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=22ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=31ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=16ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=23ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=17ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=15ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=20ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=23ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=28ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=18ms TTL=244
Antwort von 99.86.244.96: Bytes=32 Zeit=24ms TTL=244

Ping-Statistik für 99.86.244.96:
    Pakete: Gesendet = 100, Empfangen = 100, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 13ms, Maximum = 33ms, Mittelwert = 19ms

0 comments

mensa84 6 Reputation points

2020-12-11T12:01:52.207+00:00

Hello,

thanks for the explanation :)

Yes, until around 1 month ago, I also got 50 Mbit/s upload speeds on the same Windows 10 machine. But I did not change anything and also did not find Windows Updates, which have been installed at exactly that day.

Normally I do my speed tests at speedtest.net and use the nearest, suggested server. But I there I don't see the hostname / IP address which I should ping for your first test. How should I find out that IP?
Was this answer helpful?
Gary Nebbett 6,536 Reputation points

2020-12-11T12:14:08.853+00:00

Hello @mensa84 ,

Just ping speedtest.net or any other major Internet site (Microsoft, Google, etc.).

The ping test is very "rough and ready" and should show close to zero packet loss. As a first step, all I am trying to find out is if there any any hints that your link is very lossy.

Gary

mensa84 6 Reputation points

2020-12-11T12:24:13.917+00:00

I posted my answer as reply, because it was too long. It is waiting for review.

Here is the short version of the result of 100 pings from a server (ping.ubnt.com), where I know, that the answering server is inside my country (Austria):

Ping-Statistik für 99.86.244.96: Pakete: Gesendet = 100, Empfangen = 100, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 13ms, Maximum = 33ms, Mittelwert = 19ms

Gary Nebbett 6,536 Reputation points

2020-12-11T12:43:40.043+00:00

Hello @mensa84 ,

The summary (0% loss, low round trip time and low variance in round trip time) looks very good. It would be worthwhile collecting and sharing the Event Tracing for Windows data that I mentioned earlier (using New-NetEventSession and so on) - if you are comfortable doing so (some people are reluctant to share any data about their systems in case it is misused by a network attack).

It's up to you what to do next. I am interested to understand what is happening (and the trace data might reveal that), but there is no guarantee that it will lead to a solution to your performance issue.

BTW: I am in Switzerland (Basel), so we share a common land border :-)

Gary

mensa84 6 Reputation points

2020-12-11T13:14:37.277+00:00

Cool, but what exactly should I do next?
Make a speedtest and then share any event tracing?
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Gary Nebbett 6,536 Reputation points

2020-12-10T14:37:19.673+00:00

Hello @mensa84 ,

I am still not sure whether you understood my first question: have you ever experienced 50 Mbit/second upload speeds from your local network using a Windows system?

It is clear that you do get 50 Mbit/second with other systems and would like to obtain that under Windows, but it would be useful to be clear about the historical situation concerning Windows.

If you are prepared to share the trace data generated by the commands that I mentioned in an earlier message (using New-NetEventSession and so on) then I will take a look at it.

It is quite possible that an analysis of the trace data will show a lossy link (a link that "loses" IP packets). If that is the case then there is currently nothing that can be done under Windows to improve the situation (none of the built-in congestion control mechanisms provides high throughput over lossy links). All that would remain would be to try to identify the "lossy" leg of the routing path...

Perhaps we could start with a very simple first step. When you "ping" the system(s) that you use for your upload speed tests, what is the summary of the ping results? To make this more useful, it would make sense to use the "-n" option of ping to specify the number of ping attempts (about 100 should be enough). For example:

ping -n 100 www.microsoft.com

Pinging e13678.dspb.akamaiedge.net [2.21.38.54] with 32 bytes of data:
Reply from 2.21.38.54: bytes=32 time=20ms TTL=47
Reply from 2.21.38.54: bytes=32 time=18ms TTL=47
[...]
Reply from 2.21.38.54: bytes=32 time=19ms TTL=47
Reply from 2.21.38.54: bytes=32 time=24ms TTL=47
Reply from 2.21.38.54: bytes=32 time=181ms TTL=47

Ping statistics for 2.21.38.54:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 181ms, Average = 19ms

The information in bold is what I would like to see.

Gary
Was this answer helpful?

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
mensa84 6 Reputation points

2020-12-10T03:59:13.647+00:00

Hello,

is there any solution or workaround to ger normal upload speed in Windows 10 back again?
I still don't understand why I habe full 50 Mbit upload on Linux and Apple devices, but only around 4 Mbit in Windows 10. Can somone please explain it not so deeeply technically to me?

I would even buy other hatdware if that would help?
Was this answer helpful?
Gary Nebbett 6,536 Reputation points

2020-12-10T13:15:30.73+00:00

Hello @mensa84 ,

When you say get normal upload speed "back again", do you mean that you previously measured a 50 Mbit upload speed under Windows?

As can be seen from the messages in this thread, there are a large number of things that could affect upload speed and one needs to perform some investigation to understand what the particular problem on a specific system is. I have previously mentioned one first step that I think helps in making this determination.

In the discussion between myself and Egoist-7680, it was fairly clear that the problem was related to a combination of the TCP congestion control algorithm and the packet loss characteristics of the link. Windows does not currently support the BBR congestion control algorithm which, at a cost, provides better throughput for suitably configured *nix systems over a lossy link.

Gary

mensa84 6 Reputation points

2020-12-10T13:24:05.633+00:00

Yes, I mean 50 Mbit upload, like I have it on all Linux and Apple devices. I test only over Gigabit LAN cables and also do tests directly at the 5G modem.

What I already tried and nothing helped:

Changed CAT6 cables

Tried 3 different (2 new) network cards

Completely re-installed Windows 10 with formatting HDDs

Re-installed Windows 10 on other hardware

Installed Linux on same hardware solved the problem. But often I need Win 10.

Nothing helped.

In the meanwhile I found out, that EDGE browser may have an additional problem. Cause in Win 10 EDGE the upload speed is always only 4 Mbit but in Firefox in Win 10 it's always around 20 Mbit. And in EDGE in Linux it's always 50 Mbit.

Do you think that 5G mobile internet and / or my ISP could be the problem? But as I said, all Apple and Linux clients are fine, why can't I just configure Windows to do the same?
On Apple and Linux devices I have really ALWAYS 50 Mbit uplod at least.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Slow wired upload speed vs Linux on same hardware

50 answers

Your answer