Forum

Added 4 May 2019:

Since nobody is likely to read through this struggle to the end to see the resolution, I've made it a new post:

https://www.cwnp.com/forums/posts?Win-10-Wi-Fi-No-auto-switch-but-scan-every-ten-seconds---stopped-124846

There are lots of details to be learned from what follows here, but none of it affected the actual problem. 

I have a strange issue where every ten seconds my Wi-Fi throughput gets choked back drastically. I've dug pretty deeply into how it happens, and in all of my searching for clues about the mystery, this website is the first place I've found people talking on the level of detail that seems to be involved. I hope my questions are not too ignorant.

I live in rural Northern California, "Northwest Nowhere" for internet service. It has taken many years to progress from driving to a pay phone, hanging an acoustic coupler out the van window, and making a long distance call to a Telenet node, to actually having a solid 16Mb/s WISP connection. For most of that time, random variation hid the ten-second periodicity. But with the new WISP hardware, it is obvious - and stealing half of my bandwidth!

It happens with any router or AP, with internet data or connections to the local wired net, and with any _Windows_ machine from XP to 7 to 10. If a Windows machine is awake, there is a ghost of the effect noticeable on various Linux flavors and on iOS, but it is a gradual curve instead of the sharp drop, and not as deep. If no Windows machines are live (a rare occurrence), the others see full speed.

Here's what happens, every ten seconds, with a high-end Windows 10 Surface Book running a Telnet session to a Wiznet ethernet-serial board wired to a TP-Link TL-WDR3600 Wi-Fi router, as captured by Wireshark 1.10.6 on an ancient EeePC with Ubuntu 14.04 (I have several newer options, including a Gazp9 with current Antergos and Wireshark 3.0.0 and an explicitly added monitor interface, but none of them will actually capture 802.11 in monitor mode):
-----
The "88:42" or 88:4a:3a:01:b4:ae packets are apparently an interpretation error:
Frame Control Field: 0x884a
.000 0001 0011 1010 = Duration: 314 microseconds: Data = 3a01
The last "b4:ae" is the beginning of Microsof_d1:66:5e (b4:ae:2b:d1:66:5e)
The packets seem to come from the Microsoft Surface Book...

Have been receiving data from wired DS (Wiznet) to Microsoft in this pattern, at 12, 24, or 72 Mb/S:
44275 20:43:26.264007 0.014939 88:42:30:00:b4:ae Microsof_d1:66:5e 802.11 811 QoS Data, SN=1655, FN=0, Flags=.p....F.
44276 20:43:26.264054 0.000047 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (RA) 802.11 28 Acknowledgement, Flags=........
44277 20:43:26.264787 0.000733 Microsof_d1:66:5e Wiznet_16:e2:a1 802.11 111 QoS Data, SN=226, FN=0, Flags=.p.....T
44278 20:43:26.265079 0.000292 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 46 802.11 Block Ack, Flags=........

Problem always begins with null function from Microsoft at 1 Mb/S:
44279 20:43:26.270868 0.005789 Microsof_d1:66:5e Tp-LinkT_ca:85:83 802.11 44 QoS Null function (No data), SN=3026, FN=0, Flags=...P...T
44280 20:43:26.271123 0.000255 Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 28 Acknowledgement, Flags=........

==> That Null Function includes:
---
IEEE 802.11 QoS Null function (No data), Flags: ...P...T
Frame Control Field: 0xc811
Flags: 0x11
.... ..01 = DS status: Frame from STA to DS via an AP (To DS: 1 From DS: 0)(0x1)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
==> ...1 .... = PWR MGT: STA will go to sleep <==
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
---

Then another data packet from DS at 13 Mb/S:
44281 20:43:26.279797 0.008674 88:42:30:00:b4:ae Microsof_d1:66:5e 802.11 471 QoS Data, SN=1656, FN=0, Flags=.p....F.

Which is repeated in 0.000658 second for no apparent reason:
44282 20:43:26.280455 0.000658 88:4a:30:00:b4:ae Microsof_d1:66:5e 802.11 471 QoS Data, SN=1656, FN=0, Flags=.p..R.F.

And the RTS storm begins - ten bursts of 12 RTS packets each:
44283 20:43:26.280813 0.000358 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 34 Request-to-send, Flags=........
(with a few beacons and things...)

--> Between each burst of RTS packets, the two DS packets repeat, with always the same sequence number and data, at 13, or 11, or mostly 1 Mb/S:
44296 20:43:26.290949 0.000598 88:42:75:00:b4:ae Microsof_d1:66:5e 802.11 468 QoS Data, SN=1656, FN=0, Flags=.p....F.
44296 20:43:26.290949 0.000598 88:42:75:00:b4:ae Microsof_d1:66:5e 802.11 468 QoS Data, SN=1656, FN=0, Flags=.p....F.

--> Beacons during the storm say "no data buffered", even though the AP is still trying to resend those two packets and is blocking lots more data from the Wiznet:
44385 20:43:26.389632 0.002386 Tp-LinkT_ca:85:83 Broadcast 802.11 280 Beacon frame, SN=1413, FN=0, Flags=........, BI=100, SSID=TP-LINK_2.4GHz_CA8583

Then five beacons over 0.25 second, three from active AP, two from its Guest SSID, all with "no data buffered".

And then another null function from Microsoft (delay from previous wake seems random, 200 - 500 mS):
44448 20:43:26.722968 0.029227 Microsof_d1:66:5e Tp-LinkT_ca:85:83 802.11 44 QoS Null function (No data), SN=3027, FN=0, Flags=.......T
==> With "PWR MGT: STA will stay up":

Then an ACK
44449 20:43:26.723253 0.000285 Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 28 Acknowledgement, Flags=........

And a block ACK request and response:
44450 20:43:26.723943 0.000690 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (RA) 802.11 38 802.11 Block Ack Req, Flags=........
44451 20:43:26.724390 0.000447 Microsof_d1:66:5e (b4:ae:2b:d1:66:5e) (TA) Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (RA) 802.11 46 802.11 Block Ack, Flags=........

Then finally back to Wiznet data at 1 Mb/S, though ACKs are at 24 or 72 Mb/S:
44452 20:43:26.725991 0.461204 Wiznet_16:e2:a1 Microsof_d1:66:5e 802.11 114 QoS Data, SN=1657, FN=0, Flags=.pm...F.

-----

In the middle of a constant stream of incoming data, the Windows machine decides to go to sleep and ignore dozens, sometimes hundreds of RTS packets. Until it seemingly randomly decides to wake up and continue...

Here's a Windows 7 machine (J3400) running jperf with a BBB wired to the TP-Link TL-WDR3600 Wi-Fi router:
-----
Continuous real data...
Then:
537964 16:26:43.736856 0.000516 J3400.local Tp-LinkT_ca:85:83 802.11 42 Null function (No data), SN=1142, FN=0, Flags=...P...T

ACK to the sleep notification...

Then 79 of these with no intervening activity:
537966 16:26:43.737657 0.000495 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) J3400.local (00:21:6a:74:c4:a4) (RA) 802.11 34 Request-to-send, Flags=........

A beacon, then:
538049 16:26:43.831115 0.007817 J3400.local Tp-LinkT_ca:85:83 802.11 42 Null function (No data), SN=1143, FN=0, Flags=.......T

And back to real data.
-----

Another point in that capture, this time with iperf:
-----
Find the BBB (TexasIns_4d:71:eb):
587582 16:28:46.811404 0.000924 J3400.local Broadcast ARP 78 Who has 10.1.1.4? Tell 10.1.1.100

A packet gets resent quickly for no obvious reason:
587597 16:28:46.814611 0.000462 J3400.local TexasIns_4d:71:eb 802.11 1566 Data, SN=2850, FN=0, Flags=.p.....T
587599 16:28:46.815021 0.000356 J3400.local TexasIns_4d:71:eb 802.11 1566 Data, SN=2850, FN=0, Flags=.p..R..T

Had been on 3490 SN values:
587661 16:28:46.825031 0.000057 TexasIns_4d:71:eb J3400.local 802.11 118 Data, SN=3494, FN=0, Flags=.p....F.
--> Why the retry on the next send, with different SN:
587667 16:28:46.826967 0.000020 TexasIns_4d:71:eb J3400.local 802.11 118 Data, SN=2753, FN=0, Flags=.p..R.F.
Stayed on 2700 values... It does seem to change SN randomly, where other machines roll over from 4096 to 1...

The problem:
635393 16:28:59.342407 0.000466 J3400.local Tp-LinkT_ca:85:83 802.11 42 Null function (No data), SN=1215, FN=0, Flags=...P...T

Then 175 of these with one beacon midway:
635395 16:28:59.342754 0.000043 Tp-LinkT_ca:85:83 (f8:1a:67:ca:85:83) (TA) J3400.local (00:21:6a:74:c4:a4) (RA) 802.11 34 Request-to-send, Flags=........

Ending with:
635571 16:28:59.408378 0.000567 J3400.local Tp-LinkT_ca:85:83 802.11 42 Null function (No data), SN=1222, FN=0, Flags=.......T
-----

I notice that when everything is idle, the Surface Book wakes up exactly every ten seconds to check for data. The gazp9 varies between 8 and 12 seconds, but averages ten. I've checked all the settings Windows gives me, WMM Power Save was "optimized", set it to "high performance" in DevMgr, and disabled packet coalescing - made no difference. In the TP-Link router, I tried disabling WMM, and setting RTS Threshold to 64 instead of 2346, didn't help.

The problem seems to be that Windows machines of any age and flavor with Wi-Fi from b to g to n to ac (but all of them tablet or ultraportable battery powered hardware) just arbitrarily go to sleep in the middle of maximum speed data transfers. I see lots of non-technical people saying their Surface Books have lousy Wi-Fi speeds, but nobody has dug deep enough to confirm they are seeing the same problem I have.

How can this be? Is there anything to be done about it? Is there more detail I should be analyzing? (Full .pcapng files are available if anyone is that interested... )

Loren

It sounds like you may some conflicted settings, between  WMM and/or Power Save, in your network. 

I have seen problems similar to this when my computer has had a very different DHCP lease time set on it compared to the ISP's address lease time - but not to such an extreme (more like every half hour).  Making sure my DHCP request was slightly less than the ISP's schedule fixed that problem.

Many years ago, I had a similar sounding problem when my D-Link AP was running way too hot in the summertime (in CA).   Opening up every-other politically correct childproof vent hole in its case, top and bottom, and orienting the case for good airflow fixed that problem too.

When you are running, do you know what rate your PC is "talking" with to the AP ?    Part of the problem here is that some Win drivers lie, and only report the maximum rate that the chip-set in it can run at - a BS marketing/sales gimmick I suppose.

Have you downloaded, and installed, the latest drivers for both the AP and the tablet ?

Have you tried running the dreaded "restore factory defaults" option on the AP ?  That can be painful, but sometimes a forgotten modification can come back to "byte" you (pun intended). 

Fantasizing now - you are not trying to run 802.11ac using less than "real"   WPA-2 security are you ? 

Back to the strictly Power save scenario's. Try this:

Turn   WMM    OFF  everywhere (every device client and AP) that you can you can.

Turn off any legacy Power Save options.

Forget the battery - plug the client into the wall power.

If this doesn't help, disable /ac on the AP and try just /g rates, single stream (20 HZ wide),   You are already getting such low throughput  I doubt this will hurt. 

Hopefully, something will make a difference.   Even if it's worse it should point you in the right direction.

Good luck. 

PS:  Another reason to try setting defaults is that manufacturers do not always test their configuration GUI's very well, and you may actually have a corrupted and invalid configuration in your AP, and not be able to "see" it from the GUI.   I'm in QA Test, and have literally seen this hundreds of times.

Again, good luck.

Let us know what happens. 

I just happened to wonder if you had Bluetooth enabled on the client.   If so, try disabling it and see what happens.

Some chip sets, drivers, and Apps are really naive and try to time-share the radio at stupid intervals.

Thanks Howard! Your replies are a big reason I decided to post here.

> I have seen problems similar to this when my computer has had a very different DHCP lease time set on it compared to the ISP's address lease time - but not to such an extreme (more like every half hour). Making sure my DHCP request was slightly less than the ISP's schedule fixed that problem.

Very strange! All of my machines receive reserved IPs from the router, but I guess that is still DHCP. But in the router it says lease time is "Permanent" for all the reserved machines. They wake and hibernate probably way more often than the WISP address renews - and the WISP address is a totally fixed IP that identifies my individual radio.

> Many years ago, I had a similar sounding problem when my D-Link AP was running way too hot in the summertime (in CA). Opening up every-other politically correct childproof vent hole in its case, top and bottom, and orienting the case for good airflow fixed that problem too.

I see the same problems winter or summer, on the TP-Link router, two different Linksys routers with Tomato firmware, some Ruckus commercial APs wired to my home Ethernet, and even my iPhone's "Personal Hotspot". Seems it has to be a Windows problem...

> When you are running, do you know what rate your PC is "talking" with to the AP ? Part of the problem here is that some Win drivers lie, and only report the maximum rate that the chip-set in it can run at - a BS marketing/sales gimmick I suppose.

According to Wireshark, actual data packets vary among 12, 24, and 72 Mb, that I've noticed. Overhead packets are often at 1 Mb. I'm curious if there is a pattern to the data speed, but I don't know any way to have Wireshark analyze that, and my brain isn't up to remembering rates and timestamps across ~100K packets.

> Have you downloaded, and installed, the latest drivers for both the AP and the tablet ?

The Win 10 Surface Book and the TP-Link router are up-to-date. Win XP and 7 are definitely not.

> Have you tried running the dreaded "restore factory defaults" option on the AP ? That can be painful, but sometimes a forgotten modification can come back to "byte" you (pun intended).

It was completely reset and new firmware adopted last October, when it replaced the Linksys as the primary route to the WISP network.

> Fantasizing now - you are not trying to run 802.11ac using less than "real" WPA-2 security are you ?

The TP-Link main channels (2.4 and 5) are definitely WPA2-Personal. It has a "Guest" account which is open - could that matter? (The bridged router out in my power shed can't seem to do the main security, so it connects to "Guest".)

> Back to the strictly Power save scenario's. Try this:
Turn WMM OFF everywhere (every device client and AP) that you can.
Turn off any legacy Power Save options.
Forget the battery - plug the client into the wall power.

In Win 10, the WMM-PS options are "Optimized" and "High Performance", and changing makes no difference. The only other option is "Packet Coalescing", and Enabled or Disabled makes no difference. I can't find any other controls for my card.

I turned WMM off in the TP-Link router many tests ago, made no difference.

If all the old Windows versions are completely powered off, their settings (if they even have them) shouldn't matter.

All tests have always been done with external power.

https://answers.microsoft.com/en-us/windows/forum/all/after-updating-windows-10-wifi-extremely-slow-how/6d4a8186-6813-49be-b833-19258bc3dbf4
My Windows "Location" is off.

https://msdn.microsoft.com/en-us/ie/ff553780(v=vs.94)
Wireshark shows Win 10 using QOS, Win XP and 7 not. The driver internals are beyond me...

I thought to check in Event Viewer...
Tons of these:
---
Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 0x02004C4F4F50. The following error occurred: 0x79.
---

Looks like the errors come in occasional bursts of a few dozen, once or twice a day, starting Jan 29 when I installed a new Wireshark and NPCAP:
---
The Npcap Packet Driver (NPCAP) service failed to start due to the following error:
The system cannot find the file specified.
---
Following a few hundred of those errors, the DHCP errors start. The NPCAP errors stop after that day, but the DHCP storms are still almost daily.

And I notice "Ethernet 3" showing in the system tray popup along with all the Wi-Fi listings. Never used to be there.
---
IPv6 DNS servers: fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Manufacturer: Microsoft
Description: Npcap Loopback Adapter
Driver version: 10.0.17134.1
Physical address (MAC): 02-00-4C-4F-4F-50
---
Why would a loopback adapter be requesting DHCP? Definitely shows as an error in the router logs!

There is no hardware connection on a Surface Book, only the one Wi-Fi adapter. Maybe all those other things are stubs in case somebody plugs in the USB to Ethernet dock? Which I've never had...
---
C:\Users\loren>ipconfig

Windows IP Configuration

Ethernet adapter Ethernet 3:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::653e:e510:e15c:f871%19
Autoconfiguration IPv4 Address. . : 169.254.248.113
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

Wireless LAN adapter Local Area Connection* 3:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Local Area Connection* 6:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::454a:31e9:829:acaf%23
IPv4 Address. . . . . . . . . . . : 10.1.1.10
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.1.1

Ethernet adapter Bluetooth Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

C:\Users\loren>
---
I just disabled Eth3 in Control Panel\Network and Internet\Network Connections. At least it isn't cluttering my Wi-Fi list now...

> If this doesn't help, disable /ac on the AP and try just /g rates, single stream (20 HZ wide), You are already getting such low throughput I doubt this will hurt.

Still the ten second chokes. And much lower throughput between them.

> I just happened to wonder if you had Bluetooth enabled on the client. If so, try disabling it and see what happens.
> Some chip sets, drivers, and Apps are really naive and try to time-share the radio at stupid intervals.

I turned off all the house Bluetooth, put my phone in Airplane Mode, disabled Bluetooth in the Surface Book, and removed the battery from its pen. Exact same ten-second chokes. (It does disconnect my mouse maddeningly often, and sometimes the keyboard as well, but the Wi-Fi speed is just as bad when I'm nowhere near the keyboard, mouse, or headset.)

> PS: Another reason to try setting defaults is that manufacturers do not always test their configuration GUI's very well, and you may actually have a corrupted and invalid configuration in your AP, and not be able to "see" it from the GUI. I'm in QA Test, and have literally seen this hundreds of times.

If the problem only showed on one router, I'd maybe spend the hours to try that. But I see the same problem on four different APs, and on my iPhone hotspot - they can't all be corrupt in the same ways! And I see it on three different Wi-Fi adapters of wildly different ages from different manufacturers. The only common factor is Windows! Linux can draw perfect throughput graphs, if all the Windows machines are off.

Do the 802.11 standards specify when a client can send that "PWR MGT: STA will go to sleep" flag? And how long they can stay asleep once they do? Is there some command that would prohibit going to sleep? At least when there is a solid 16 Mb/S data stream backed up and waiting?

Curiouser and curiouser ! 

Is there anyway you can update the drivers without updating the OS's ?  Check the chip set manufacturers site if you can.  Be sure to reboot after installing drivers.

Which channels are you using on your AP's ?   They should be set to STATIC, never automatic.

 Are the AP's  really dual radios, or do they only have one radio that uses one band at a time ?     A few years back, some mfg's were misleading customers in their marketing claims  - so that they could exhaust their supplies of single band-at-a-time devices .   What we want is dual channel & concurrent operation. 

What happens if you disable the bridge and only have one AP powered up ?  Be sure to disable the Guest SSID.

Is the DHCP server on the second AP disabled ?   You should have ONE, and only one,  DHCP server in your entire network.

You do realize that you have a big security hole by using the Open guest SSID,  right ?

When was the last time you ran a virus scan (e.g. the free version of Malware Bytes) on all your systems ? 

Did you run the Win10 router test mentioned in the link ?

Howard,

> Is there anyway you can update the drivers without updating the OS's ?  Check the chip set manufacturers site if you can.  Be sure to reboot after installing drivers.

It is a "Marvell AVASTAR Wireless-AC Network Controller". They don't seem to have anything useful:

https://www.marvell.com/support/downloads/search.do

DOS, WinNT, up to Vista...  And part numbers I don't recognize. Windows insists I have the best driver. I wish there was something like Tomato or DD-WRT for the STA side of the link! 

> Which channels are you using on your AP's ?   They should be set to STATIC, never automatic.

All static, to avoid stepping on each other. Ch. 11 for the TP-Link. 

> Are the AP's  really dual radios, or do they only have one radio that uses one band at a time ?     A few years back, some mfg's were misleading customers in their marketing claims  - so that they could exhaust their supplies of single band-at-a-time devices .   What we want is dual channel & concurrentoperation. 

I can definitely use 2.4 and 5 seemingly simultaneously. Never actually tried to prove whether they take turns or not...  But for all of the captured tests 5 is not used at all - my ancient capture tool doesn't do 5. 

> What happens if you disable the bridge and only have one AP powered up ?  Be sure to disable the Guest SSID.

That would have to wait for tomorrow. But I see the same problems with APs that don't have guest and don't know about the power shed bridge. On totally different channels. 

> Is the DHCP server on the second AP disabled ?   You should have ONE, and only one,  DHCP server in your entire network.

There is only the TP-Link in the main network. There is one Linksys that has its own separate WISP link and separate static IP WAN, so it has its own DHCP. And of course the iPhone hotspot has its own. 

> You do realize that you have a big security hole by using the Open guest SSID,  right ?

I'm off-grid, miles from the highway, and pretty much trust my neighbors. Who can't see my Wi-Fi anyway, unless they park in front of my house. 

> When was the last time you ran a virus scan (e.g. the free version of Malware Bytes) on all your systems ? 

Never. I let Windows Defender do its thing, but I burned out on virus scanners years ago. Yes, I know, I'm living dangerously. That's the least of it...  

> Did you run the Win10 router test mentioned in the link ?

No, not sure which you mean... 

Thanks for listening! Definitely time for YouTube and and a late snack...

Loren,

You said CH 11 for the TP LINK - What are ALL the other channels ?   

I've never been very happy with some chip manufacturers, as either a manufacturer's contact or as an end user.   The only allowance I will give them, and that  I appreciate, is that they don't want to be in the "help desk" business.  Unfortunately, the NDA's they offer sometimes make it impossible for a subordinate supply-chain company  to provide decent help.   Other drivers are available to WFA member companies, for use with the WFA test engine, but only from a single source.

HINT: Several years ago, you could download a driver meant for a "sniffer" program and use it for your everyday driver, giving you other controls - including dis-allowed channels, promiscuous mode, power level control, etc.  But as time went on, these options were either reduced or the sniffer drivers were modified so that they could ONLY work with the sniffer software.   It is, again, the case that some firmware can be put into a hardware manufacturer's  hidden "FCC Test" mode, but don't expect to ever be told how to do that.

I think you're down to the point of needing a real, multi-simultaneous-channel, wireless sniffer - i.e. something more than WireShark and your PC's chip set can provide.   I always preferred OmniPeek, but a much less expensive AirPcap/npcap dongle with Wireshark can work.  You want to be able to sniff ALL of the wireless traffic, not just the traffic on your network and all your  channels simultaneously.   OmniPeek had a couple ways of  doing that.   

I often ran four channels simultaneously with OmniPeek without any problem, and I've heard that the FBI runs dozens of channels simultaneously. 

BTW, it REALLY helps if you can use, or set up, a common NTP (Netwrok Time Protocol) server for all of the devices on your network, so that all of the log files across your network can be compared accurately.    It can be very enlightening to see how all of your devices interpret a particular packet.   From the discussion we've had so far, I'm sure you can manage it, if you want.

The test I was talking about was the first thing listed in that link you posted.  I'm pretty sure you have, but I wanted  to verify that.  It was:

a)       Press “Windows Logo  from the keyboard.

b)       Type “Troubleshooting” in the search bar and press “Enter”.

c)       In the “Troubleshooting” window, click on “View All” on the left pane.

d)       Click on “Network Adapter”.

e)       Click on “Advanced” and then click on “Run as Administrator”.

f)        Click “Next” and follow the on-screen instructions to complete the troubleshooting process.

Don't start feeling too secure.   I once got a demonstration of an antenna that could pick up Wi-Fi from more than a mile away, in a situation much like yours.  The fact that a transmitter is remote to others actually makes it easier to snoop.

Best of luck.   

Loren,

A whole other train of thought here:

Are you using any  USB 3.0 devices anywhere in your network ?

                                              OR

Are you using any external disk drives with your Apple computers ?  Might be a more important question than you'd first think.

> You said CH 11 for the TP LINK - What are ALL the other channels ?

Right now the Linksys is the only other full-time AP, and it is on Channel 6. The power shed bridge follows the TP-Link wherever it is.

Wireless Site Survey (tabs are a mess)
SSID BSSID RSSI Noise Quality { Ch } Capabilities Rates

Talisman 00:14:BF:05:4A:50 -61 dBm -95 dBm 34 { 6 } infra shortslot 1,2,5.5,11 6,9,12,18,24,36,48,54

TP-LINK_2.4GHz_CA8583 F8:1A:67:CA:85:83 -21 dBm -98 dBm 77 { 11 } infra wep shortpre
shortslot 1,2,5.5,11 6,9,12,18,24,36,48,54

GCA8583 FE:1A:67:CA:85:83 -21 dBm -98 dBm 77 { 11 } infra shortpre shortslot 1,2,5.5,11
6,9,12,18,24,36,48,54

> HINT: Several years ago, you could download a driver meant for a "sniffer" program and use it for your everyday driver, giving you other controls - including dis-allowed channels, promiscuous mode, power level control, etc.

I wish!

> I think you're down to the point of needing a real, multi-simultaneous-channel, wireless sniffer - i.e. something more than WireShark and your PC's chip set can provide.

Maybe that's my next toy purchase. I think just Wireshark 3 might help, if I could get it to monitor mode... See my bug at:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15652

> BTW, it REALLY helps if you can use, or set up, a common NTP (Netwrok Time Protocol) server for all of the devices on your network, so that all of the log files across your network can be compared accurately.

All machines sync to the same NTP server. I wish iperf would use NTP time for its displays! That's what I've been using for test data.

> The test I was talking about was the first thing listed in that link you posted. I'm pretty sure you have, but I wanted to verify that.

I'd run it, but Windows 10 doesn't offer the admin route. Last night I discovered:
https://www.thewindowsclub.com/how-to-run-a-troubleshooter-from-the-command-line-in-windows-10
and the command:
msdt.exe /id NetworkDiagnosticsNetworkAdapter
which you can run in admin PowerShell. Same result - couldn't find a problem.

But if you dig in the xml files it makes, there's a place where it says "There may be problem", with no clue I can see to what problem they might refer to. Just long lists of all the cryptic ID info from the Device Manager details tab.

> Don't start feeling too secure. I once got a demonstration of an antenna that could pick up Wi-Fi from more than a mile away, in a situation much like yours.

My first venture beyond ISDN was a Ruckus beamforming relay device mounted in the focus of an old DSS sat dish and pointed at a guy with a regular home router and a T1, over three miles away. (With his permission, of course.) Totally worked!

> Are you using any USB 3.0 devices anywhere in your network ?

Lots of USB 3 ports here, but nothing ever plugged into any of them, except when I take my backup drives out of the fire safe and update them.

> Are you using any external disk drives with your Apple computers ? Might be a more important question than you'd first think.

No actual computers from Apple, just the iPhone.

But if we're getting that paranoid, how about the 1600W of solar that snakes through the house, about 4' from the TP-Link at one point, on its way to the MPPT in the power shed?

Or, OMG - how about this? The ancient microcomputer that controls the house reads a dozen 1-Wire temperature sensors spread all over the house, on a ten-second cycle! Every ten seconds it updates the status of all the dozens of pumps and motors and valves from roof to crawl space to the garden. But most cycles nothing changes. It reads a different sensor every second, but the signal goes to all of them on the same bus so there should be no change in the radiated effect.

It is wired to the Wiznet adapter that leads to the TP-Link. And it has a Bluetooth adapter in its other serial port. It has its own UPS battery system, fed from the same DC that runs the TP-Link but via an isolated DC-DC converter. Pretty incestuous...

And if you want to get really spooky, the wilderness behind me is a "Military Operations Area" on all the aircraft maps. Nobody knows why...

But this network problem is constant, and only on Windows. I sniffed the Linux box doing iperf with no Windows machine awake, and it was perfect - never once set the power flag until the test was done. Only Windows insists on setting the power flag in the middle of maximum data flow.

Since I don't believe in coincidences...  I'd have to say you found the culprit behind your ten second network hiccup.

There should be a simple test to see if it's the cause - change your 10 minute sample period to 30 minutes for a couple of days.

In addition, some solar system gear is notorious for creating RF interference, both radiated and conducted (over the cabling).  Have you checked that out ?

There is a new book out, called Energy Choices for the Radio Amateur.     I just got a copy, and have found it very interesting.  Ham radio operators can get a $5 discount on the ARRL website too.

I am really interested in your solar setup.   I have a small amount of yard, and roof space, that I have been contemplating dedicating to a solar system.