Downtown Doug Brown

I previously blogged about a strange problem I’ve been experiencing where my internet upload speed tests fail to reach the expected gigabit speed that my ISP provides — but only in Windows 10. I have a quick update on where I ended up with this problem, and a collection of further test results that point the finger at Windows 10’s TCP stack.

I didn’t mention this in my previous post, but the Seattle server I’ve been using for all of my testing (and seeing the problem with) is run by my ISP. The main thing I figured out, and I’m embarrassed I didn’t try this earlier, is that I do get my full upstream speed in Windows 10 on some (but not all) other nearby test servers, one of which is also run by my ISP.

These two servers don’t always give me perfect speeds, but the upload speeds are excellent every time. When the speeds aren’t perfect, it’s likely due to sharing bandwidth with other people running tests. My understanding based on Reddit posts by employees at my ISP is that their Seattle server is on a 10 gig connection and the Everett server that they also run is on a 1 gig connection. So it makes sense that I won’t always get perfect test results on the Everett server, because if anyone else is testing at the same time as me, they will use some of the bandwidth.

So basically, the Seattle test server, which is on a much beefier link to the internet, doesn’t interact well with uploads from my connection for some reason — but only when I’m testing with Windows 10. Linux, macOS, and Windows 11 all test perfectly with it. Yesterday morning, I was actually able to get it to give me a perfect result in Windows 10. But it wasn’t repeatable. My next test 4 minutes later had a much slower upstream speed, and several additional tests confirmed that my fast test was a fluke.

Interestingly enough, someone else a while ago on Reddit saw strange results with the Seattle server too. They have 200/200 fiber internet, and found that while both the Seattle and Everett servers provide the full bandwidth when wired over Ethernet, the Seattle server is more erratic over WiFi, mostly on the downstream side. The prevailing theory in the Reddit post was that the 10 gig link’s “burstiness” may be hitting buffer limits that cause worse results on WiFi. This is again a situation where TCP is pretty dang complex! I don’t know what OS that person was testing on, and I know that WiFi opens up another can of worms with speed testing, but it’s interesting to see someone else also noticing differences in test results between the two servers.

The problem I’m seeing is definitely not unique to just the Seattle server I’ve been testing on though. I found other nearby servers that give me good downstream speeds with poor upstream speeds. Those results don’t concern me as much, because I don’t know how much available bandwidth those servers have in each direction.

Just for the fun of it, I did an extensive set of speed tests with one of my older computers yesterday (the Intel DX58SO motherboard I repaired a while ago with an i7-920 CPU). I tested a bunch of different OSes and combinations of virtual machines, all using my ISP’s Seattle test server. I had already done some of this earlier, but I hadn’t officially recorded my results anywhere.

• Windows 11: 928/939, 941/939
• Windows 10: 938/517, 941/614
• Ubuntu 22.04: 932/932, 932/936
• Windows 11 Hyper-V guest inside of Windows 11 host: 927/931, 934/940
• Windows 11 Hyper-V guest inside of Windows 10 host: 937/932, 940/938
• Windows 10 Hyper-V guest inside of Windows 11 host: 941/697, 941/345
• Windows 10 Hyper-V guest inside of Windows 10 host: 934/269, 936/390
• WSL Ubuntu 20.04 guest inside of Windows 11 host: 341/936, 439/936
• WSL Ubuntu 20.04 guest inside of Windows 10 host: 405/936, 358/936
  • WSL seems to have some issues with downstream speeds, confirmed across multiple computers. I’m not sure what causes this, but these results are still demonstrating full upload bandwidth which is what I’m trying to test.

Clearly, something is wrong with my uploads when Windows 10 is the actual OS running the speed test. That includes being a guest VM. I still find it funny that Windows 10 by itself gives me bad upload speeds, but is still capable of having good upload speeds as a host for guest VMs of other operating systems. In my mind, this pretty conclusively places the blame on Windows 10’s TCP stack.

I think I had already convinced myself in the last blog post that I’m seeing the same problem that Dropbox discovered a while ago. I feel even more convinced of that now. My ISP agrees, and even hinted at maybe needing to apply the same type of fix to their test server. If that is indeed what’s going on, that would at least cause my speed tests to come out better, but it doesn’t really solve the actual problem, which is that Windows 10 has a problem in its TCP stack. I still don’t understand why everyone using Windows 10 isn’t seeing the same upload slowdown I’m seeing when testing with the Seattle server, but I’m sure there’s a logical explanation.

That logical explanation is likely way over my head due to the complexities of TCP, but at least I feel like I can sleep well at night knowing that my upstream speeds are fine, and the real problem is that Windows 10 doesn’t interact well with some servers during uploads in certain circumstances. I think the bottom line is that speed testing gets way more complicated once you’re up in the gigabit and higher range.