Network throughput drops to 0Kbps (send and recieve) every 8 seconds, adapter fine on other PCs

Question

System:
HP 290 G1 Microtower PC
Processor Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz 3.40 GHz
Installed RAM 8.00 GB (7.89 GB usable)
Device ID EA9D01FF-A2BC-4AF7-99C6-36A4BAF78CC2
Product ID 00330-50826-60474-AAOEM
System type 64-bit operating system, x64-based processor
Edition Windows 10 Pro
Version 21H1
Installed on ‎12/‎07/‎2021
OS build 19043.1415
Experience Windows Feature Experience Pack 120.2212.3920.0

Wifi speed drops to 0Kbps every 10 seconds or so for about 2 seconds both send and receive
I have two identical USB Wifi adapters and it’s the same for both adapters but just when in this PC.

Resource monitor shows the same issue
What I have tried:

• Testing with data from the web or transferring data from my NAS on the same subnet. Both have the issue so it’s not an issue with broadband.
• Swapped to another identical 802.11ac USB network adaptor – they both work fine in another machine – so I don’t think the adapter is the issue.
• Switch to another brand adapter (802.11n only) – works fine
• Another PC with this adapter in the same room has no problems and is on same wifi 5GHz channel so that rules out the Wifi signal having problems. Same wifi/network setup, same driver, same update version of windows.
• Tried manual DNS configuration to 8.8.8.8 and 8.8.4.4
• Latest update to router
• Latest update to Windows
• Latest f/w for adapters
• Latest BIOS for PC
• Turned off adapter power management
• Tried latest manufacturer and latest MS drivers for adapter
• Different USB ports tried both 2.0 and 3.0
• Airplane mode on/off
• Router reboot (full power off)
• PC reboot (full power off)
• “Forget” and reattach to network
• Uninstalled VPN
• Reboot with all start-up programs and all non-Microsoft services disabled
• Link speed to router checked = 585Mbps
• Set the adapter as the only connection on the 5GHz channel
• Set the adapter as the only connection on the 2.4GHz channel
• Tried Static and DHCP IPV4 addressing
• Network RESET in settings
• Network troubleshooter
• Network Adapter Troubleshooter
• Incoming Connections troubleshooter
• Internet Connections troubleshooter
• HP Network Check
• Tried switching off local firewall
• Tried switching off router firewall
• HP Hardware diagnostics 1.8.0.0

Hardware properties:
SSID: xxxxxxxx
Protocol: Wi-Fi 5 (802.11ac)
Security type: WPA2-Personal
Network band: 5 GHz
Network channel: 60
Link speed (Receive/Transmit): 585/585 (Mbps)
Link-local IPv6 address: xxxx::xxxx:xxxx:xxxx:xxxxxx
IPv6 DNS servers: xxxx::xxxx:xxxx:xxxx:xxxxxx
IPv4 address: 192.168.1.83
IPv4 DNS servers: 192.168.1.1
DNS suffix search list: broadband
Manufacturer: Realtek Semiconductor Corp.
Description: Realtek 8812BU Wireless LAN 802.11ac USB NIC
Driver version: 1030.38.712.2019
Physical address (MAC): 1C-BF-CE-7D-75-D4

I have spent so many hours on this - it's driving me nuts. Any input or suggestions gratefully received.

Thanks in advance

Nick

Answer 1

Hello Nick,

There are lots of possible next steps, but rather than spending effort weighing the merits of each, let's just start with a simple test:

• Issue the command netsh trace start report=disabled overwrite=yes provider=Microsoft-Windows-WLAN-AutoConfig tracefile=why.etl.
• Wait 3 or so minutes.
• Issue the command netsh trace stop.
• Issue the command netsh trace convert why.etl why.txt

There should be some readable information in why.txt.

Looking directly at why.etl using my tools and filtering some junk, I see on my system:

The events highlighted in green happened when I performed a search in Google - I have enabled Google to request my location when performing searches.

I think that we will see a scan being initiated every 10 seconds on your PC and, if so, we will then have to search for the client that requested the scan.

Gary

Answer 2

Hello Nick,

The two ideas that I wanted to check both proved to be unfounded. One idea was that the interrupt from the network adapter might be masked for extended periods, but the trace shows interrupts from the adapter even during the "pauses" in packet reception.

The second idea was that something might be preventing the scheduling of the thread that handles packet reception (rtwlanu!RxNotifyThreadCallback), but this is also not the case - there is no attempt to make ready and schedule this thread during the "pauses".

The adapter driver seems to create 7 different system threads, each presumably with a different purpose; the work resulting from the interrupts that occur during the pauses are routed to some of the other threads; we may be able to extend the trace data collection to get an idea of what these threads are doing.

The adapter driver (rtwlanu.sys) is very large (approaching 10MB, half of which is code) - it's bigger than any other driver that I have and approaches the size of the NT kernel, so it is not easy to second-guess what it is doing.

Everything looks OK from a Windows perspective (but the fact that the adapter(s) work in other PCs is not lost on me) - my attention now is very much focussed on the Realtek rtwlanu.sys driver (at least as a source of new ideas, prompted by more detailed tracing). The driver is up-to-date.

Gary

Answer 3

Hi Gary,

Managed to get a quick email in before sleep as I'm away from home now.

Currently Windows tells me that I have the ms driver not the realtek one installed. If it's still using the realtek one then could that be thd issue. Can I delete realtek drivers to force ms ones?.

I have a spare hdd. I could try a fresh install with no other drives or hardware then build up pc testing at each stage. That could rule out possible hardware cause?

Nick :-)

Answer 4

Hi Gary,

Speed not an issue as have another brand of adapter that works ok. My suggestion was to do a fresh install on another drive to rule out hardware then put original drive back in to keep troubleshooting if the hardware had proved ok.

Will be home Friday evening so will be able to check on drivers. Originally was using Windows drivers then downloaded and installed realtek, then when they didn't work went back to ms. Didn't check the driver details after going back to MS.

I did however check all driver options were exactly the same as in in the the working machine-driver combo that is in the same room. Both PCs are HP but slightly different models.

Have a nice day.

Nick :-)

Answer 5

Hi Gary,

Here's the trace.... ping-why.etl

Below is the Ping result, there was a 2s+ almost immediately, then a time out, then a 3222ms delay, after which I stopped the trace
(The correct adapter was in !!! ;-) )

Being called to bed by She Who Must Be Obeyed!

Continuing thanks Gary :-)

Nick

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2788ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=62ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=26ms TTL=64
Reply from 192.168.1.1: bytes=32 time=243ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=104ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=77ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=40ms TTL=64
Reply from 192.168.1.1: bytes=32 time=7ms TTL=64
Reply from 192.168.1.1: bytes=32 time=70ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3222ms TTL=64
Reply from 192.168.1.1: bytes=32 time=32ms TTL=64
Reply from 192.168.1.1: bytes=32 time=55ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=44ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=1340ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=51ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3345ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=12ms TTL=64
Reply from 192.168.1.1: bytes=32 time=47ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=48ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2905ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=109ms TTL=64
Reply from 192.168.1.1: bytes=32 time=29ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=53ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=37ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2878ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=220ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=1512ms TTL=64

Ping statistics for 192.168.1.1:
Packets: Sent = 50, Received = 44, Lost = 6 (12% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3345ms, Average = 440ms