Windows server upload speed problems

Question

Hello, so we have some problem that i cant find any solution..

We have a server with windows server 2019 (latest updates) connected 10G network card directly to 10G router and next ISP router.

we get 9Gb/s download and ~1,5Gb/s upload.

when downloading over internet from that server we get only 10MB/s speed

When we change network card speed to 1GB, download from same server to same computer go up to ~50MB/s

I was trying to change network adapter settings, but nothing helped.

This problem only occurs on windows server, on linux everything go normal and we get even more speed.

Answer 1

Hello @Aurimas Kurauskas ,

I would suggest looking at this thread to check the extent that your observations match what others have reported: https://learn.microsoft.com/en-us/answers/questions/330172/extreamly-slow-upload-speed-in-windows-all-other-o.html

To really get a deeper insight into what is happening, it is useful to use the Microsoft-Windows-TCPIP ETW provider to trace activity on the sending system (the Windows 2019 server, in your case) and to pay particular attention to the development over time of the congestion window (cwnd).

Gary

Answer 2

But is very strange that if i connect my network card to 1G i get the speed that clients want.. with 10G its too slow..

I installed windows server 2022 and the speed a bit increased

but still not so fast when with 1G

Answer 3

Hello @Aurimas Kurauskas ,

The observed behaviour may be counter-intuitive, but it would be necessary to compare traces of the 10G and 1G cards before concluding that the behaviour is inexplicable.

Some "auto-tuning" of TCP behaviour is based on estimates of the bandwidth and latency product. It may be the case that this auto-tuning is pushing the behaviour into a region where (when combined with the congestion control mechanism) the increased bandwidth results in increased packet losses and more severe congestion control steps.

If you are prepared to create traces for the two configurations and share them, then let me know - I can then suggest what test steps would be useful.

Gary

Answer 4

I am prepared for anything that would confirm that is not our problem.

I can make many test but at this moment i dont know what to test.

Answer 5

Hello @Aurimas Kurauskas ,

Here is another thread on Microsoft Q&A describing essentially the same problem: https://learn.microsoft.com/en-us/answers/questions/89768/slow-wired-upload-speed-vs-linux-on-same-hardware.html

The command that I would suggest to start a trace is pktmon start --capture --comp nics --flags 0x10 --trace --provider Microsoft-Windows-TCPIP --keywords 0x200700000000 --level 16 --file-name why.etl and the command to stop the trace is pktmon stop

The trace needs to be run on the sending system (the system where the congestion control is taking place). In your case this is the server. The trace just needs to capture a few seconds of activity during the "upload" (from the server to the client). The trace will capture all network activity of the server during the trace. The trace will grow in size quite quickly, so it is worthwhile trying to construct a short test scenario that "captures"/exhibits the problem.

Most (actually all) of the performance problems that I have helped with in this forum occurred when the client was sending data (and the traces were made on the client system); there are probably more "confidentiality" issues when tracing on a server. If you are still willing to share the captured data, I would suggest making it available via a file sharing service such that readers have to "request" access. Alternatively you can try to contact me directly (perhaps via LinkedIn - I am the only "Gary Nebbett" there) to discuss other transfer mechanisms.

Gary