dewme

About

Username
dewme
Joined
Visits
766
Last Active
Roles
member
Points
14,023
Badges
2
Posts
5,410
  • Apple releases iOS 17.0.3 & iPadOS 17.0.3 with overheating fixes

    jcbigears said:
    I've never experienced a more bug-riddled update than iOS 17, and I'm pretty sure I've been through them all. I have had nothing but trouble with Siri, contacts, and watch-face complications. I would like to see an option of being able to roll back to a previous iOS but alas it isn't possible. Is it unusual to get three supplementary updates so quickly after the 17.0?
    Great question.

    I'd say that in the past it would be unusual to see so many updates rolled out so quickly because doing releases used to be a lot more work and more costly. They probably would have waited a little longer and accumulated more bug fixes before releasing a bigger update. Today, a lot of software development organizations follow a continuous integration/continuous delivery (CI/CD or simply CD) model which, in theory, means that every build or every daily build is in a releasable state. In other words, if they had to ship the daily build, it would be good to go and fully tested. That's the goal, but I'm not sure Apple or very many software development organizations hit that goal perfectly. Getting closer to the goal still represents a significant improvement.

    For CD to work software development organizations have to use a lot more automation, especially around regression testing, but in all aspects of their process from compilation, understanding dependencies impacted by code changes, code signing, integration, version control, change management, installation packaging, etc. There are usually still some processes that require manual testing and verification, but anything that can be reliably and predictably automated without sacrificing the fidelity of the entire software system or introducing variation helps speed up the process is fair game for automation. 

    So the simple answer is: because they've made the whole update process easier, faster, and less risky they can release far more often without sacrificing quality. While we are annoyed by the frequency of these updates, we are now exposed to the negative side effects of bugs for much shorter periods of time. In a world of zero day security exploits, this model has become a necessity for survival. This is why Apple has spent a great deal of effort on refining their CD process to the point where they can support their Rapid Security Response (RSR) update model. So far, so good. But like everything software related, it's still not perfect. Perhaps AI will help move us closer to perfect. 
    Alex1Nwatto_cobra
  • Apple confirms iOS 17 fix for overheating iPhones is on the way

    y2an said:
    Why is iOS not taking action on excessive energy use by apps and giving warnings, or slowing them down? That is, after all, why we have operating systems. 

    That is an interesting question, but as far as I know, there is no process level or thread level energy/CPU load limits built into iOS (and iPadOS and macOS), or any other general purpose operating systems that I am aware of. There are specialized embedded operating systems that do energy monitoring and apply throttling or preemption as necessary to ensure that critical system functions are maintained while ancillary ones are preempted/deferred until additional energy is available. For example, a solar recharged battery powered remote telemetry device may cache data readings locally but only upload them to the remote monitoring site when there is sufficient energy available to run the communication devices, e.g., cellular modem and radio, without losing the data collection function. 

    General purpose operating systems like iOS are built around a shared preemptive multitasking scheduler model. The scheduler only has as many CPU cores and hyper-threading (HT) logic available to it as the system provides. Obviously there are always many more processes/threads that are ready to run than there are available cores and  HT logic. Additionally, there are some processes/threads that need to run more often to maintain the systems state, manage memory, manage interrupts, manage IO, interact with sensors, interact with the user, etc. Simply put, the operating system is providing an illusion that every process and app is running in its own dedicated machine with its own memory, storage, CPU, IO, user interface, etc., when in fact the system's hardware resources are time-shared (unequally) between every process and thread running on the real machine. The scheduler determines who gets to run at any given time.

    All processes/threads, both in the kernel and in user mode, get an opportunity to request the priority that they want to be scheduled. If all threads asked for the same priority and if every thread was always ready to run every time the scheduler came around to hand off a core to another thread, and if every thread used their full time quota, all processes/threads would get an equal share of the core/cpu. But that would be disastrous. Things that are critical to maintaining the system state, like pretty much everything done in the kernel, need to run much more often. Thus, the need for priorities and why things that are critical to maintaining the system state (kernel functions) get the highest priority when it comes to running.

    User mode processes, i.e., Apps we install, must also specify directly or by default the priority for all of the threads they create. How many threads do Apps create? It may be only a few, but it could be hundreds or more. Unfortunately there is no Activity Monitor on iOS, but on the Mac that I'm typing this on the kernel has 647 threads right now, Google Drive has 102 threads, and Firefox has 82 threads, as an example. The scheduler is responsible for making sure all of the threads that are ready to run are given cpu/core time. Of course the highest priority threads get a lot more cpu/core time, but the operating system also has starvation prevention algorithms to ensure even low priority threads do get some time in the cpu/core even when higher priority threads are ready to run. The "ready to run" point is important. Not all threads that exist are ready to run. These threads are often waiting on some event, signal, interrupt, etc., before they are ready to run. If a thread isn't ready to run it does not get scheduled.

    The Apps that we deal with, like Instagram, run in user mode and at a lower priority than kernel threads. All running Apps compete for core/cpu time against one another as well as the kernel threads. As long as the system has plenty of cores and not too many ready to run threads (varies by hardware capabilities) everyone is happy and the system is likely spending the bulk of its time idling. However, each App creator gets to set the priority of the threads they create and even the core to run inside. In some cases the App creator has determined through testing that their App runs better/faster/more responsively if some of their threads are run at a non-default higher priority. This changes the scheduling behavior on the machine and potentially reduces idle time so the CPU has to run at higher utilization levels, increasing heat.

    Jacking up the thread priorities in your App, or asking that your thread runs on a specific core, may result in other Apps running more slowly, or put more load on the CPU. But priority jacking isn't the only way to put more load on the CPU. Some developers are uncomfortable with multi-threading because it is hard to deal with concurrency issues, synchronization, mutual exclusion, locking. blocking, waiting, thread lifetime management, etc. So rather than using thread synchronization to provide a way to block while waiting on an event or signal, like an IO input or asynchronous response, they will use a high priority thread as a polling mechanism to constantly check for whatever it is they're waiting for. Polling always increases CPU utilization.

    Finally, why should we worry what Apps are doing in user mode space when the kernel is always a higher priority? Because operating system APIs (directly or indirectly) result in kernel level threads being created to service the user mode requests. This means that "badly behaved" (from an energy consumption perspective) user mode Apps can still result in the kernel having to schedule additional kernel threads to run and place more load on the overall system. As far as I know, the iOS kernel does not intervene in any way to ensure that Apps do not place excessive demands on the system. It will intervene when the "bad behavior" causes system issues like overheating. That's not to say that it couldn't intervene, but doing so would require cooperation from the Apps and the thread creation process, for example, providing a thread attribute that tells the operating system that the thread's priority can be reduced under certain system conditions.
    FileMakerFellerAlex1Nwatto_cobra
  • iPhone 15 overheat complaints are inconsistent, and it's unclear what's going on

    jdw said:
    I know AppleInsider often considers YouTubers a less than reliable source of information, but consider well what one respected tester has to say about the Instagram app consistently raising iPhone temperatures when doing nothing at all, which holds true among different iPhone models...

    https://www.youtube.com/watch?v=P6X2ZIkYFsQ&t=478s

    Nothing I read in the AppleInsider article seems to address the Instagram app, which as you know is not a gaming app.  And like I said, the testing indicates a large temperature increase even when doing nothing.  Since Apple vets all apps distributed in its app store, the question becomes how did Apple allow the Instagram app to get their approval?  Does Apple bear no responsibility for allowing apps that overheat iPhones to continue to be distributed?

    I would appreciate it if you folks at AppleInsider could test the Instagram app and then write a follow-up article sharing your detailed thoughts.  Because in my opinion, if the Instagram app can cause heat to rise dramatically for no good reason at all, logic dictates that other non-gaming apps could do so as well.  This needs serious investigation.

    Thank you.
    Everything you’re saying with respect to some apps making higher demands on the operating system and underlying hardware than other apps makes sense. Any app that creates lots of higher priority worker threads and keeps those threads running and doing work will absolutely increase the workload on the system. If those threads are also utilizing other system resources that consume power like the GPU, I/O including the radios and modem, various sensors, and of course the screen it only increases the power consumption and consequently the heat that needs to be dissipated from the device to prevent overheating.

    It’s an over generalization to say that only gaming apps can stress a system. Yes, some games tend to be very resource intensive and spin up a lot of higher priority threads because they are doing a lot of multiprocessing to maintain the computational dynamic models that define the game space and action. Plus they are constantly interacting with the user and need to be as responsive as possible. Basically, there’s a lot of processing going on both in the background and in the user interaction on the screen and through user controls so these apps are telling the operating system they want to run as many threads as possible as often as possible. The operating system tries to accommodate their needs to the extent that it can by scheduling run time quotas that meet the scheduling priorities that the app has specified when it creates its threads. When there is a mix of threads with varying priorities running concurrently (in a time sliced manner) this tends to work well, but if several apps ask for high priority scheduling all at the same time, the system will as fast as it can, consume more power, and generate more heat. Worst case, apps start running too slow in the eyes of the user.

    On the other hand, many less interactive apps spin up a threads but a lot of these threads are doing less intensive background processing or waiting in an idle state to be woken up to respond to an event or interrupt. If those events and interrupts aren’t coming at a breakneck pace, perhaps because the user is typing or staring at the screen or little to nothing is changing that needs updating, the demands on the system are much lower.

    At the same time, the operating system itself has to run all of its own threads and processes along with all of the I/O and background tasks that it needs to keep the system running and in a consistent state. Fortunately the operating system does assert its own precedence to satisfy its needs over those of the client apps with their processes and threads that have demands of their own.

    I don’t know whether Apple’s app review process place restrictions on how much demand an app places on the system. Hopefully the app reviewers profile the resource demands and consumption that apps present and consider whether these make sense for the purpose and function of the app. An app that exhibits unusually high resource consumption could be indicative of an app that is doing something unusual or nefarious in the background, something that doesn’t makes sense based on the app’s advertised functionality. If this is the case I suppose they dig a little deeper and go back to the developer to inquire why the app is such a resource hog in light of what it is supposed to be doing.

    Whether Instagram falls into this category is anyone’s guess. But if Instagram is consuming resources and placing unusually high demands on the system for the functionality it provides then I suppose users can inquire about this to the app developer or request additional information from Apple by reporting its behavior as a bug.
    Alex1N
  • iPhone 15 overheat complaints are inconsistent, and it's unclear what's going on

    I’ve had 3 sporadic heat issues with my 14 Pro Max over the last 10 or so months. The last one occurred when I slid the phone into my pocket while making a gas stop and left the Maps navigation running. It got uncomfortably hot in my pocket so I powered it down and placed it in front of the AC vent when I got back in my car. When it cooled off to the touch I powered it back up and the issue did not reoccur.

    It all happened very quickly, within 3-5 minutes or so of it being in my pocket. I attributed the last incident to the phone having poor reception and jacking up the radio power to try to get a better signal. The other incidents were not related to the use of the navigation functionality. The phone just got hot to the touch at random times. I suspect a software anomaly led to a process or thread spinning in an infinite loop because the phone seemed sluggish. Restarting the phone always made the issue go away.

    All of my heat incidents were based on the phone feeling unusually hot to the touch or in my pocket. I didn’t have a non contact temperature measuring device with me and the phone did not pop up a warning of any kind. So it’s also possible that I was being overly sensitive to my phone’s condition.

    I’ve yet to encounter any charging related heat issues with the iPhone 14 Pro Max, but I’m only using Apple’s 20 W charger with an Apple brand MagSafe puck. 
    Alex1N
  • iPhone 16 rumored to gain new capacitive 'Capture Button,' updated Action button

    jdw said:
    We need a reprieve from iPhone 16 talk.  Seriously. Most people are still playing the waiting game for the iPhone 15.

    Now I know full well you news people need to make money by releasing new stories.  And Apple rumors unfortunately has become a major part of that because it feeds selfish human nature to want, want, want. But here's the crux.  Many people get disappointed with Apple product releases only because they read the tech media stories, learn pretty much everything about a new device BEFORE it is released, and then on the day of the announcement they come away not surprised at all and somewhat disappointed.  Had the stories and rumors not existed, people could finally be pleasantly surprised and overjoyed at the update announcements once again.  That's right, there once was a time when we actually were surprised by Apple and those really were the Good Old Days!

    All the leakers and analysts who feed the rumor sites non-stop need to crawl back into their holes and stay there.

    If I could wave my magic want and make all the iPhone 16 talk vanish worldwide for the next 6 months at least, I'd do it.  We need to focus on what we have, which is great, by the way.  There will always be something newer and better, but let's just slow down and enjoy what's before our very eyes.

    Lastly...

    Tim Cook, people shouldn't have to wait more than 1 month for a phone that costs well over $1,000.  Not everyone can or wants to buy from a wireless carrier, which were allowed to buy up most of the iPhones and who made everyone else wait as a result!  Fix that!

    I have to agree. We haven't even received or opened our Christmas presents for this year and we're already being bombarded with folks telling us what we should put on our wish list for next year's Christmas.

    As far as the pre-release spoilers and inevitable delays in obtaining the most popular newly released products is concerned, all you can really do is to recalibrate your consumption model and expectations. It is possible, but not easy, to avoid reading all the speculation around the "next greatest thing" in the pipeline and you can delay your product upgrades to occur on your own timeline, sometime after the initial crush of orders that predictably happen in the weeks after release.

    Easier said than done because the speculation cycle for the "n+1" product version starts even before the "n" version is publically announced. Apple product and feature speculation has become an industry in and of itself. It's unbounded by the physical and time constraints the actual product developers have to contend with. With such a vast supply chain the probability of something leaking out into the Apple Product & Feature Speculation Industry with its vast network of media outlets and rabid prognosticators seeking affirmation is nearly impossible to contain.

    I have managed to delay my last few Apple purchases for about 2-3 months post release, just to let things cool off a bit and to let the hysteria subside. It has not been a complete success because Apple's supply chain still isn't firing on all cylinders. If you stray too far away from the base or more popular configurations on some Apple products you may still have to wait even after you've waited. 

    If you see the configuration you want on Amazon it's highly likely you can walk into an Apple Store and bring one home that same day. I was able to get an iPhone 14 Pro Max with 512 GB storage the next day, but the Mac Studio with 2 TB storage and MacBook Air with 2 TB storage required a couple of weeks even after the initial 2-3 month surge should have subsided.  If you think Tim Cook should be held accountable for making some people wait weeks for $1,000 plus iPhones, imagine the people who waited 2-3 months for a $5,000 plus Mac Studio, which is what quite a few Studio Ultra buyers had to contend with.

    All I can say is that Apple's version of just-in-time manufacturing isn't always calibrated against the same time reference that its customers expect.
    Alex1NjdwAnilu_777williamlondonwatto_cobra