Let me jump in and add a bit more information.
I am not an RF guy - I stopped playing with radios [and TV] in the days
when they used vacuum tubes (yes, really.)
Many laptops share radio and antenna resources between WiFi and bluetooth.
Bluetooth lives on the 2.4ghz band. Wifi presently uses both that band
and also a 5ghz band. Different antennas might be used for each.
I encountered Wi-Fi/Bluetooth contention issues a couple of years back....
My home wifi has (or rather had) distinct SSIDs for Wifi on the 2.4 and
5ghz bands. It was a rough attempt at manual load and distance balancing.
(Our house is in a relatively quiet area, RF wise, so there's not really
any seriously competing wi-fi - or for that matter cell signal,
broadcast TV, or FM radio.)
I began to notice that when I had one of my laptops on the 5ghz WiFi and
was listening to music via some bluetooth speakers that my remote
terminal keystrokes sometimes had that sluggish feel that is familiar
when doing remote terminal command-line stuff over long paths with a lot
of latency/jitter. And at the same time the music via Bluetooth often
broke up or stuttered. There was a clear correlation between the two
problems.
I had heard from some Linux kernel developers that deep down in the
Linux kernel the simultaneous use of Wifi on a 5ghz channel and
bluetooth on 2.4 causes a lot of thrashing and flogging of the the radio
system. I don't know, but I suspect that as a result there are queues
of outbound traffic waiting for the radio or antennas to become
operational on the channel they need. I have no idea what happens to
inbound frames when the radio system is tuned elsewhere - I never
measured whether the frames are lost or delayed.
I suspect similar issues are present in *BSD, MacOS, and Windows kernels.
So I did some simple empirical testing to compare life with the laptop
coerced to use an SSID present only on the 2.4ghz band. The problems
went away.
I went back to the laptop, but coerced onto the 5ghz band for WiFi and,
voila, there was trouble.
I've done this with a MacBook Pro (circa 2015 model) using various
versions of MacOS and with my rather newer Linux laptops (mostly Dell
XPS units with Fedora.) Same sorts of behavior.
These were all i5 based units with 2 or 4 cores - plenty of CPU power to
simultaneously handle an SSH remote console client and a music player.
I did not test with mobile phone or tablet platforms.
I do not know if the single radio issue is the result of cost savings or
some radio-engineering or antenna issue. I do suspect that these things
could become more troublesome as WiFi 6 and/or 5G start to use some of
the higher frequency allocations around 5.9 and 6ghz.)
(A few weeks ago we switched our home WiFi to a WiFi 6 [Netgear Orbi-6]
mesh system that does not appear to allow separate SSIDs for the 2.4 and
5ghz bands, so I can not repeat these tests without constructing a test
network with the now unused access points. BTW, I did encounter the
hell that is known as "reconfiguring dozens upon dozens of different
kinds of IoT devices to use a different SSID".)
Looking somewhat off topic - it is my sense that we will be seeing a lot
more latency/jitter (and packet resequencing) issues in the future as
radio systems become more agile and as we begin to use shorter
(millimeter) wavelength frequencies with reduced ability to penetrate
walls that, in turn, cause more frequent access-point transitions (with
possibly distinctly different backhaul characteristics). I've observed
that these things can cause trouble for some TCP stacks and some non-TCP
based VoIP and streaming applications.
--karl--
On 10/30/20 12:08 PM, Mark Tinka wrote:
Hi all.
So I may have fixed this for my end, and hopefully others may be able
to use the same fix.
After a tip from Karl Auerbach and this link:
https://developer.apple.com/forums/thread/97805
... I was able to fix the problem by disabling Bluetooth.