3 ms·

> To do that, among other things, Mac scans WiFi around you (probably for the names/SSID?) and to do that, the current WIFI connection is temporarily put on a b

> To do that, among other things, Mac scans WiFi around you (probably for the names/SSID?) and to do that, the current WIFI connection is temporarily put on a back burner, resulting in a brief delay in traffic. Scanning for nearby WiFi access points with excessive frequency might be a dumb idea for other reasons (e.g. power consumption) but it should *not* interrupt the functionality of the current network connection. If it does, that's a massive failure of the network card's firmware and/or OS drivers for it. My guess would be that the card is changing frequencies/bands to scan other channels, and is slow to switch back to the channel of the currently-associated AP, or doesn't properly buffer network packets while doing so. Under Linux, I don't think I've ever seen a case where WiFi scans appreciably affected a normal infrastructure-mode WiFi connection (whether from NetworkManager or triggered manually via `iw` etc). So much for Apple's vaunted hardware/software integration

vel0city 2y ago
I've seen a lot of people experience lag spikes in Linux when software scans for SSIDs. It's a pretty common issue overall regardless of the OS, it's more of a device and driver quality question. https://www.reddit.com/r/linux_gaming/comments/3xipom/how_to_eliminate_ping_spikes/ https://www.reddit.com/r/linux_gaming/comments/3xipom/how_to...
- dlenski 2y ago
  > It's a pretty common issue overall regardless of the OS, it's more of a device and driver quality question. Right. I suppose I've been both lucky, as well as intentional in seeking out hardware with high-quality drivers when it was very important. I'm just surprised that *Macs* have this issue, given that one of the alleged selling points for Mac is that it runs on a very limited set of hardware which is supposed to enable careful OS/hardware integration and testing.
dehrmann 2y ago
> Scanning for nearby WiFi access points with excessive frequency might be a dumb idea for other reasons (e.g. power consumption) but it should not interrupt the functionality of the current network connection. Scanning works by tuning the radio to listen for a beacon sent by the AP every ~100ms on every channel (there are 11 2.4 GHz and ~22 5 GHz channels in the US). Since you're not transmitting, it should be low-power, but you have to tune the radio to each channel, so you can't communicate with your AP.
- dlenski 2y ago
  > Scanning works by tuning the radio to listen for a beacon sent by the AP every ~100ms on every channel (there are 11 2.4 GHz and ~22 5 GHz channels in the US). Yes, but good drivers can mitigate the latency hit by not scanning all the channels at once. https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/#:~:text=With%20a%20good%20driver%20scanning%20takes%20only%20a%20few%20seconds%20and%20the%20driver%20breaks%20the%20scan%20into%20chunks%2C%20returning%20to%20the%20associated%20access%20point%E2%80%99s%20channel%20periodically%20to%20handle%20pending%20traffic https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-w.... > Since you're not transmitting, it should be low-power, Depending on the hardware/firmware quality, tuning to each channel can use a lot of energy. As for "not transmitting," this is true for passive scanning (generally preferable) but not for active scanning. > but you have to tune the radio to each channel, so you can't communicate with your AP. Right, but _if the OS and drivers are written properly_ (on both the client device as well as the AP ) they'll buffer unsent packets… the high latency during the channel changes is unavoidable, but the dropped packets and broken TCP streams are NOT.
  - vel0city 2y ago
    From your quote: > With a good driver scanning takes only a few seconds A few seconds of not transmitting or receiving packets. This is in line with people having sudden several hundred millisecond ping spikes. A few seconds of no real traffic is absolutely noticeable impact for constant, latency sensitive traffic.
    - dlenski 2y ago
      > From your quote: > > With a good driver scanning takes only a few seconds You omitted the immediately following text: "*and the driver breaks the scan into chunks*, returning to the associated access point’s channel periodically to handle pending traffic." A good driver will return to the AP's channel _during the scan_ so that there is never more than (say) 100 ms of latency even while the scan is ongoing.

vel0city 2y ago

I've seen a lot of people experience lag spikes in Linux when software scans for SSIDs. It's a pretty common issue overall regardless of the OS, it's more of a device and driver quality question. https://www.reddit.com/r/linux_gaming/comments/3xipom/how_to_eliminate_ping_spikes/ https://www.reddit.com/r/linux_gaming/comments/3xipom/how_to...

dlenski 2y ago
> It's a pretty common issue overall regardless of the OS, it's more of a device and driver quality question. Right. I suppose I've been both lucky, as well as intentional in seeking out hardware with high-quality drivers when it was very important. I'm just surprised that *Macs* have this issue, given that one of the alleged selling points for Mac is that it runs on a very limited set of hardware which is supposed to enable careful OS/hardware integration and testing.

dehrmann 2y ago

> Scanning for nearby WiFi access points with excessive frequency might be a dumb idea for other reasons (e.g. power consumption) but it should not interrupt the functionality of the current network connection. Scanning works by tuning the radio to listen for a beacon sent by the AP every ~100ms on every channel (there are 11 2.4 GHz and ~22 5 GHz channels in the US). Since you're not transmitting, it should be low-power, but you have to tune the radio to each channel, so you can't communicate with your AP.

dlenski 2y ago
> Scanning works by tuning the radio to listen for a beacon sent by the AP every ~100ms on every channel (there are 11 2.4 GHz and ~22 5 GHz channels in the US). Yes, but good drivers can mitigate the latency hit by not scanning all the channels at once. https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-wifi-scans/#:~:text=With%20a%20good%20driver%20scanning%20takes%20only%20a%20few%20seconds%20and%20the%20driver%20breaks%20the%20scan%20into%20chunks%2C%20returning%20to%20the%20associated%20access%20point%E2%80%99s%20channel%20periodically%20to%20handle%20pending%20traffic https://blogs.gnome.org/dcbw/2016/05/16/networkmanager-and-w.... > Since you're not transmitting, it should be low-power, Depending on the hardware/firmware quality, tuning to each channel can use a lot of energy. As for "not transmitting," this is true for passive scanning (generally preferable) but not for active scanning. > but you have to tune the radio to each channel, so you can't communicate with your AP. Right, but _if the OS and drivers are written properly_ (on both the client device as well as the AP ) they'll buffer unsent packets… the high latency during the channel changes is unavoidable, but the dropped packets and broken TCP streams are NOT.
- vel0city 2y ago
  From your quote: > With a good driver scanning takes only a few seconds A few seconds of not transmitting or receiving packets. This is in line with people having sudden several hundred millisecond ping spikes. A few seconds of no real traffic is absolutely noticeable impact for constant, latency sensitive traffic.
  - dlenski 2y ago
    > From your quote: > > With a good driver scanning takes only a few seconds You omitted the immediately following text: "*and the driver breaks the scan into chunks*, returning to the associated access point’s channel periodically to handle pending traffic." A good driver will return to the AP's channel _during the scan_ so that there is never more than (say) 100 ms of latency even while the scan is ongoing.