Oh, oh, oh Samsung, up to their usual tricks.
Samsung phones ship with a Game Optimizing Service app pre-installed as a system app — we confirmed it’s installed on the Galaxy S22+, as pictured below. It cannot be disabled. The app’s exact purpose isn’t described very well anywhere, but its name certainly implies the app is used to improve performance for games.
However, as one Twitter user points out, with the backing of a lengthy thread from frustrated Samsung Galaxy owners in Korea (via Android Authority), Samsung seems to be using this app to “optimize” the performance of thousands of non-gaming apps. When an app is in the Game Optimizing Service list, its performance is limited, as demonstrated by a YouTuber who changed the package name of the 3DMark benchmark app to trick Samsung’s software into throttling it, and the results are pretty telling.
In and of itself there’s really nothing wrong with managing the performance of various applications in order to preserve battery life. However, it has to be done transparently and openly, so that users can easily see what’s going on and disable any optimisations they’re not interested in. This kind of obfuscation by Samsung is deception, and simply should not be allowed.
They could have avoided all this with a “game mode” toggle on the settings UI. (The one you pull down to manage Wifi and such).
Yes, mobile performance can be tuned a lot. Even regular modern CPUs will change parameters on the fly, and things like “BogoMips” no longer make sense. However if you are boosting CPU speed on benchmarks, while reducing it to save power otherwise is a pretty bad move.
I was also upset with M1 benchmarks for this reasons. Sometimes peak performance is important, sometimes it is the sustained one that is more relevant.
Side note: I think currently “Steam Deck” seems to offer the best open controls on this area.
Not very convenient to phone with a “Steam Deck”.
Kochise,
I had used a Samsung tablet as a “phone” for a while (SIM card and all, but no actual cell calls, only VOIP). So it would be fine 🙂
Joking aside, I was referring to them being open about performance affecting battery life, and having lots of options to fine to it. And they even expose all thermal data, so you can export to Excel and do your own analysis.
Cell phones are becoming even more taller walled gardens, while consoles are opening up.
Still, the “Steam Deck” is more a computer and for enthusiasts than an Android smartphone.
I don’t understand your point… There are two different devices with two different operating systems that provide a similar feature, which is that the user can change the performance of the device during portable gaming.
sukru makes the point that Samsung implemented this feature in a way that is closed and confusing and hides information from the user, but the Steam Deck implements the same feature by being open and transparent and keeping the user fully informed.
Is there a reason it can’t be or shouldn’t be implemented this way on Samsung devices?
No, of course not, but the “Steam Deck” is purposed for performance and for advanced users. It is expected to have such freedom of tuning. Much less so the “Samsung Galaxy S22+”.
But why whining about another shady tactic from a phone manufacturer that is known for this kind of crap ?Just select another brand, vote with your wallet.
I think performance / endurance balancing is part of the manufacturer secret formula with which the try to get best of both worlds and show competitive competency.
As long as this “throttling” doesn’t disrupt user experience it should be fine. How different is that from CPU governor settings?
It’s like cheating the benchmarks. If you buy a high end phone such the S22+, you expect to exploit its power and play games with the full experience. In expense of the battery life. Otherwise it just shows that without this throttling, the S22+ is just like any other phone in term of battery life and is just using a trick to make it last longer.
Kochise,
Yeah, they can tune things, but they really need to be transparent and give owners an override.
Too often we’ve seen performance parameter tweaking based on process names to cheat. Anyone can maximize battery life by reducing performance and maximize benchmarks by increasing performance. But it becomes dishonest when they sell a phone that doesn’t get the expected battery life and/or performance because they cheated on the tests..
Alfman,
Yes. The phone tech specs lists features as if they have an “AND” relation, but it is usually an “OR”.
* 10 hours battery life
* ultra bright HDR
* WQUXGA (3840×2400) resolution
* high speed cpu
Some manufacturers, like Razer, offer active cooling and external battery packs to improve gaming sessions. But thinking one could have all these features at the same time is very misleading.
Again Steam Deck reference: Battery life drops to 1.5 hours from 8 hours if you maximize all settings.
That’s a way more honest statement.
It’s not even close to cheating benchmarks. It’s balancing performance vs battery life for the vast majority of users that don’t play games. I’d much rather have that balance and have a phone that lasts 12 hours instead of a useless phone that last only 6 and that goes for most consumers.
Windows uses balanced mode instead of performance by default. It’s the same idea. It sure as hell is not about cheating benchmarks. Most people browse the web, look at Facebook, use Office, view some YouTube videos. That kind of thing. Most people would rather have 8 hrs instead of 4 on battery for their average everyday usage.
0brad0,
That doesn’t make sense though. If you don’t use the apps or games being throttled, then the throttling will add no improvement to your battery life. The tradeoff can only work if you use the apps that are throttled.
Nobody’s really against your having the option. The problem is having benchmarks report one performance then the phone failing to deliver it. Assuming the report is true, it is cheating. In any case as long as samsung stops hiding it’s throttling and gives owners control over it, then everyone can set things how they want and move on.
Is it just me, or does this sound entirely normal/expected – improving game performance (by throttling poorly designed apps that waste CPU time and slow games down)?
Brendan,
Take a loot at what’s being throttled…it seems to be thousands of foreground apps including games being throttled. Even if you want to put this in a good light and say they’re throttling intensive applications to extend battery life, not applying the same throttling to benchmarks means that the scores reflect CPU performance levels that regular applications are not able to achieve. This is especially problematic given that it wasn’t disclosed and cannot be disabled.
Ah. Games should be throttled. It’s better to run at the same performance continuously than to go as fast as possible for the ~30 seconds it takes for temperature to get too high and then be forced to throttle back severely in an attempt to try to cool everything down after its too late.
Brendan,
The throttling should be based on an actual temperature feedback loop like it works almost everywhere else rather than using the process name, which IMHO is dumb. I don’t speak Korean but the videos show over 50% framerate & scores loss just by renaming the app, While there’s nothing wrong with providing the feature as an option to prolong battery life. It was very deceptive and unprofessional of them to make it mandatory and not disclose it’s existence. This leaves users with an invalid impression that the benchmarks are representative of the phone’s performance when in fact it will be far worse.
Unfortunately benchmark manipulation is something that companies do and so I think some people will believe they did it intentionally. I personally don’t know, but if it was an innocent oversight then they can make it right by making it clear going forward and giving owners the option to toggle it.
That leads to oscillations – everything starts off being cool so the OS decides “Yay, I can afford to run 50% faster with 100% more power consumption and 100% more heat”, then it slams head first into a high temperature threshold and the OS says “Oh no, throttle back to half speed”, then …
Note that the relationship between performance and heat (or power consumption) is complex. E.g. as the temperature increases leakage current increases (causing more heat at the same performance); so max. sustainable performance depends on preventing the CPU from becoming hot in the first place.
The correct solution is to pre-determine “max. sustainable performance” and stay at that speed (or close to it, with very minor adjustments for temperature) to avoid massive performance swings (especially that initial “max. speed” burst when CPU is cool).
I’d expect that (without throttling) you’d get 50% higher frame rate for about 30 seconds, followed by much worse frame rates for hours (on average, in a “surging between sometimes slightly better and sometimes much worse” way).
In other words, I’d expect that videos showing 50% higher frame rates are misleading.
If it was intended for battery life they wouldn’t throttle when the phone is plugged into a charger, and if it wasn’t throttled when on charge people would be saying “50% faster when on charge” (which is easier to test) and not “50% faster if I rename the app” (which is more hassle).
The problem with providing an end user option is that 50% of end users won’t bother changing the option (and then they’ll complain that the default behavior is wrong), 25% of end users are clueless people that will set the option wrong (and then complain that the behavior is wrong), and 25% of end users are clueless people that will set the option right by accident (and then still complain about the behavior because they’re never quite sure if they set the option right or not).
Yes. Without throttling; short-term benchmarks (that don’t run long enough to get CPU hot) and benchmarks that have deliberate breaks to let CPU cool will continue to be as misrepresentative as they’ve always been; and good benchmarks will give worse scores (causing people to think a phone is slower than it is).
They should throttle the good benchmarks (if there are any) to improve the scores and make those benchmarks more representative of the phone’s performance (so people don’t think a phone is slower than it is).
Brendan,
That could happen if you trigger the CPU’s absolute temperature cutoff, but it’s not like this is a new unsolved problem that samsung or android is solving for the first time. We generally manage temperature much better than that with instantaneous feedback loops that involves a reactive gradient. This is the reason we don’t see the huge jumps and stalls that you’re talking about in practice unless something is really wrong.
Sure, that’s how things normally work, but that’s not what samsung is doing, which is consistently throttling processes by name for the life of the process. This has two obvious effects: 1) significantly reduce performance, and 2) increase battery life. To be fair some users may benefit from this tradeoff, which would be fine if they clearly understand they won’t get full performance. But to force this throttling and not apply it to benchmarks is clearly misleading users on performance.
No, the throttling produced 50% fewer FPS, the mathematical inverse of which equates to 100% higher FPS for no throttling.
Anyways, it depends on how you tune things, the thermal capacity of your system, etc. A phone doesn’t have nearly as much thermal mass as a laptop or desktop so it will reach equilibrium faster. For the record though, the drastic difference in benchmark scores are abnormally high even for multiple sequential runs on a system that’s warming up. Assuming that nothing’s been faked, then the evidence is pointing to a very substantial loss of performance under samsung’s throttling.
Yes that’s the whole point of a benchmark. It’s wrong and misleading to apply one profile to apps and another to benchmarks. As for the full time throttling as a feature, I suspect some people don’t want that…but if it’s fully disclosed and fairly represented by 50% lower benchmarks and they knew what they were buying, then IMHO that’s ok. It seems that samsung may give owners the option to disable the throttling which would be ok too.
It’s hard to be sure how each vendor tweaked the kernel; but in general it’s based on Linux and is therefore a hacky pile of shit that periodically polls CPU load and sets CPU frequencies without ever caring what caused the CPU load (and without caring about future load), that applies the same naïve strategy for everything.
Note that there are 2 very different kinds of loads. For normal apps, the system is typically idle until something triggers a short burst of activity; and the right strategy is “race to idle” (quickly switch to max. speed knowing that the burst of activity will be brief and won’t have much impact on temperature). For continuous loads (e.g. games), that same “race to idle” strategy is a horrifically broken disaster.
You’re right in that it’s not a new unsolved problem that they’re solving for the first time. It’s an old unsolved problem that they’re trying to fix/improve (actually caring about what caused the CPU load) for the first time (or at least the second time – Samsung aren’t the first to try to work around the inherent stupidity of Linux via. throttling).
Ah, OK.
That’s not unsurprising for the difference between “max. speed for race to idle” (e.g. maybe as much as 40 watts) and “max. continuous speed that can be sustained for 8+ hours” (e.g. maybe 5 watts)
It’s wrong and misleading to apply “performance for brief periods” to situations where “performance for a continuous 8+ hour period” is what matters. Most benchmarks for smartphones measure the former (which is fine for most apps) and should not be throttled; and this makes them wrong and misleading for the latter (where throttling should be done for apps that cause continuous load and benchmarks that measure continuous load).
Brendan,
Can you give me a single reproducible test case for the “disaster” you are claiming? The thing is you claim this has been such a notorious problem for a long time yet I’ve never experienced any of the disastrous symptoms on any of my android devices or linux desktops.
I don’t have this samsung phone to test with unfortunately, but I did test 3dmark on my lineage OS phone and the scores don’t support your hypothesis. The benchmark performance does not show any signs of the massive deviations that you claim would be there without samsung’s throttling. Starting cold and running back to back tests shows virtually no deviation running for 9 minutes. The scores are reproducible as expected.
3dmark wildlife
3838 3858 3862 3864 3862
3dmark wildlife extreme
1122 1122 1122 1119 1122 1122 1123 1121 1122
So unless you’ve got some new evidence to share, the problem you are claiming doesn’t seem to have much evidence going for it. I’m not trying to be difficult here, but I do need data to be convinced and I think it’s a reasonable request.
Why do you think you need a test case for something so blindly obvious? Here’s a research paper instead: https://ces.itec.kit.edu/img/Improving_Mobile_Gaming_Performance_through_Cooperative_CPU_GPU_Thermal_Management.pdf
Take a look at “Figure 2”, where CPU frequency is bouncing between 1 GHz and 200 MHz in the most idiotic way imaginable (and then try to explain why CPU isn’t staying at ~850 MHz to deliver constant performance instead of massive performance swings).
Note: For normal desktop and server this doesn’t happen – the fan speed fluctuates instead. This is also annoying (the sound, “iiiiieeeeeiiiiieeeeeiiiiieeeee….”) and stupid.
Did your results look like this: https://benchmarks.ul.com/hwc/tmp/3dmark-wild-life-extreme-result-screen.jpg
.. where CPU clock frequency is bouncing all over the place in the most idiotic way imaginable?
Brendan,
No it is not obvious and I’d say there are millions of people gaming without issue. I do appreciate the research paper. It talks about thermal coupling between the CPU and integrated GPU, which is interesting although different than the “race to idle” CPU effect you were talking about. Nevertheless I did try to install the game to see the problem for myself but unfortunately they used a proprietary game that I can’t find an APK for. So I’d still appreciate a specific test case if you have anything that I can reproduce on my end.
The root cause of the problem discussed in the paper appears to be that the GPU isn’t throttling properly and therefor the CPU is forced to throttle until the GPU pipeline stalls by proxy. Assuming that’s what’s happening then I concede it doesn’t look good, but technically the manufacturer of the GPU and GPU drivers is at fault here. The linux kernel is acting appropriately to the CPU over temp condition IMHO and is the victim of the GPU overheating problem and not the root cause of it.
Haha, I’ll grant you that but it has nothing to do with linux. Many desktops and servers are designed to sustain high performance and the fans will ramp up as a result. It is what they’re supposed to do. There are many ways to down-clock, reduce performance/framerates/visual quality/etc and that will reduce the fan speeds, but it’s obviously a tradeoff.
I don’t own the advanced edition of 3dmark, however what you call idiotic may be perfectly normal depending on what’s happening with the workload. The scenery is changing, dynamic conditions are being tested, etc. Also I want to point out the irony of your using a screenshot of a windows benchmark to criticize linux behavior.
Look Brendan, I think you came into this discussion wanting to be critical of linux regardless, but that’s all tangential to the main point which is that Samsung’s throttling significantly reduces performance compared to normal. And samsung has already responded saying they would provide an update to increase performance. So assuming they follow through I think everyone can be happy.
The fundamental problem here is:
a) there’s multiple variables that are inter-dependent; with the priority of work on one side (ranging from “idle” to “high priority soft real time stuff that has to respond to user ASAP”), and a complex “performance vs. (power consumption/heat vs. battery life vs. temperature)” on the other side.
b) You have one system (the OS scheduler) that only cares about “priority vs. performance”, that completely ignores the entire “performance vs. (power consumption/heat vs. battery life vs. temperature)” part of the equation.
c) You have another separate system (power management) that only cares about “performance vs. (power consumption/heat vs. battery life vs. temperature)”, that completely ignores the “priority” part of the equation.
If you bring all this together as a single system it becomes “relatively obvious” that high priority work (the stuff that needs to respond to user ASAP that only runs briefly) justifies “higher than can be sustained continuously” performance (clock speed, etc); low priority work (e.g. apps running in the background) should be run at significantly lower performance (to save battery, and to reduce temperature so there’s more thermal capacity for high priority work to use); and stuff in between (e.g. games) should running at/near the speed that can be sustained indefinitely.
You can (I would) express this in terms of target temperature – e.g. for very high priority work the target temperature might be 80 degrees, for medium priority the target temperature might be 40 degrees (whatever is comfortable to hold in your hand), for low priority the target temperature might be slightly above ambient temperature (maybe 28 degrees) and for idle the target temperature is effectively zero (ambient temperature, maybe 25 degrees). When scheduler does a task switch it should be doing “new task’s priority is W therefore target temperature is X; but current temperature is Y and taking that into account means I’m going to set the clock speed to Z”; and then periodically (maybe every 20 ms or so) repeat this evaluation if there’s no task switches.
Note that this applies to each CPU independently, and “groups of GPU cores” independently; but could (should?) also be modified by some kind of “CPU vs. GPU” balance; so it’d be more like “new task’s priority is V therefore target temperature is W; but current temperature is X and the CPU/GPU balance is Y, and taking those into account means I’m going to set the clock speed to Z”
Samsung’s throttling is an attempt (possibly a bad attempt, but an attempt nevertheless) to work around kernel developers’ failure to understand the fundamental problem by using a “big hammer” approach (throttling whole apps based on the app’s name, because thread priorities are probably broken, and scheduler is broken and power management is broken) to get closer to the behavior that should’ve existed from the start but didn’t.
Brendan,
Sure you can make it as tunable/complex as you want, but the crux of the problem seems much simpler than that. The GPU wasn’t effectively throttled thereby forcing the CPU to be throttled instead. Can it cause problems? Sure, but it has to be fixed in the GPU drivers. When those drivers are proprietary…well what exactly is “linux” supposed to do?
BTW I’d still like a reproducible test case if you know of one speficially.
The performance loss is so egregious that I find it hard to believe samsung was truly this incompetent. I find it more plausible that engineers were intentionally instructed to sacrifice performance for battery life. In any case though since samsung wrote both the GPU drivers AND the throttling app, the fault clearly lies with them either way. They don’t get to blame someone else.
The crux of the problem is that multiple separate systems is an inadequate approach for managing a single set of inter-dependent variables.
Note that “end user tunables” are always a clear indication of failure. All of the physics are known (by smartphone vendor – how much heat is created at various performance levels in various parts, how much thermal capacity there is, how much the heat the device can dissipate, etc), which means it can be right (and if it is right, the only possible reason for “end user tunables” is to allow the user to make it wrong).
Let me spell it out for you:
a) Linux is a big sack of crap slapped together by incompetent fools who failed to provide a coherent single “power management” system (and hacked up a pile of turds in the form of multiple separate systems trying to manage a single set of inter-dependent variables).
b) Because Linux lacks a coherent single “power management” system; it’s impossible for any driver to participate in the non-existent single “power management” system.
c) A GPU driver gobbling all the thermal capacity is the direct result of Linux being big sack of crap slapped together by incompetent fools. Not only have they made it impossible for drivers to participate in a non-existent “single power management system”; they’ve failed to provide any standard or documentation for how video driver is supposed to work (for their half-assed “multiple separate power management systems”, or in general).
d) The same root cause is responsible for many related symptoms – people being told to take a 5 minute break for every 30 minutes of gaming (and to disable everything, and to remove smarthpone case, etc) to prevent the device overheating (and impacting device longevity), pure “CPU only” continuous loads getting throttled after 30 seconds or so, a whole decade of research papers suggesting ways to make it suck less, multiple hacky work-arounds (from Samsung, etc) that don’t fix the root cause, etc.
If you’re too lazy to think for yourself and realize I’m right based on theory alone; and too lazy to accept both a research paper and a real-life example; and too lazy to find any continuous load and monitor CPU frequency yourself; then I shall respond in kind and be too lazy to provide the irrelevant reproducible test case that should never have been needed in the first place.
Again; the performance difference is exactly what I’d expect for the difference between “peak performance that can not be sustained” and “peak performance that can be sustained for 8+ hours”.
Brendan,
It’s better to give reasonable defaults and then allow tuning. Some people need more battery life versus other people needing more performance. Let’s not pretend we can eliminate end user tunables without annoying those who have different needs.
You know Brendan, it seems pretty clear that you just want to say this regardless of facts. Seriously starting with your first post you erroneously said “this sound entirely normal/expected – improving game performance (by throttling poorly designed apps that waste CPU time and slow games down)?”. And then when it was pointed out that Samsung was actually throttling game performance you did a full 180 and saying “Ah. Games should be throttled.” saying that the higher performance isn’t sustainable. Fine so I tested your claim and you were wrong, the performance is quite stable. I’ve repeatedly ask you for test cases that you still will not provide. You provided a benchmark screen shot saying “CPU clock frequency is bouncing all over the place in the most idiotic way imaginable?”, but then it turned out to be a screen shot showing windows behavior and not linux. You cited a paper that shows android GPU throttling isn’t optimal, which is fair enough except you want to blame linux instead of those responsible for samsung’s GPU drivers.
You seem hell bent on blaming linux even though it’s been established that samsung is responsible for the performance problems in this article.
Look into linux HWMON and CONFIG_THERMAL. Linux has support for generic thermal management. In practice linux see and control all devices exposed by ACPI (ie in the BIOS) or that it has platform drivers for. System integrators can either write their own kernel driver governers, or userspace helpers. Either would work.
No, it would be the fault of the GPU driver author who didn’t write drivers to do proper thermal management.
Sources please.
You can’t blame me since I ran tests and didn’t see problems, hence the requests for test cases. If they’re so easy to find then _please_ provide a specific test case.
Again, I already ran the test for 9 minutes and witnessed no loss of performance. So how long do you assert I need to run a test before seeing degraded performance on the level of samsung’s throttling? My prediction is that there is no amount of of time that would reduce the performance to levels anywhere close to samsung’s throttling. Do you still not accept that samsung’s throttling is killing performance?
I think the evidence against them is strong, but maybe you want to agree to disagree?
These are smartphones. There are no users with “different needs” (like laptop vs. server). They all “need” (want) both longer battery life and higher performance. One user running an app is not different to any other user running the same app.
No, you did a half-baked “test” of only one thing on only one phone (with unknown/unspecified hardware under unknown/unspecified conditions), and then provided disingenuous partial results (from a short period of time, without temperature readings, looking at “average frame rate” and not CPU frequencies); and when I tried to find (what I thought was) the same test I found that it provides a full chart showing CPU frequencies and temperatures and asked for clarification (wondering why you’re not providing relevant results if the benchmark I thought you were using provides them).
Um? Show me something (anything!) where the load (which process, which priority, whether its likely continuous or likely short bursts) is taken into account for any power management decision.
Providing proof that they don’t even have a combined “monitoring and control” API (where CONFIG_THERMAL doesn’t even exist on smartphone to begin with) isn’t going to convince me that they’ve combined scheduling (of load on CPUs, GPUs, ..) and power management into a single coherent system.
It’s the GPU driver author’s fault that it’s impossible to comply with non-existent specs; and the GPU driver author’s fault that they have no choice but to create their own completely separate system for GPU power management that is not part of a single coherent system?
What, exactly, are you suggesting that smartphone GPU driver authors do? Should each GPU driver author create and maintain their own list of apps/games where GPU needs to be “severely throttled” to guard against the unwanted throttling of CPUs? Should a GPU driver be wholly responsible for making decisions like “Oh, this app is using GPGPU for background processing while another app is also trying to use GPU for 3D graphics; so I’ll throttle GPGPU so I can boost graphics” without having any clue what any of the load is actually for?
You’re going to deny the existence of problems immediately after attempting to blame someone else (GPU driver author) for them?
Let’s turn the tables – let me be the one trying to ignore and deflect without using any thought. Do you have sources for “it would be the fault of the GPU driver”? Do you have sources for “it’s Samsung’s fault that they’re trying to fix a problem they didn’t create”?
Did you notice that Samsung provided a list of 10000 test cases? Feel free to do proper testing (e.g. charting temperature and CPU frequency and GPU frequency for an 8+ hour period) on each one.
It depends on too many factors (the load itself, the hardware, vendor specific power management tweaks, ambient temperature, etc). The correct way to test would be to make sure the phone is cool and fully charged to begin with, and then continue testing for as long as it takes for temperature to stop increasing (for whatever reason).
Note that some phones just don’t bother at all – they let temperature increase until it reaches a critical threshold (e.g. 80+ degrees) and then treat it as an emergency over-temperature condition. For some cases (e.g. a load that is primarily GPU, running on hardware with power hungry CPUs and weak GPU, with cool ambient temperature) it could take many hours for a phone to switch to “emergency over-temperature” (and for temperature to stop increasing and start to fall).
Brendan,
This very article proves that users have different needs. Some users may want more throttling to get more battery life. But others want more performance instead. Even one user may want to change between performance and battery life at different times and places, like at home versus on a plane.
I did the test and it disproved that the benchmark dropped over a longer time. If you don’t think 9 minutes is enough then tell me how long you think it needs to run. You posted the benchmark screenshot with the intention of showing that rapid frequency changes are a linux problem, but the screenshot shows it happens on windows too.
Thermal mass already reduces the impact of short bursts. You need longer loads to cause dramatic temperature swings.
It is strictly up to the system integrator to do this. Linux will not even see temps or setpoints without a driver. Even if the OS can see those points, the it has no knowledge of where the sensors are, where the components are, and how everything effects everything else. By default linux throttles the CPU. The responsibility for tuning temps further lies with the system integrator! You are being too biased to admit it, but even microsoft windows has a suboptimal governor without manufacturer drivers.
https://github.com/linux-surface/linux-surface/issues/221
(my emphasis)
No, I don’t think the OS should be throttling games at all. I strongly dislike the idea of hardcoding lists of games/apps into the OS! We’ve been running games for decades without this, there’s no reason to introduce it now unless it’s an option to let the user enable power saving mode. Many games already limit themselves to a fixed FPS and reduce FPS naturally. IMHO there’s no need for over engineering!
The onus is on you.to provide sources for what you say.
That’s idiotic, not even samsung did that. Anyways let’s pretend that the performance did drop by 50% at the two hour mark. Who the hell cares!? Does that mean that the OS should artificially limit the game to half performance for the first two hours? That’s stupid.
Well I already did that and the benchmark was stable. The evidence still shows that samsung is hurting performance.
Brendan I normally respect you, but right now you are being so dogmatic with your hatred of linux taking the spotlight that I don’t think there’s any possibility of being able to discuss samsung’s throttling issue rationally. So I move that we just agree to disagree.
This is what I’ve been saying. For shorter bursts ramping up to 10 times higher power consumption is fine, and for longer bursts (in systems without fans, etc) it is not fine, and if you don’t care what the load is you can’t do the right thing.
It’s not biased, it’s just that we’re talking about Android. Had it have been a Microsoft phone (or an Apple phone) I would’ve been bashing Microsoft (or Apple) in exactly the same way for exactly same “characteristics of the load are ignored for all power management decisions” mistake. Saying “Linux is shit” does not in any way exclude the possibility that other operating systems are also shit.
Too bad. There are only 3 possibilities: the system has fans (and OS can increase fan speed/s instead); the game is “low load” and can be played without throttling (e.g. single-player text adventures); or it must be throttled sooner or later whether you like it or not (and it’s only a question of when and how much)
I’d be willing to bet that Samsung did proper testing (while monitoring performance and temperature) for multiple apps in their list (but then probably extrapolated results to similar apps to save time instead of testing each one individually). I’d also assume they tested on recent version/s of their hardware (possibly without caring much about older hardware, and possibly only caring about Galaxy S22).
I simply don’t trust your benchmark. For lots of phones (iPhone, Xiaomi Mi , OnePlus 9 Pro and Samsung S21, …), and for lots of tablets and laptops, you do get the “high performance initially followed by severe throttling after a while” behavior I expect. Maybe your phone fails to get high performance initially for some reason.
Brendan,
You made it out to be a linux specific problem. If you think it’s problem in general you should have said so.
A lot of apps *don’t* have to be throttled at all. Games that are clamped at a max FPS for example. Throttling is only necessary when the temps get too high in which case performance can be gradually throttled. There’s no need to make it terribly complicated.
Ok, but you don’t get to use this as an excuse when I asked you to provide test cases over and over and over again. Feel free to run the tests yourself.
The evidence *still* point to samsung’s throttling hurting performance.
This is the same “wrong thinking” that causes almost every OS to suck for continuous loads; and it’s the same “wrong thinking” that various research papers (and likely Samsung’s throttling of 100000 apps) is trying to fix.
The fact is that an initial “performance burst” (from when phone is cool at the start until it gets too hot and must be throttled anyway) has very poor “perf/watt”, causes annoying and pointless performance variation for users, causes the phone to heat up and leakage currents to increase leading to sustained worse perf/watt and worse performance during the later “throttling that must be done anyway” period, causes pointless and unnecessary user discomfort (higher “skin temperature”), causes pointless and unnecessary battery life issues, and may cause longevity issues (heat/cool cycles cause expansion/contraction at mechanical joints that may cause premature hardware failures).
It is significantly better (for all of those reasons) to pre-determine how much throttling must be done anyway and throttle by that amount from the beginning, with the very specific goal of deliberately avoiding the pointless and unnecessary initial “performance burst” that ruins everything.
Note that I do think Samsung’s approach is extremely silly – a lot of error prone human effort spent creating and maintaining a list that still fails to provide “how much throttling” (and only provides a “yes or no”) and fails to take into account different phone’s different characteristics. It should (in theory) be possible to auto-determine the right amount of throttling (e.g. the first time an app is run; start by assuming it doesn’t need throttling, realize it’s a continuous load within a fraction of a second, and then switch to dynamically determining the right amount of throttling by refining “guesses” so that the current “guess” becomes very good after a few seconds; then when the app is closed record the “right amount of throttling” value for the app so that it can be used again the next time the same app is run).
Of course a system that dynamically auto-detects the right amount of throttling would still suck (it’d just suck less than either Samsung’s work-around or not doing anything to work-around the problem); primarily because it assumes that there’s only one load at a time (and that you’re not running a mixture of different types of loads from multiple apps and services at the same time). That just brings us back to “single coherent system” (with schedulers making decisions during task/load switches).
Brendan,
If half of what you said were true, computers would be unusable today.
With an appropriate temperature->performance feedback loop it won’t get “too hot”. The hardware gives all it can, but no more. If it does get “too hot”, then that’s a clear bug in feedback loop that should be fixed by the system integrator. It really isn’t rocket science.
If all of what I said is true; then we’d have inefficient systems with people complaining about throttling and (some) researchers and (some) vendors trying to fix the problem; which is exactly what we do have today (for almost all systems without fans).
Describe “an appropriate temperature->performance feedback loop” that simultaneously:
a) allows “extra fast, even when the device is already warm/hot” (for non-continuous loads where the load is extremely brief and it’s both desirable and achievable), and
b) prevents “extra fast” (for continuous loads where it’s neither desirable nor achievable for long).
Brendan,
Give up the lie already, Samsung was caught with it’s pants down. By throttling they made their android devices perform like far older android devices that were not throttling. I’m not kidding the evidence for this has been established. You’re only denying it in order to push a narrative that you have steadfastly refused to provide any evidence or test cases for. I don’t know how you expected not to be called out for that, but I did call you out and now you’re being all trumpian about how you are right and the facts are wrong.
The evidence is still clear that samsung’s throttling significantly hurts performance and if you want to live in denial then it’s your prerogative but don’t expect anyone rational to agree with you.
https://www.vertech.com/blog/understanding-pid-loop-process-control-part-1
https://www.setra.com/blog/what-is-a-pid-loop
Samsung’s work-around sucked; but that does not mean the problem they’re trying to work around doesn’t exist.
Note that Samsung already has a fix for their work-around; where people are saying things like “But we still expect some form of throttling to happen on the Galaxy S22 even after the fix is applied. That’s because the phone will still have to prevent overheating during extended gaming sessions.” (from https://bgr.com/tech/galaxy-s22-throttling-fix-download-released/ ); specifically because the problem still exists and still needs to be worked around (despite your continued attempts to ignore the problem).
I have never denied that Samsung’s work around sucked.
I have not “steadfastly refused” to provide any evidence that the problem they’re trying to work around actually exists (I provided full explanations, descriptions and reasoning that remains unrefuted; in addition to evidence).
What I have been “steadfastly refusing” is your repeated non-genuine and juvenile attempt to cause an irrelevant distraction by asking for an unnecessary “sources”. This is primarily because I’ve been trying to be polite rather than just call you a big deluded ignorant fool (which honestly, in hindsight, probably would’ve been a lot more effective). If you were willing to remove your head from your arse, were willing to actually think, and/or weren’t too lazy to care; you’d have noticed an abundance of evidence (proving the problem that Samsung are trying to solve does exist) within easy reach, including:
… advice to help people suffer less from the “FPS drop” problem you refuse to admit exists for smartphone games: https://frameboxxindore.com/other/how-do-i-fix-fps-drop-on-android.html
..the problem on Apple’s iPhones: https://hothardware.com/news/ul-benchmarks-3dmark-wildlife-stress-test-benchmark-iphone-android
…the problem on tablet/laptop: https://www.notebookcheck.net/Opinion-It-s-time-we-talked-about-throttling-in-reviews.234232.0.html
..the problem for Office 365 everywhere: https://www.avepoint.com/blog/office-365/office-365-throttling/
..about half of the research papers looking into power management on smartphones (e.g. the paper I already provided, which also serves as proof that smart people have understood the problem and have been trying to find solutions for at least a decade now)
..the fact that various benchmarks added new “stress tests” specifically so that people can see/measure the problem
Is it still considered rude to respond to mentally challenged people with a sarcastic “slow clap”?
We are not arguing about whether or not Samsung’s work-around is good/bad (we’ve agreed that it’s bad from the beginning). We’re arguing about whether there’s a problem that should be fixed and how it should be fixed (where all of the evidence points to me being right regardless of how much difficulty you have trying to accept it or how hard you try to cause distractions).
Yet again, you’ve attempted to distract from the issue by feigning an inability to understand simple things. A feedback loop like this works; IF AND ONLY IF YOU KNOW THE RIGHT TARGET. My question was how a simple feedback loop determines the right target (when the right target is different for short bursts and continuous loads).
@Alfman
I hope you understand that suppressing criticism does not make you less wrong; it only makes you seem cowardly.
Not that it matters. You will always know what you’ve done (and I will always know what you’ve done), and nobody else is likely to read this far down comments on an article that’s become so old.
Soon Samsung’s patch will roll out; likely reducing the amount of throttling a little while keeping the same fundamental approach, and likely giving users the option to disable it. People (Samsung S22 users) will see for themselves that “fast for 30 seconds” makes things worse and leave Samsung’s “preventative throttling” service enabled. Then other vendors will follow Samsung’s lead.
Essentially; this is the beginning of the end for the misguided “simple feedback loop alone” approach (at least for continuous loads on systems without fans); regardless of how much you want to ignore everything I said over the last week or so (the reasons for it, etc).
Brendan,
Great, if it’s optional I have no issue with people being able to decide between power savings and performance. I think 50% throttling is too steep so hopefully it’s adjustable, but as long as they can legitimately get the full performance without jumping through hoops then I don’t have a problem with it.
It isn’t misguided. There just isn’t a better generic solution. You’re whole notion that you can save up the heat capacity for when you need it implicitly requires the OS to know things that it cannot know. Things are so dynamic that even different runs of the same program may be unpredictable: when you are in game and look to the west, you may see one scene, but look to the east and see another, Naively applying 50% fixed throttling can end up killing the FPS of a complex scene while NOT helping the FPS of a simple scene that’s already reaching max FPS. Maybe the game needs heavy CPU bursts during an impactful event (say an explosion) but otherwise runs a sustainable load. If you force the application to be throttled during the explosion, you’ll hurt the game’s performance during impactful events when the application actually needs it most.
So yeah, I’m pretty sure samsung knows all of this. 50% throttling isn’t to improve performance, it’s to save battery life. But if you want to use it thinking it will improve performance, be my guest.
It’s misguided (has multiple disadvantages for continuous loads – worse performance, worse per/watt, higher temps, …). It does require information that crusty pieces of crap (e.g. Linux) didn’t care enough to have previously; but the idea that an OS can’t have this information is absurd and trivially proven false.
Specifically; the could come from a (relatively horrible) “list of 100000 apps” (as Samsung is doing), or by auto-detecting the right values quickly and remembering them for next time (as I described previously), or from information/hints explicitly provided by the app developer as part of their package (and/or executable file format), or derived from thread priorities that are explicitly provided by app developer, or anything else I’ve neglected, or any combination of multiple sources.
Do you honestly think that “Get the phone as hot as possible as quickly as possible so that after the first ~30 seconds you can’t improve performance temporarily to handle temporary increases in load” is a valid solution to (relatively rare) games that have fluctuating load (that don’t cause constant load by trying to pump out as many frames per second as possible)?
The ideal/right approach for this is….. the approach I described many days ago (that I don’t think you read or understood), where the game has a target temperature (e.g. 45 degrees) but the scheduler is free to boost or nerf performance while trying to maintain the target temperature (and where “lower game load” causes actual temperature to be lower than the game’s target and allows the scheduler to boost performance if load increases).
If it was about battery life (and not performance and temperature) then the throttling would be disabled when the phone is plugged into a charger. That’s not what Samsung are doing because that’s not what the throttling is for. I’d even go further and say Samsung has no reason to care (people don’t expect battery to last as long when playing resource hungry games) and every reason to not care (it makes marketing better because benchmarks and reviews ignore battery life).
I’m pretty sure Samsung knows all of this; and they’re continuing to use their existing approach (just with “minor tweaks for teething problems”) despite the public backlash (from their earlier attempt), even though it’d be a lot easier for them to throw the whole idea away (and avoid having to be constantly maintaining a large list of apps); because they actually understand their hardware, physics, the research, etc; and want to fix “performance vs. temperature” problems that almost everyone in the industry are aware of (and have been aware of for at least a decade) that have nothing to do with battery life at all.
Brendon,
The problem is that OS throttling explicitly harms performance at times of high usage. You’re hoping that the throttling will only harm the performance during less important loads, but statistically the exact opposite is more likely. The most severe throttling is likely to take place when an application needs the most CPU power. If the OS had some kind of API to request more power CPU above baseline load, then maybe you could make the case for shaping the CPU load using said API. But absent that the OS will not know when an application needs more power or the priority of code executing within the application.
The majority of games can throttle themselves by governing their own FPS. Most importantly it doesn’t require over-engineered heuristics in the OS to guess or predict when an application needs power. Not only does the OS have no way to predict load, but for interactive applications the power profile can easily vary from one run to the next because the user is non-deterministic.
Getting hot isn’t the goal but a byproduct of productive work. Fluctuating load is not rare, it’s the norm. If you over-engineer the OS to artificially force a load to be stable throughout a game’s runtime you’re going to end up shifting the natural jitter from the CPU load domain “meh who cares” into the FPS domain “this looks bad”. Forced throttling necessarily forces FPS down in demanding scenes. Meanwhile when the game’s load is naturally lowest the FPS is going to skyrocket simply because the program has less work to do. Sure your throttling can make the CPU consume a fixed amount of power across it’s lifetime. But that’s a non-goal that ends up amplifying the the conditions for titles that drastically speed up during basic scenes and crawl during complex ones. Sometimes this cannot be helped because the CPU/GPU just are maxed out, but you’d be recreating these problems artificially and unnecessarily when they aren’t maxed out.
This is already how a PID loop works. The system builders define the system’s max temps and regulating the hardware’s performance using one or more PID loops. The OS can set a lower target if desired, but we should be clear that it will decrease performance. It may be a perfectly valid tradeoff., but not all users want this tradeoff.
I don’t know whether or not they do. Conceivably Samsung may not have wanted users to find out about their throttling at all. If users discovered that plugging it in makes it faster, they would have been quickly exposed. Anyways we both agree that Samsung should make it optional and that’s all that really matters. If some users think throttling helps them, then they can turn it on. Why not.
No; the problem is that the relationship between performance and heat is non-linear. You can split this into 4 parts: leakage current (which increases with temperature and voltage), “influx current” when switching the state of transistors (which increases with CPU frequency – more transistors changing state more often), voltage (which has to be increased when frequency is increased), and battery efficiency (battery’s internal resistance means that higher current when discharging causes the battery itself to generate heat).
In other words, “twice as fast” probably means about 4 times more heat generated. This is beneficial for brief periods of time (e.g. handling user input and returning to an idle state) because you have ages to get rid of the heat; and completely and utterly idiotic for continuous loads because you do not have time to get rid of the heat. The result is that an OS designed by a fool will screw everything up for the first 30 seconds or so and then hit a “too hot” threshold causing a severe performance drop, and then suffer (high temps, no headroom for “temporary boost where justified” because you’re already at higher temp, higher leakage, worse performance, worse battery life) for the next “many hours” because the OS screwed everything up initially.
The most severe throttling takes place when the OS screwed everything up by allowing the phone to get too hot for no sane reason whatsoever, and then sees a temporary increase in load and can’t handle it because the phone is already too hot, and then has to throttle hard (to avoid an over-temperature condition) because the OS let the phone get too hot for no sane reason whatsoever.
If the OS isn’t aware of it this would cause a worst case pattern – “quadruple heat”, then idle waiting for next frame, then “quadruple heat”, then idle waiting for next frame, then …
Assuming a 50% duty cycle (quadruple heat half the time + no heat half the time) this would work out to an average of twice the heat for the same performance/frame rate (compared to keeping the game throttled just enough to not have idle time).
Yes; the problem is that for traditional operating systems the PID loop only has one target (e.g 80 degrees) and that target is wrong for continuous loads (and designed for brief bursty loads, the “race to idle” stuff, where the target is right).
The ideal/right approach for this is….. the approach I described many days ago (that I don’t think you read or understood), where the PID loop has different targets for different types of loads (e.g. 80 degrees for high priority/bursty loads, 40 degrees for medium priority/continuous loads, …).
Note 1: This approach wouldn’t necessarily be ideal – it’d still have some “too fast initially” (e.g. as the phone heats from ambient to the game’s 40 degree target) that would be more pronounced/worse if the scheduler tries to achieve the target temperature too quickly.
Note 2: The other part of this was tying it to the scheduler, so it works properly for “multi-app” and background services (e.g. something that polls a social media site for notifications/alerts once per second while a game is running would cause a brief boost to an 80 degree target once per second, and wouldn’t be throttled just because something unrelated is throttled).
Brendan,
I realize the physics of it, but that’s the nature of the beast. I think we’re in agreement about this. Throttling decreases power & heat while extending battery duration. These are all good things BUT it’s a tradeoff with performance and frame rates. What is an acceptable tradeoff? It’s almost completely subjective and dependent on local circumstances. If I’m not around a power source then battery life becomes much more important, but if I have access to power I may want full performance. It’s no big deal either way but it’s wrong for the OS to presume that I always want throttling over performance.
No. If the system integrator did a good job of tuning their PID loops then the components will not reach “too hot”. An application that puts full load on the CPU will push it up to the max temps and then the temperature rise will stop. There is no implied “severe performance drop”. It *will* drop to the max sustainable performance level and that’s it.
If you meant “severe performance drop to the max sustainable performance” then it’s already implied that long running processes are going to reach that limit anyways. These numbers are purely illustrative, but let’s say it starts at 50FPS and drops to 30FPS after 30s. (BTW I did not see such dramatic shifts under 3dmark, but lets assume it for the sake of discussion). Throttling can slow down how quickly we reach max temps, but it cannot ultimately increase the max sustainable performance over 30FPS with no throttling. In fact any throttling after we reach max temps implies dropping below the 30FPS that can be sustained without throttling.
Again, the device should not become “too hot” with correctly tuned PID loops. If it is becoming too hot outside of small margins of error, then it’s a problem the manufacture needs to fix since that shouldn’t be happening in the first place regardless of what programs are running.
Just think if your case fans had a binary on/off setting. They would kick on to full blast for a moment and then turn off for a moment and alternate between these two states indefinitely. Would it work? Maybe. Is it a good solution? Hell no. Likewise a poorly tuned car might have a fuel injector alternating between too much fuel/too little fuel. Is that a problem? Yes. But the point is we know how to solve it. A PID loop is about making small corrections proportional to the size of the error. So if a phone were making huge dramatic adjustments in response to negligible changes in temperature between frames, then the manufacturer needs to fix their governor.
Granted many modern CPUs have multiple temperature setpoints, but none of that changes the fact that it’s the manufacture’s responsibility to account for that. On x86 this gets implemented in the BIOS. On ARM there have been lots of pseudo standards but ARM themselves have been pushing for “SCMI”.
https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Power_and_Performance_Management_SCMI_White_Paper.pdf?revision=9ee0a9f8-fce7-4584-bd1a-fa018ec9a283
A 40 degree gap seems really extreme. It takes my phone ~30s to go up by 15deg under full load and it’s non linear. It would likely take 6 minutes to reach 80C and drop back down to 40C…so I have a question: In what scenario do you consider such high temperatures to be reasonable before dropping to 40C for sustained loads?
Regardless of the “why” though, it’s still the implicit responsibility of the manufacturers to get the tuning right whatever it entails. From the game’s point of view, they’re typically designed to use all the performance available until max FPS, and I’m convinced that’s the most practical way to do it since the OS doesn’t know what the application needs and when.