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"
