I noticed this too when I used steam to stream a game to my laptop over good wifi. Every minute it would stutter for a second. I set up iperf3 tests and noticed the wifi lag increasing every minute between my macbook and my server and between my windows desktop pc and my server (when connected over wifi). Of course no lag when using cables, so I reasoned it was wifi related, and had noting to do with my setup (I used different clients, and different AP's). I then took my macbook (only portable computer I had) it too a nearby coffee shop with good wifi and I could still measure lag spikes every minute. So then I was really puzzled, was there some rogue device interfering with wifi all over the neighborhood? Finally I found a suggestion to turn off location services (or whatever it is called), and the spikes disappeared. And I learnt that even when it is not used (not sure it the lid was closed) a macbook can cause significant interference to the wifi for all other nearby devices.
> And I learnt that even when it is not used (not sure it the lid was closed) a macbook can cause significant interference to the wifi for all other nearby devices.
My partner has an older MBP, I noticed this the last time she was forced to updated her OS a major version... the thing no longer sleeps when you tell it to or when you close the lid, it will stay connected to wifi and quite happily saturate the network downloading updates.
Only way to be sure is to power off the stupid thing.
"Do not leave XPS laptop in any sleep/hibernate/standby mode when placed in a bag" because they stay connected to wifi and may attempt to run updates etc when the user is not expecting or prepared for that, as far as cooling.
Yeah it might be unwanted behavior for your particular setup. Personally, on macOS and windows, I would prefer not to be at the computer when an update occurs - I also dont want to have to go do something else while I wait for the update. Just feels like a waste of time in my opinion. However, if I had reason to care about an update or the changes it was introducing I too would not want background updates running when I put my machine to sleep. I guess for an average user updating when the machine is not in use is a feature, while for the tech crowd that kind of behavior can mess with your preferred setup.
Running updates are only a problem on Mac or Windows. Updates on the different linux flavors I’ve used take fractions of the time, are unobtrusive (I can continue to do work), and as a bonus, never fail to make my aging self feel like a technoir hacker with all that rapidly scrolling text. It’s all whole different ball game.
Different user groups, different priorities. I had a colleague who was a seasoned C hacker and long-time Linux user (but not someone who'd be very interested in how a Linux distribution or package manager works). Their Ubuntu system indicated that there were updates. So, they started the update. However, it was taking too much time and they wanted to go home, so they shut down the machine during the update. Unfortunately, it left the system in a bad, (IIRC) unbootable state and the local sysadmin had to spend an hour to get the system in a consistent state again.
Is it reasonable to expect that you can just yank the chord during an upgrade? Maybe, maybe not. But users have the expectation that it is ok, there can be a power interruption after all.
This would never happen with a macOS update, which uses an immutable root file system and APFS containers to switch the root after an update. Or an OSTree system like Silverblue, Fedora IOT, or Fedore CoreOS. Traditional Linux packages fall flat on their face in such scenarios (unless you use a lot of band-aid like filesystem snapshots, set up GRUB to handle boot into the right snapshot, etc.)
I think it is uncharitable to assume that the people making macOS (or Windows) update are incompetent. They may just have a different set of requirements and constraints.
> This would never happen with a macOS update, which uses an immutable root file system and APFS containers to switch the root after an update.
There are still things that cannot be interrupted like flashing firmware blobs, on many devices. Before apple distributed updates using FS snapshots they would reboot the machine first and block the user with a message that it cannot be interrupted.
It's also not a completely free or well implemented solution because (even as an x-apple user) I am made patently aware of just how absurdly huge their updates are, even for the smallest patch... incremental distribution and immutable FS based updates are not fundamentally incompatible, so I guess Apple simply doesn't respect user's bandwidth or assumes all of their customers have gigabit downlinks for the exclusive use of Apple devices.
That’s a good story. I thought apt can usually recover from incomplete updates, but maybe it was in the middle of a kernel or bootloader update or something when power got killed.
Sure you can have data loss. But we were talking about updates. Most image-based systems do not update in-place, but write the updated system first and flip the switch atomically when the update is successful. macOS 11 and later cryptographically verify the new on-disk system volume and boot into the old system if the verification fails:
SSV not only helps prevent tampering with any Apple software that’s part of the operating system, it also makes macOS software update more reliable and much safer. And because SSV uses APFS (Apple File System) snapshots, if an update can’t be performed, the old system version can be restored without re-installation.
I always assumed it was smart enough though not to do it when it's on battery as it is very likely that the device is also in a confined space, such as a laptop backpack waiting for the trip to the office next morning.
If I have it sitting on power and thus likely just on the top of the table and I have auto-updates on, sure do them when I'm not around as long as they are updates that can run unattended. Note the "if auto-updates are on" part, which luckily you can still disable on MacOS.
people on linux wait for updates? i thought that was a thing only for mac and windows... never noticed or seen a update screen on linux unlike the Windows nightmare where it would even kick you out of your work to do a damn update
Yes, Fedora downloads packages first and then reboots the machine to perform the actual updates and then reboots again into the updated system [1]. You can still run dnf update manually, but the recommended path is the former one. Why? Because in contrast to what many commenters say here, in-place updates of Linux systems can go wrong. Apparently, Fedora have encountered this often enough that they they have started doing 'offline updates'.
(The proper solution, which Silverblue/Fedora IoT/Fedora coreOS/NixOS/GUIX do is to make system updates atomic with roll-back.)
just checked how Fedora does it... it just downloads the updates and when you shutdown it installs them for you before it finally shuts down, doesn't seem as bad and not how you said it was.
The system update mode is implemented by booting into a special target. The target installs the downloaded updates and then reboots back into the regular default target.
You can also see the process in the video on the end of this page:
You can see that after choosing to install the updates, the system reboots. Then it uses systemd functionality to switch into a special update target. Then it reboots again to boot into the updated system.
Finally, also see the article that I linked in the earlier post:
The process of restarting, applying updates, and then restarting again is called Offline Updates. Your computer boots into a special save-mode, where all other systems are disabled and where network access is unavailable. It then applies the updates and restarts.
I am currently using Fedora headless. But the last time I used Fedora on the desktop (~a year ago), I am pretty sure it still did the reboot-update-reboot dance. The exception to this is Fedora Silverblue, which downloads a new system image and then boots into that in a single boot.
I have had this issue with Thinkpads as well. The solution was to make sure to unplug the AC power adapter before putting it to sleep and putting it in my bag. Else it would go to sleep thinking that it's still on AC power, and happily wake itself up to install updates while in my bag. If power was disconnected after putting it to sleep, it would not be able to know it was on battery power.
Dunno if the new MacBook Pro M1 Pro / Max are more thermally efficient or that they don't start back up in a bag but I've left mine in sleep in a sealed bag and it wasn't warm to the touch at all.
Yesterday my home DNS weren't resolving and noticed on PiHole that there were >30,000 requests of *.in-addr.arpa (Reverse DNS Lookup) from the iPhone+iPad of the guest to whom I gave the WiFi access and was saturating the Pi's CPU. I re-enabled rate limiting on PiHole and blocked the request with a filter.
A cursory search on the issue says Bonjour is the culprit, I'm forwarding DNS requests to my PiHole instances on my gateway and latest iOS doesn't seem to like it; I haven't faced such issue earlier and I have this setup for several years now.
“pmset -g assertions” will show you why it thinks it’s awake, it could be a silent video playing in a web browser or something. (and of course, if you can ssh in to run that it must be awake.)
they already mentioned why it was awake: downloading updates.
...which it only does when connected to power so I'm honestly failing to understand what the problem may be. Anyway: Settings -> Software updates -> Advanced -> Download new updates when available -> uncheck.
For everything else: Battery -> Power adaptor -> Wake for network access -> uncheck (may also take care of the above, dunno)
For extra fun, if while it's sleeping it's connected to a Display Port or USB-C display, it'll wake it up everytime it wakes the wifi for its 'power naps'. Disabling them in System Prefs doesn't change this.
Can confirm that the scripts posted itt by vJan00 [0] solved the stuttering problems that were plaguing me 4-5 months ago. Didn't bother setting up a cronjob; I just toggle it on/off as needed.
Wow, I guess this is also why my local steam streaming (well, I use Moonlight but same difference) started lagging out of nowhere. I first noticed it 2 days ago, but before that I clocked 30 hours no problem, so I guess this is a brand new problem.
Gonna try turning off all my Mac devices location services, thanks for the tip.
This was a few years ago on a 2015 MBP running Catalina or whatever came before that. My guess is the adaptive bandwidth algorithm acutely switches to a lower bandwidth due to the lag spike, and then slowly recovers in the ten seconds after. And then 50 seconds later it starts over again. I suspect if I could have manually set the streaming quality to a fixed value the lag spike would hardly not be noticable at all, but the constant switching of the stream quality is what actually caused chopiness. Same might be the case with the OP's zoom calls
if you have the wherewithal to use iperf then why not wireshark too? it's probably actively sniffing surrounding wifi frames to feed back to its proprietary version of WiGLE.net under the guise of super helpful "location based services"
This is normal across all wifi clients; they can't scan for networks and transfer data simultaneously so there will always be increased latency during that event. You can test this yourself by doing a low-interval ping and clicking the wifi icon to show you nearby networks - you'll notice a brief latency spike.
I agree that it's not a good default to have an app doing this, though.
This may not always be the case, fortunately! I recall the Broadcom Wi-Fi 7 chipset announcement[0] in April mentioned a dedicated scan core which may well offload the network searches to a separate part of the chip, freeing the AP connectivity core(s) from having to do other tasks for a second or two each minute.
Here's hoping it works as I understand it and other chipsets start doing similar things!
Supporting 802.11g means scans are send at 1Mbit. 802.11a bumps it to 6Mb/s, so not much better. This means that every time you want to send a beacon you have a pause equal to the duration it takes to send a packed at 1-6Mbit, not to mention scanning all the channels.
On different bands you can with basic filters. On the same band it would admittedly be tough (unless the band is super wide like the 6E band). It is done by radio repeaters for example but they do need big bulky filters, that kind of thing would not work on a laptop. But it is possible to transmit and receive on the same antenna at the same time, it's not a technical limitation. You just need a good enough filter.
I used to have constant ping spike at regular interval and had to do that bat script thing, which fixed it but it was really annoying. Eventually I figured out it was because of a Qt bug in the Qt lib that an application running in the background is using, and there is a system property to disable that behavior.
Thank you, this solved a problem I was having with Citrix Workspace. Every ten seconds I would get a ping spike. It reliably destroyed video calls and made typing in the workplace a pain.
My old Mac does not have this problem. Makes no sense to me that Windows allows any random program to trigger wifi scans. It’s a performance issue and privacy issue too.
It’s good to know. I suppose the unintuitive part is that “location” means “Wi-Fi scan”. Makes sense for a laptop when you think about it but I wouldn’t have thought of this as the first thing to check.
It's kind of a weird situation we're in with this. Facebook and Google track your location by default and you can go back and look where you've been on a map. I used it to figure out the details of an automated traffic ticket I got on a trip to Europe a couple of years back, so it's not totally useless from a consumer perspective, but it's still creepy. So you opt out, but "location services" keeps tracking you and sending your location data (as represented by the SSIDs and signal strength around you) but not telling you you're being tracked. So you opt out of that, and all the sudden you're subject to a bunch of dark patterns insisting you need to enable it again, even though it's perfectly capable of just using the GPS and keeping everything on the client. I'm glad my life isn't interesting enough for it to matter, I guess.
> the unintuitive part is that “location” means “Wi-Fi scan”
I was under the impression that this has been SOP for mobile device location forever: get rough location via WiFi and/or tower multilateration while GPS is...I don't know the proper terminology here, bootstrapping? That's why your dot tends to start somewhere nearby-ish and then quicky jump to your exact location.
It's possible that I'm way off base or my understanding is outdated, though.
I'm thinking that my devices could have an offline list of known WiFi mac-addresses from when it's checked GPS before and return those for very accurate results without scanning anything.
But if the laptop is currently connected to a WiFi network with a known location, what's the point of scanning for networks to locate it? You already know that you're within range of a known spot.
Roaming. Although a desktop might not usually be moving while it's on, a laptop user might move around the house, conference room, or lecture hall, and switching APs could result in a stronger signal. It's better to switch before your signal gets weak/drops to minimize disruptions during BSS transitions.
On an unrelated note, in my experience Apple devices are consistently the most frustrating devices when it comes to wifi. They are insanely picky about what networks they will connect to, and they are never consistent.
„Within range of one network“ doesn‘t give you as much information as „all these networks are visible and here‘s how strong they look from where you are“
True, but is that precision worth the hit to latency... especially if you're trying to do a voice and/or video call? I doubt it's worth the tradeoff most of the time.
> opening up the WiFi connections list to hunt for other networks?
That's not the trigger. The trigger is location services scanning for networks in the background. So, if you have that enabled then it happens automatically while you're on a call.
Not just within range, connected to. Meaning you're close enough to have a strong signal. If it isn't a strong signal this can be detected and the system could scan in that case, looking for a better one.
What helped me was not using a hidden SSID. Apparently, with hidden networks, the computer has to actively probe for the network, but passive probes don't affect latency as much.
It happens to me when using Ubiquiti UniFi access points, but not as much with other brands of APs. In fact, certain models of UI APs seem to be more problematic when used with newer Macs.
I discovered this exact problem over lock down 2020. My Teams calls would freeze every 60s.
There's a better solution though! Delete all your saved wifi connections. All those hotels and coffee shops you have connected to in your apple lifetime are the trigger. Reduce them down to those you actually use and the problem goes away.
I'm amazed more people haven't come across this, though from what I've seen people tend to just live with these problems as they don't know where to start in figuring it out.
On Windows, there was an infamous Qt bug that also caused regular ping spike, so check it out if you have the issue and you also happen to be using a Qt program:
I wonder why they keep rescanning the wifi environment even though the fact that it remains connected to the same BSSID and the RSSI doesn’t fluctuate too much should suggest that it’s very unlikely the device moved far enough to warrant another scan.
My anecdotal experience (partially informed by working on the Windows Wi-Fi team) is that iOS/macOS are more aggressive about switching APs. It's a tradeoff - on one hand, you can have disruptive scans like this, but on the other, if it results in switching to a better network during a long period when the user is stationary, it can result in a better experience.
It also depends a lot on what your hardware is, whether you're doing a full scan or a partial scan, whether you have more than one NIC etc, etc.
Video calls aren't hyper latency sensitive, there is already a lot of latency in encoding and processing effects. I'd imagine this could be most disruptive to video games but this isn't a market Apple has done much to work with.
Maybe it wasn’t a problem worth fixing at the time? Maybe they’ll do exactly this in future versions of the location finder stack.
Edit: somebody pointed out that these scans could be for roaming purposes as well. Maybe there is another access point with a better signal and it’s time to move?
You're forgetting how sensitive this location detection is, these days. Let's say you are moving in a direction roughly parallel to the circle carved out by a given signal strength. You could move quite a long ways without RSSI fluctuating much.
I imagine they have to handle the scenario where you're connected to a mobile access point and can't assume that 0 movement means you're in the same physical location. Watching other APs is going to provide a better picture.
What's the newest Wifi standard? ax? Anyway: it's quite... something? My standard router runs four different networks on two different IDs and if I understand it correctly, the fasted frequencies are subject to occasional use by... my local Patriot air defense system(?) which it needs to occasionally check for.
> the fasted frequencies are subject to occasional use by... my local Patriot air defense system(?)
I think you're you're talking about Radar detection?
My apartment is on the approach-path for one runway of a major airport - I regularly get reports of Radar detection on my Unifi APs when planes are landing in this direction.
I just tried this myself and can't replicate on a 2019 i7 running Big Sur. I wonder if it's related to the number of Wifi networks in range (mine is the only one)... Also, the Apple Maps thing didn't seem to change anything for me, either.
Environment can have huge impact on this. With a larger number of devices, there could be more collisions, increasing traffic more than linearly, and then in case of scanning traffic, the modulation used would likely be the lowest available which means the packets take up a lot of wall clock time. So a broadcast storm with collisions, retries, at the lowest bitrate = brief outage.
I reckon that'd be because it isn't relevant to the topic at all. I'd say most things that advertise written in Rust is because it's a valid upside, not all but definitely most.
I noticed this when using a meeting/streaming tool that detected these bits of latency and went in to a degraded mode, even with abundant bandwidth available.
I tried the various settings for avoiding it, discussed in many other comments here. The only thing that worked for me: get out a USB ethernet adapter and a long wire, don't use WiFi when doing things where it matters.
... which is ridiculous; I don't want or need location scans at all, I am sitting stationary in my home office.
Ok that sucks. If they do a scan, at least use the radio that's not in use so it doesn't affect the one communicating (e.g. use 2.4 Ghz when you're connected on 5).. That would be a good way to avoid this latency hit.
Also, I'm assuming Maps only does this when it's open, but Apple's annoying tendency to keep an app running when you close the last window (with the exception of system preferences and a few others) makes this very hard to diagnose. While I still used Macs a lot I would always close apps with Command-Q for that reason. This behaviour would exacerbate the problem as the user isn't aware that the app is stil running.
Apple's reasoning is I believe to "not worry about open apps, the OS will handle it". But it doesn't always, I often get prompts that my memory is full and I have to close something now or else... And that is with me being rigorous closing apps. My work buys only base level machines with standard ram, unfortunately.
> Apple's annoying tendency to keep an app running when you close the last window
This is…just how macOS works. Windows applications (generally) tie their lifecycle to the existence of a window, but Macs have a different paradigm: the program can live without any windows. Pretty much every Mac app behaves this way. It’s been this way as long as I can remember.
iOS is different; you can force close an app with the app switcher, but the OS generally encourages you to leave things “open” and the OS will periodically wake your process so it can perform various tasks. The OS is very stingy about how much work your process can do when it’s in the background in this way. This is one of the challenges when developing for iOS, for sure.
But yes I know it's just how macOS works. I never really got used to it except that it ingrained "Command-Q" into my muscle memory :) I agree it makes sense for some apps. For example for mail, which will continue receiving in the background and notify you. But not for Maps. This is an app that isn't useful when its window is not open.
But I mean this uniqueness to macOS is causing this to cause unintended side-effects. While working in Apple Maps, I imagine the user would not care so much about latency issues and the location tracking would be useful. By the app shouldn't do it while it's not actively being used IMO, as long as there is no way to avoid the latency.
I wonder if the same happens with Apple's own FaceTime by the way, or if they made an exception for that :)
Yeah, I think OP is right that this behavior is confusing for Windows users, but as a longtime macOS user I don't find it confusing or problematic at all.
I'm more a unix user than a Windows user. I use pretty much all current OSes (including Mac and Windows) on a daily basis but FreeBSD is my daily driver. I think macOS is pretty unique in this regard (as well as being the only that use Meta-C / Meta-V for copy/paste, something that still bites me every day as I switch between OSes :) ).
But I only used macOS since 10.2, never used classic.
I had the same issue with copy/paste on MacOS, until I couldn't stand it anymore and used software to remap the keys. I swapped the builtin Fn, Ctrl, and Meta keys around so they are positioned like you'd expect on a normal keyboard (and a normal OS), and it instantly fixed my issues without any other negative side effects aside from having to learn another key combo for Ctrl-C in terminals.
Classic was the same. On older systems, I think it was a good idea, given the speed of hard drives back then. With SSDs, the performance gains from keeping unused programs alive are far lower, but at the same time, RAM is far more plentiful, so it comes at a much lower cost.
Considering Apple added the Command ⌘ key in 1984 and the original cut/copy/paste as being command-x/c/v, it's more like the others didn't follow convention at the time.
The frequencies are different enough for it to be possible technically. The same way mobile phones can be active on multiple bands at the same time. But indeed the used chipset may not support it.
It's something I would expect Apple to have taken advantage of though, as they own both the hardware and the software.
> Ok that sucks. If they do a scan, at least use the radio that's not in use so it doesn't affect the one communicating (e.g. use 2.4 Ghz when you're connected on 5).. That would be a good way to avoid this latency hit.
Is this possible? Or is AP scanning perhaps always over 2.4?
Is this the "weird WiFi latency on Mac OS" thread? I've got a WiFi network with a MacBook Pro (running 11.6 because I hate upgrading) and a System76 linux box (as well as lots of other devices). Both of the machines can ping a google dot com server (which is approximately 150 miles away, going by the hostname) consistently in the 8-12 ms range.
Pinging the System76 box from the laptop, the latency varies from 2-250(!) ms. Pinging the laptop from the System76 box varies from 2-125ms.
I don't even know where to start debugging that but the latency is driving me crazy.
So I've tried this and cannot reproduce anything like it. Yes, when I tell Macos to scan for network, there is a short latency spike, as can be expected. But _only_ when I open up the networks menu.
I have maps open, refresh my location etc. Nothing at all. So there must be some other factors at play. Given the authors wireless woes that I've never had trouble with, I feel like they might just be living in a bunch of farayday cages ;)
Please read the article you are commenting on. In it, they identify the cause and lay out a solution. The solution is not to botch your macbook by disabling core components as AWDL (disabling it will break airplay, handoff and other).
Not sure why you assumed I did not read the article. Anyway I just wanted to point out that this has been and still is an issue recognized by Google Stadia and others.
Other anecdote: I have a thinkpad L450, and randomly during the day, the wifi firmware just "crashes" and disable itself, and needs to be reset via the "troubleshoot" dialog in windows 10.
It's quite annoying, and I can't really think of why it happens.
The latency is also massively better -- I surgically implanted an "ancient" ath9k into my laptop and 5ghz wifi latencies dropped 6x compared to the "modern" broadcom chip on the laptop's motherboard. Still getting 300mbit/sec.
All it cost me was the left speaker, removed to make space for the superior wifi card with open-source firmware.
There are a bunch of these 5ghz ath9k USB sticks, all of which are basically the same ar7010/ar9280 reference design from atheros with different plastic housings around them.
Only if either (a) both networks use the same channel or (b) the networks use different bands (i.e. one is 5ghz and the other is 2.4ghz).
In order to scan usefully you need to listen on more than one channel from each band. Hence, the interruptions.
I suppose in theory if you were using a 5ghz network you could scan all the 2.4ghz frequencies. In practice there is little demand for this, so the proprietary firmwares don't support it (at least some, and often all, of the scan routine happens in firmware).
This is really interesting so I did an experiment.
I connected my iPhone to a 5 GHz-only network on channel 36, and my MacBook Pro to a 5 GHz-only network on channel 48, and I could still AirDrop between them at 300 MBit (which exceeds any real-world speed I've seen on 2.4 GHz), and both devices retained connectivity (an iperf on the MacBook dropped from 600 Mbit to 300 Mbit while the AirDrop was in progress)
After messing around with this and sending around 10 AirDrops, now the feature is completely broken no matter what I do (same network, etc) so who knows (lol)
As a means to keeping this feature on when out in public, but not have it cause latency spikes at home, is it possible to configure the router to block these requests from location services? Or do we need to setup each device to automatically disable location services when on the house wifi?
Wifi positioning does not actively talk to the network you‘re connected to, but rather does a beacon frame sweep and then matches BSSIDs seen with some database.
One side effect of this is that in order to scan all possible wifi channels, your baseband needs to tune to different frequencies at least for a short period of time.
Theoretically this interval should be short enough to avoid any disruptions – practically that‘s apparently not always the case.
It's not just Apple Maps either! Even with location services disabled, try opening AirDrop (even on another device you own) while running a ping and you'll see your en0 device's latency spike, while Apple tries to divide traffic between awdl0 and en0.
I see system_profiler doing a scan when I gather the logs. Is that just the logger itself doing something, and if not is there a way to find what it invoking system_profiler?
I’ve seen this sporadically. A reboot clears it for me. I probably spent a good hour trying to figure out if it was my ISP or router. Improve your QA Apple
lol. i wonder if it's quietly popping the nic out of the associated state, quickly scanning for aps and then jumping back where it left off without telling userland or the remote ap that anything happened...
Background scanning is a normal WiFi feature, you don't break association state when doing this. It is required for regular and fast roaming.
Also it must be notifying userland it happened because location services is trying to gather that info.
Most WiFi clients enable background scanning when signal strength is below some threshold, so you would never notice latency spikes unless connection is already poor.
interesting. so they just switch it on even when the signal is strong.
> Most WiFi clients enable background scanning when signal strength is below some threshold, so you would never notice latency spikes unless connection is already poor.
Interestingly, when I went to Security Preferences there was an icon to show that Apple Maps had used my location in the last 24 hours. This is in spite of almost never using Apple Maps on my MacBook, and certainly not in the last month. So this smells like some sort of background daemon or similar.
While some platforms go through the Maps app to get the location, under macOS/iOS there's the locationd daemon that provides the location independently of any app. There, Maps is just a locationd consumer just like any other app requesting a location so Maps shouldn't be invoked in the background by non-Maps stuff. But perhaps Maps has a timed trigger to background update your cached location (so it can open up to the correct startup location instead of locating you after startup) or something similar.
Did you hop into a vehicle you have paired with bluetooth? Apple Maps drops a "parked car" pin automatically when you do, I think regardless of whether it was in use at the time.
Maybe you used an app that uses an Apple Maps view?
Do you have any of the drive-time/traffic condition widgets active in the lefthand thingy, or homescreen?
A bit of a clickbait-y tweet. Exact same thing happens with any OS and Wi-Fi device when briefly scanning for surrounding access points. In the case of my setup (2017 MacBook Air running 10.15/Catalina) the penalty seems forgettable - avg. ping jumps from 2 ms to 25 ms during 1.5 seconds, on 802.11n/5GHz with about 20 other 2.4GHz/5GHz access points in my vicinity. My Asus ZenBook running Linux Mint and equipped with Intel Centrino Wi-Fi suffers a lot more from the same procedure.
Why would someone program an OS to do this when it's already connected to an access point? This is like me eating a sandwich and stopping mid-chew every minute to check the fridge.
Reason one is that one doesn’t generally connect to an access point (BSSID), but rather to a an SSID. That SSID may have many access points, as the device may roam. Periodic scans check to see if another access point for the same SSID is now a better choice, and switch accordingly. On Linux, configuring the connection to a specific BSSID generally disables periodic scans.
Reason two is to determine location from WiFi network data. Location may not be static even if connected to a single network, since that network may cover a large area and be roam-able, or be moving (hotspot, train, etc.).
> Reason one is that one doesn’t generally connect to an access point (BSSID), but rather to a an SSID. That SSID may have many access points, as the device may roam. Periodic scans check to see if another access point for the same SSID is now a better choice, and switch accordingly.
Maybe I don’t fully understand the Wi-Fi “space” but I gotta wonder why the standard hasn’t embraced a CDMA-like system where your device can just roam around without really caring which AP is the strongest… the access points would all communicate with each other to figure out which one should be responsible for a device.
It would also fix all the nonsense with picking channels for each access point. They’d all use the same spectrum.
A moving wifi AP wouldn't really help with establishing a location, since it's, well, non-stationary :)
In theory, it could establish that you are on a bus/train/airplane... and then look up any public transport information for whereabouts of that vehicle, but I don't think anyone does that.
Because on devices with only WIFI the only way to give you 'GPS' like data is to scan for nearby wifi access points. There are several big databases in the sky that know about a great many Access Points and when your laptop says 'i see these 10 APs with this amount of signal' it can figure out where you are.
It's not really forgettable if any app can request a scan at any time – collect wireless logs, then start the Maps app, you will see repeated scans. Locationd doing this ever so often might be acceptable, but not when any app can do this, repeatedly.
Also, 25 milliseconds is about a round trip across half the continental US. Not really sure that's a good tradeoff for devices that are mostly stationary.
A 750-1000 ms increase would be disturbing, but a 20 ms round trip increase for a brief two seconds is entirely forgettable. It's nothing. It (and more) happens all the time between you and practically any destination out on the Internet as part of normal traffic/congestion patterns.
You got downvotes for being wrong about the issue being real. You get credit for attempting a test but your personal test failed. Oh well. A few downvotes in that case are normal and fine.
I just can't replicate it, and another user ( leodriesch ) pointed out they may be a few versions behind. That's not something I can replicate right now.
