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

Hi Gary,

Hmmm - don't think it's the level of data!

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms 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=2934ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=46ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2780ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=10ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=7ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms 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=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=9ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2893ms TTL=64
Reply from 192.168.1.1: bytes=32 time=8ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2940ms TTL=64
Reply from 192.168.1.1: bytes=32 time=15ms 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=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2938ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.1.1:
Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2940ms, Average = 293ms

Kind regards

Nick

Answer 3

Thanks so much Gary,

I'm in the UK but use Mega.nz as a cloud service due to security reputation of their system (and 50GB of free storage!).

I will be away for 4 days from tomorrow and then be doing 3x 12 hour shifts so responses will be a bit lagging.

Please don't bust a gut as the PC is working and I have a spare NIC. It's a fun challenge to crack this one. Looking forward to persevering with it.

Thanks again for your valued assistance.

Nick

Answer 4

Hi Gary - possibly a clue and an apology.

I had just finished writing my last reply and realised that I had a working USB NIC inserted rather than the problematic one. Below is the ping test with the problematic one, which is a worse result than the non-problematic one, Sorry! However it does give us a clue does it not? It seems there may be an underlying issue that one NIC is handling better than the other???
(I did a 50x ping on the other PC in the room with the problematic NIC and there were no issues, all fast, 1-3ms response.)

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=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3504ms 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=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Request timed out.
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=454ms TTL=64
Reply from 192.168.1.1: bytes=32 time=112ms TTL=64
Request timed out.
General failure.
Request timed out.
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3131ms TTL=64
Reply from 192.168.1.1: bytes=32 time=95ms TTL=64
Reply from 192.168.1.1: bytes=32 time=12ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=6ms 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=2874ms TTL=64
Reply from 192.168.1.1: bytes=32 time=8ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=7ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=3ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2937ms TTL=64
Reply from 192.168.1.1: bytes=32 time=5ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64
Reply from 192.168.1.1: bytes=32 time=2ms TTL=64
Reply from 192.168.1.1: bytes=32 time=4ms TTL=64

Ping statistics for 192.168.1.1:
Packets: Sent = 50, Received = 46, Lost = 4 (8% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3504ms, Average = 287ms

Sleep well

Nick :-)

Answer 5

Hello Nick,

This trace won't crack the problem by itself, but it might help.

Save the attached file as sched.wprp. A trace can be started with the command wpr -start sched.wprp!Net -filemode

When the trace has started, issue the "ping" command again; the ping can be stopped with Ctrl-C as soon as one is sure that one of the long ping reply events (greater than 2 seconds) has occurred.

The trace can then be stopped with the command wpr -stop why.etl.

Gary

160699-schedwprp.txt