Wednesday, September 13, 2023

Solving slow Intel AX201 WiFi on Surface Pro 7 (and why Microsoft paid for support wasn't worth it for me)

TL;DR

It’s ToE on a Hyper-V vSwitch.  Go to the end for the fix.

 

The Long Version

After a series of upgrades (I’m not sure which ones) my Surface Pro 7, whilst working fine seemed to be rather slow when synchronising email/OneDrive/DropBox files.  To my surprise when I looked into it with SpeedTest my Wi-Fi connection was running at just over 1Mb download and a measly 0.1Mb upload.  No wonder!

To check the scope of the problem, I connected to other Wi-Fi networks (including a hotspot from my phone) and got the same result.   So I hauled out the Surface USB Ethernet Adapter and connected directly – all was good.  After hunting around online I found that I wasn’t the first to see this; and hardware was very much implicated (or rather hardware not recovering from sleep).  I tried various solutions suggested, and stopped using sleep mode (I tend to switch on, work, shutdown anyway).  To no avail.

So as I had a few years Business Warranty left I placed a tech support call.  And this had to be the worst technical support experience I’ve had with Microsoft ever.  I’m not sure it ever got to the right team in the weeks that followed.  It certainly never got to anyone who could propose a good fix, and I’m not sure that if I had had a hardware problem Microsoft would have even honoured the warranty I purchased (because I could find no route that seemed to invoke it).

I had already rebuilt the computer from scratch using the normal tools; but despite this I was pushed to do it again, but stay off the domain take logs and upload them.  This I did.  Microsoft never gave me feedback from the submitted logs.

However *good news alert* - as a virgin build the machine did have acceptable Wi-Fi performance again!

So time to bring my machine back to useful operation.  Which (as a major part of my working life) included recovering Hyper-V VM disks and rebuilding my test VM's.  At which point the problem recurred.

On a whim (as pretty much nothing else had touched networking), I deleted the VM’s and removed the Hyper-V vSwitch.  It worked!!  I was able to reliable reproduce the problem by creating and deleting the vSwitch and checking with SpeedTest. 

I thought this would be good news for Microsoft Support, and that they might be able to point me at something.  However, the Microsoft Support team to who I was talking said it wasn’t their issue anymore, and suggested I open a new ticket with the Hyper-V team and to open a ticket with them – I don’t get how they can just wash their hands and dump me to the back of the queue.  But it’s what they did.  Apparently support tickets cannot be moved between the teams.

Disappointed I turned back to the problem.  Knowing the vSwitch was implicated changed my attack and searched again.  I found these two articles online

Hyper-V Causes Extreme Degradation of Performance on WiFi Solved - Windows 10 Forums (tenforums.com)

Solved: Re: Hyper-V External Virtual Switch Bridge Mode - Slow download speeds on 8265AC - Intel Community

The latter of which lead me to

Network Optimizations - BizTalk Server | Microsoft Learn  - yes I KNOW it’s a BizTalk article – but trust me, lateral thinking and linking can really improve your fault diagnoses and fixes.

Which finally took me to a broken page link in this paragraph:


So I just BING’d the title of the article.   And got to Using Registry Values to Enable and Disable Task Offloading - Windows drivers | Microsoft Learn

 

Hallelujah!!!  Switching off Task Offloading on the network worked.  The steps to take are:

  1. Open Device Manager and locate “Microsoft Network Adapter multiplexor Driver”
  2. Right-click, Properties.
  3. Disable LSO settings 'Large Send Offload Version 2 (IPv4)' and 'Large Send Offload Version 2 (IPv6)', as shown in the following screenshot.

 




When they are disabled I got 75/18 MB out of an 80/20 internet connection.  When enabled that dropped to 1.5/0.1.

 

Postscript

I reported this back to Microsoft with the details thinking they’d be pleased.  They just replied with “We have escalated your support request to our colleagues in Windows/ Virtualization and Hyper-V unfortunately they are unable to assist thru our escalation. 

Please, contact them directly opening a new support request and choosing the support path from the screenshot below. “

Pathetic.

 

I’d asked Microsoft for answers to these questions – if you know the answers I’d like to hear from you, I don’t expect Microsoft will reply.

  • What is the Multiplexor Driver (used for NIC bonding) doing in the Hyper-V setup, and how does it fit into the overall networking picture?
  • Is this an AX201 specific bug (I have the same chip in Intel NUC machines here)?
  • Will this be resolved with a windows update that removes the performance penalty for setting ToE on, or default the ToE settings to disabled in a Hyper-V environment?

 




No comments: