Hacker News Reader

Comment by 404mm | Hacker News Reader

This is very similar to an issue I battled for months on MacBook Pro (one of the later Intel versions, like 2018-ish), although there problem was not in the HW itself but the current version of MacOS at that time (this is no longer an issue).

I noticed that my WiFi had similar repeating lags .. about every 8-10s pings would go to a few hundred ms and then return to single/low double digits.

Long story short, the problem was with several MacOS components (and maybe some 3rd party software) requesting Location services to determine Mac’s position. 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. The solution was to minimize location services.

View on HN

This is a great example of good ideas destroying themselves. "Software should occasionally be able to find out where the computer it is on physically is" is a cool idea, but once it's there every single piece of crapware out there does it constantly.

See also desktop notifications for websites

There's a big difference there.

You install an application you are giving it permission to do practically anything it wants to do with your system, including find the location as often as it wants to.

Browsers have to ask you permission to show desktop notifications, or get your location, or anything else.

> You install an application you are giving it permission to do practically anything it wants to do with your system

Not on macOS, AFAIK. You can add/remove permissions for that.

This is a more recent feature. I’m not sure if such granular permissions were in macOS back in 2020 when this blog post was written.

Even when you have granular permissions, though, it just means the negative UX of having to click "no" every three minutes because some jackass at Adobe is convinced you really want to be told RIGHT NOW about every single product they make (or whatever).

The authorisation prompt doesn't show up once you denied. Which makes sense to avoid user fatigue, but is annoying when users denied it the first time (aka "go away stupid modal dialog") and now complain about things working (or not) as designed. At some point operating systems and browsers will have to run a simulation to provide realistic fake responses from denied subsystems if application developers get even more brazen violating user interests and maybe even *locally* analyse API call patterns for abuse with the option of sending a trace to make a claim against the developer with the application distribution channel. Oh you added a bunch of criminal spyware libraries praying on your paying users? Guess that's a push notification to your whole install base offering them a refund and a ban on further sales until you've paid up. Except no existing player wields that much power and can be trusted to use it wisely. sigh

I think they should (permission allowing) be able to ask for location, as often as they like.

I pin the system disruption from this query squarely on the OS. It should make such determinations in the background and return whatever value it has, without starting up a new scan just for this query.

> 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

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

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

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

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

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.

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

>and to do that, the current WIFI connection is temporarily put on a back burner, resulting in a brief delay in traffic.

I can't believe they ever thought that'd be a good idea.

Probably have to sweep across the frequency bands, so it's physically the only way to do it. Still stupid to do it more than once every 15 minutes

Fast switching on a background schedule while packets continue to flow but at slightly reduced rate should be possible. Might be very export controlled though given obvious application.

You mean the RF circuitry has to continue working in the frequency of the current network and switch frequencies to scan for other networks in all bands simultabeously? I don't think consumer hardware is capable of that. It usually will send probes or listen passively for some time in a band before moving to the next one sequentially. It's an expensive operation.

I'm not an expert but I think depending on design this is sacrificing one MIMO channel when active and adding another PLL.

It is more insidious to scan all the SSIDs within the RF sightline of a device than it is to install a GNSS receiver in the laptop. It means that not only do they get all the SSIDs but that they have also triangulated some of those SSIDs. You are also giving up the location privacy of everything you can see.

That's not the only way if you are the one designing the hardware. Even if you can't make a radio that can listen on multiple bands, you can add a second radio.

Oh there is an obviously correct way to do it: have two radios able to switch channels with without impacting traffic, but that costs more money as well as space and power. No lets just retrofit this crap into existing drivers and hope nobody expects their computer to work reliably.

This plagued a lot of remote workers when the trend started due to ping latency causing terrible VC quality like delayed speech , dropped frames, out-of-order frames . Very frustrating.

In recent times, I found 2 troublesome issues: one was network-side and another was client-side.

1. Google/Nest WiFi mesh APs being "too close" to each other (30 ft / 10 m), causing a periodic backhaul mesh collapse. There was no user-visible indication of this, it was completely locked away and only noticed by support. I ditched Google's junk and moved to Ubiquiti.

2. On macOS, ObjectiveSee's LuLu has nondeterministic packet loss that causes SSH connection resets and a whole host of other weird problems. It's totally untrustworthy and shouldn't be used by anyone until it's proven reliable.

Packet loss is supposed to be deterministic?

Reminded of https://mnpn.dev/blog/airplay-network-disaster, which was a very similar issue (now resolved).

Reply on news.ycombinator.com