Slow wired upload speed vs Linux on same hardware

Dawid Oosthuizen 26 Reputation points
2020-09-09T05:18:31.053+00:00

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:
23320-windows-10-speedtest.png

This is the Ubuntu speedtest result:
23325-ubuntu-2004-speedtest.png

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.

Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing

50 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. mensa84 6 Reputation points
    2021-01-04T16:10:20.957+00:00

    The Microsoft developers are aware of that problem? Why do you know that?

    And one other question: Why do you think, that it suddenly stopped working (full speed upload) without installing any updates? How can obe explain that?

    Was this answer helpful?

    0 comments
  2. mensa84 6 Reputation points
    2021-01-04T16:10:06.453+00:00

    The Microsoft developers are aware od that problem? Why do you know that?

    And one other question: Why do you think, that it suddenly stopped working (full speed upload) without installing any updates? How can obe explain that?

    Was this answer helpful?

    0 comments
  3. mensa84 6 Reputation points
    2020-12-24T13:01:43.367+00:00

    Thx, but it did not change anything :(

    Was this answer helpful?

    0 comments
  4. Gary Nebbett 6,536 Reputation points
    2020-12-21T15:30:07.973+00:00

    Hello @Moosa Mahsoom ,

    That is interesting, the new graph of the upload connection looks like this:

    50041-image.png

    It is (surprisingly) similar to the RTMP graph. One odd thing is that this time, the "congestion avoidance" algorithm is Compound TCP (CTCP) rather than CUBIC. Have you been experimenting with commands like "netsh int tcp set supplemental template=internet congestionprovider=ctcp"?

    The reason for the very slow adjustment of the congestion window will need some more time to investigate, but it would be very helpful to know why the congestion provider seems to have changed...

    Gary

    Was this answer helpful?

  5. Gary Nebbett 6,536 Reputation points
    2020-12-21T13:49:04.93+00:00

    Hello @Moosa Mahsoom ,

    The behaviour of your connection appears to be more similar to that of Egoist-7680. In this case, the path is "lossy" (i.e. packets are lost en route) and the "congestion avoidance" algorithm used by Windows ("CUBIC", in this case) does not match the throughput obtainable with other congestion avoidance algorithms used by some other systems (e.g. "BBR"). There are open questions about the network "fairness" of algorithms such as "BBR"; in any event, "CUBIC" is the best algorithm currently natively available under Windows.

    Passing your connection through an additional device can only worsen the problem; it is the "end-user" device (Windows) that chooses the algorithm and makes the key decisions about windows sizes, retransmissions, etc..

    I checked many of the retransmissions in the trace and they were all appropriate (the retransmitted data was not acknowledged until at least one round-trip time had elapsed since the retransmission) - this is the big difference to the behaviour observed by mensa84-6815, where retransmissions occur after the data has been acknowledged (but before the acknowledgement has been "processed").

    Your trace data was of a "useful" network connection using a higher level protocol (Real-Time Messaging Protocol (RTMP) ) rather than a straightforward speed test. In RTMP, RTMP protocol interactions do occur and this has some impact on the perceived throughput. This is a graph of the throughput from client to server (the darker line is the data throughput, the lighter line is the receive window boundary):

    49910-image.png

    Over the lifetime of the connection, the average throughput was 180 kilobytes/second or 1.5 megabits/second; however, near the end of the connection, a throughput of 615 kilobytes/second or 5 megabits/second was sustained for a short time. Since we truncated the capture length so that not much more than the TCP headers are captured, it is difficult to say what impact higher level (RTMP) protocol interactions had on the throughput.

    Sorry, but I don't have any good ideas about what could be done to improve the situation.

    Gary

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.