> 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)

> 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.