I think one can "blame" the OS. Now, I'm sure there needs to be a balance between performance and OS overhead, but it seems one role of the OS is to prevent run-away apps sucking the battery.
This might go back to the basic design of Unix. Unix is not a real-time OS and does not have preemptory capacity that would allow it to cut off applications eating up resources.
Without knowing something more, I'd bet that all but specially designed Unix-based OSes have this same problem.
Please elaborate. There's no reason the scheduler in iOS couldn't prevent individual apps from using more than a predefined quota. The *nix heritage had nothing to do with this, remember Android is built on top of Linux and in the sector i work we tailor the Linux kernel schedulers all the time (balancing safety, efficiency and foreground app performance). What do you mean? Why couldn't Apple do this?
As I said, there must be a balance between performance and OS overhead. It seems that Apple has chosen a balance which precludes stopping Spotify from eating up resources. Apple doesn't use a Linux kernel but a kernel based on XNU. My first hand knowledge and experience is ancient and based on Unix System V many decades ago -- I've not looked at OS kernels since then.
Could Apple do something to remedy problems such as this? Beats me -- anything is possible.
Apple does keep battery usage by app, so it's likely they could periodically analyze those stats to detect misbehaving apps.
But, I doubt the solution is something that can be dealt with in the scheduler. Applications like Spotify cannot be preempted and still maintain the quality of sound output -- even microsecond delays are detectable by listeners.
Spotify (and all other similar apps) are definitely preempted - on iOS as well as on macOS, Windows, Android and Linux. No modern, GUI based, computing platform would set up the OS kernel to allow user space applications to freely use the CPU. I'm absolutely sure Apple normally handles this fine, in this case i would guess it is some combination of the Spotify user space behavior and some system calls/libraries that is the problem. Regarding audio applications and potential glitches when preempted (or not switched in), this is easily mitigated by the I/O buffers in the audio drivers (usually on several different layers in the audio path). Only for extremely latency-sensitive applications (like SW synths and other instruments, DAWs etc), you might need to raise the application priority above default level (and you would seldom be allowed to use something similar to "realtime" prio anyway).
Wow. This is just now coming out? I’ve had this issue with the Spotify app since my first iPhone (iPhone SE1) in 2018. I’ve also had issues with Battery Drain after updating the iOS on each iPhone I’ve had since then. The 6S, 7 and now on the SE2. Pretty sure these battery issues are Planned Obsolescence on Apples part
I think one can "blame" the OS. Now, I'm sure there needs to be a balance between performance and OS overhead, but it seems one role of the OS is to prevent run-away apps sucking the battery.
This might go back to the basic design of Unix. Unix is not a real-time OS and does not have preemptory capacity that would allow it to cut off applications eating up resources.
Without knowing something more, I'd bet that all but specially designed Unix-based OSes have this same problem.
Please elaborate. There's no reason the scheduler in iOS couldn't prevent individual apps from using more than a predefined quota. The *nix heritage had nothing to do with this, remember Android is built on top of Linux and in the sector i work we tailor the Linux kernel schedulers all the time (balancing safety, efficiency and foreground app performance). What do you mean? Why couldn't Apple do this?
As I said, there must be a balance between performance and OS overhead. It seems that Apple has chosen a balance which precludes stopping Spotify from eating up resources. Apple doesn't use a Linux kernel but a kernel based on XNU. My first hand knowledge and experience is ancient and based on Unix System V many decades ago -- I've not looked at OS kernels since then.
Could Apple do something to remedy problems such as this? Beats me -- anything is possible.
Apple does keep battery usage by app, so it's likely they could periodically analyze those stats to detect misbehaving apps.
But, I doubt the solution is something that can be dealt with in the scheduler. Applications like Spotify cannot be preempted and still maintain the quality of sound output -- even microsecond delays are detectable by listeners.
Spotify (and all other similar apps) are definitely preempted - on iOS as well as on macOS, Windows, Android and Linux. No modern, GUI based, computing platform would set up the OS kernel to allow user space applications to freely use the CPU. I'm absolutely sure Apple normally handles this fine, in this case i would guess it is some combination of the Spotify user space behavior and some system calls/libraries that is the problem. Regarding audio applications and potential glitches when preempted (or not switched in), this is easily mitigated by the I/O buffers in the audio drivers (usually on several different layers in the audio path). Only for extremely latency-sensitive applications (like SW synths and other instruments, DAWs etc), you might need to raise the application priority above default level (and you would seldom be allowed to use something similar to "realtime" prio anyway).
Generally agree, but there are cases where priority inversion can occur and a lower priority process can effectively keep a higher priority process from running normally, as in following expected scheduling behaviors. Modern schedulers usually have accommodations like boosting to prevent starvation, deadlocks, and hard spins. At least for hybrid kernel based architectures that I've dealt with, there are often user mode drivers/services that mirror kernel level drivers/services for the most common OS services, like accessing built-in ports, so issues in the use of the user mode drivers can be mirrored across to the kernel.
I'm not ruling out anything scheduler related. I generally agree that the kernel should be able to handle user mode processes/threads running amok by ham handed app developers trying to jack up their thread priorities. But I've also seen enough cases of things that should never go wrong actually going wrong because there was a latent "window of opportunity" in the kernel code that escaped the testing coverage in previous versions of the kernel suddenly showing up when activated by a new combination of user mode code, or by the addition of new code in a new version the kernel. It happens in all software and firmware and even in microcode in chips.
One issue I have is that the battery health utility built into iOS/iPadOS is of insufficient granularity to be of any real value in tracking down battery drain issues. I'm assuming there are debug builds of iOS/iPadOS available to Apple's engineers that open up much more fine-grained details about what processes and threads (and their activation hierarchy) are consuming battery and/or keeping the devices CPUs/GPUs and various radios blasting away, which I assume are the major sources of battery drain. I'd love to be able to see more details about what is really going on.
Comments
Regarding audio applications and potential glitches when preempted (or not switched in), this is easily mitigated by the I/O buffers in the audio drivers (usually on several different layers in the audio path). Only for extremely latency-sensitive applications (like SW synths and other instruments, DAWs etc), you might need to raise the application priority above default level (and you would seldom be allowed to use something similar to "realtime" prio anyway).