[android-developers] Re: Background processes not being CPU-limited?
Mike, I'm with Robert on this one. Not because you're wrong -- you're not. But because most users don't really want to think about this stuff. I think that if they were asked if they want to enter game mode -- a single choice -- and they can either accept or decline, then users will either accept, or decline. If they really want to maximize smoothness, they'll opt for game mode. If they want to optimize for utility, they'll decline. I really think that's enough decision for most people. Maybe power users would want to dive under the hood at tweak some parameters. But I'm about as power a user as you could imagine -- and this would be good enough for me. Were I also a game addict, perhaps it wouldn't be. But I think most people are willing to make the trade- off -- if I don't want to miss an SMS message right now, I'll settle for the reduced game experience. If I'm not expecting anything, and want a nice game, I'll opt for game mode. On Apr 19, 5:47 pm, mike enervat...@gmail.com wrote: On 04/19/2010 05:37 PM, Robert Green wrote: Mike, The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. I'm not saying I know what should stay and what should go. I don't. I just know what causes the issue and what would work to provide a good experience at the cost of flipping the phone effectively into airplane mode but with the ability to receive calls. Yes, that's why a solution to this is not as straightforward as just saying phone alerts are exempt, because neither you nor google have any clue if that actually matches users' *actual* alert prioritization. And it's quite possible that trying to sort that out lies madness. I'm afraid that users really do want to have their cake and eat it too. Fortuntately Moore's Law is on our side from going completely crazy. Mike On Apr 19, 7:07 pm, mikeenervat...@gmail.com wrote: On 04/19/2010 04:56 PM, Robert Green wrote: Bob, The idea is that an exclusive mode would cater to apps that are never idle. Games are never idle. They constantly update and draw. There are other apps that work that way as well and having a more guaranteed consistent amount of CPU available for those simulations would probably be very favorable with consumers. I know I'd personally say Yes if a game prompted me to go into an optional game mode during the duration of play. If you're playing a game, you don't need background tasks running. All you would need is to receive a phone call. It is still a phone, after all. :) I get off the bus right here. At the point that you aren't willing to say that it's not a phone while you're playing a game or whatever this mode is, you're setting yourself up for failure. Why not an IM from your boss wondering if you're working or playing game? What about that alert that comes in from the baby cam that says that the loinfruit is unhappy? The problem here is that you are presuming to know users' prioritiztion of alerting, etc, based solely on tradition. That is bound to fail and fail and fail as the generations who think of it as being a phone afterall dwindle and eventually die out. It isn't a phone. It's a general purpose computer with some telephony functions on it. So if there is going to be some mode that allows you to drown out *every* other bit of background/alerting that's one thing. But if you're going to start making exceptions -- which I think you must -- you've opened up a much larger problem. Mike If the user is expecting an email/text/other notification, they could opt not to go into game mode and the game will have its normal bits of choppiness. It really could be as simple as that. After the exclusive mode is exited, paused services are resumed and all is happy on the device. On Apr 19, 6:28 pm, Bob Kernsr...@acm.org wrote: Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to
[android-developers] Re: Background processes not being CPU-limited?
Probably out of context but this issue looks similar to the thread shown below. http://groups.google.com/group/android-developers/browse_thread/thread/220248cd27e281c6/96ec2dd63c6850ab?lnk=gstq=AUDIO+STUTTERING#96ec2dd63c6850ab Audio stuttering problems in android.When somthing cpu intensive is running in foreground or background. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Background processes not being CPU-limited?
Perhaps the issue is simply more fundamentally difficult than scheduling can fix and an exclusive mode (for games and other real- time apps where users don't care about having their RSS feed up to date, etc) is in order? On Apr 19, 5:32 pm, Mark Murphy mmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can get a background process to significantly impact the foreground process, more than would seem to be possible if the background process was, indeed, CPU-limited. Details, including sample code, can be found in the issue I opened that was promptly closed: http://code.google.com/p/android/issues/detail?id=7844 Clearly, the failed issue was my fault, for not running around screaming about bugs in Android and not jumping to conclusions. Anyway, if anyone else has any ideas on how we can prove whether background processes are CPU-limited -- and if so, how come that's not helping much -- please respond to this thread or shoot me an email off-list if you prefer. And, I apologize to anyone who took my prior advice regarding this CPU utilization, as it looks like I screwed up big-time on that analysis. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Background processes not being CPU-limited?
I'll repeat my question from the bug: So if this defect is not a defect, what are the plans to make it so that our games don't have periods of lag caused by greedy background processes that we can't control? As it stands, gaming on Android is a laggy experience and this is one of the issues. On Apr 19, 5:32 pm, Mark Murphy mmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can get a background process to significantly impact the foreground process, more than would seem to be possible if the background process was, indeed, CPU-limited. Details, including sample code, can be found in the issue I opened that was promptly closed: http://code.google.com/p/android/issues/detail?id=7844 Clearly, the failed issue was my fault, for not running around screaming about bugs in Android and not jumping to conclusions. Anyway, if anyone else has any ideas on how we can prove whether background processes are CPU-limited -- and if so, how come that's not helping much -- please respond to this thread or shoot me an email off-list if you prefer. And, I apologize to anyone who took my prior advice regarding this CPU utilization, as it looks like I screwed up big-time on that analysis. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Background processes not being CPU-limited?
Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to normal. It would ALSO boost it for a *minimum* period of time. The idea being that if you'd just done user interaction, then perhaps completing the work implied by that interaction would also be of interest to the user. The equivalent here would be to boost priority for any incoming events on the main thread, up through some number of scheduler quanta. This all worked very well, but wasn't a panacea. The real fix was usually to write the application better. Another factor to figure in here is scheduling quanta. When the foreground breaths, it allows the background to run. There will always be a minimum amount of time the scheduler will allocate to run anything it does decide to run. Otherwise, you'd waste too much time switching back and forth! Anyway, I do agree with Robert Green that giving the scheduler explicit information to aid it in policy decisions would be a good thing. You still have to consider how to handle 'exclusive mode -- do you shut out non-foreground tasks entirely, even when the foreground is idle? Because you may then be blocking the foreground for a scheduling quantum? On Apr 19, 3:32 pm, Mark Murphy mmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can get a background process to significantly impact the foreground process, more than would seem to be possible if the background process was, indeed, CPU-limited. Details, including sample code, can be found in the issue I opened that was promptly closed: http://code.google.com/p/android/issues/detail?id=7844 Clearly, the failed issue was my fault, for not running around screaming about bugs in Android and not jumping to conclusions. Anyway, if anyone else has any ideas on how we can prove whether background processes are CPU-limited -- and if so, how come that's not helping much -- please respond to this thread or shoot me an email off-list if you prefer. And, I apologize to anyone who took my prior advice regarding this CPU utilization, as it looks like I screwed up big-time on that analysis. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Background processes not being CPU-limited?
Bob, The idea is that an exclusive mode would cater to apps that are never idle. Games are never idle. They constantly update and draw. There are other apps that work that way as well and having a more guaranteed consistent amount of CPU available for those simulations would probably be very favorable with consumers. I know I'd personally say Yes if a game prompted me to go into an optional game mode during the duration of play. If you're playing a game, you don't need background tasks running. All you would need is to receive a phone call. It is still a phone, after all. :) If the user is expecting an email/text/other notification, they could opt not to go into game mode and the game will have its normal bits of choppiness. It really could be as simple as that. After the exclusive mode is exited, paused services are resumed and all is happy on the device. On Apr 19, 6:28 pm, Bob Kerns r...@acm.org wrote: Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to normal. It would ALSO boost it for a *minimum* period of time. The idea being that if you'd just done user interaction, then perhaps completing the work implied by that interaction would also be of interest to the user. The equivalent here would be to boost priority for any incoming events on the main thread, up through some number of scheduler quanta. This all worked very well, but wasn't a panacea. The real fix was usually to write the application better. Another factor to figure in here is scheduling quanta. When the foreground breaths, it allows the background to run. There will always be a minimum amount of time the scheduler will allocate to run anything it does decide to run. Otherwise, you'd waste too much time switching back and forth! Anyway, I do agree with Robert Green that giving the scheduler explicit information to aid it in policy decisions would be a good thing. You still have to consider how to handle 'exclusive mode -- do you shut out non-foreground tasks entirely, even when the foreground is idle? Because you may then be blocking the foreground for a scheduling quantum? On Apr 19, 3:32 pm, Mark Murphy mmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can get a background process to significantly impact the foreground process, more than would seem to be possible if the background process was, indeed, CPU-limited. Details, including sample code, can be found in the issue I opened that was promptly closed: http://code.google.com/p/android/issues/detail?id=7844 Clearly, the failed issue was my fault, for not running around screaming about bugs in Android and not jumping to conclusions. Anyway, if anyone else has any ideas on how we can prove whether background processes are CPU-limited -- and if so, how come that's not helping much -- please respond to this thread or shoot me an email off-list if you prefer. And, I apologize to anyone who took my prior advice regarding this CPU utilization, as it looks like I screwed up big-time on that analysis. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group
Re: [android-developers] Re: Background processes not being CPU-limited?
On 04/19/2010 04:56 PM, Robert Green wrote: Bob, The idea is that an exclusive mode would cater to apps that are never idle. Games are never idle. They constantly update and draw. There are other apps that work that way as well and having a more guaranteed consistent amount of CPU available for those simulations would probably be very favorable with consumers. I know I'd personally say Yes if a game prompted me to go into an optional game mode during the duration of play. If you're playing a game, you don't need background tasks running. All you would need is to receive a phone call. It is still a phone, after all. :) I get off the bus right here. At the point that you aren't willing to say that it's not a phone while you're playing a game or whatever this mode is, you're setting yourself up for failure. Why not an IM from your boss wondering if you're working or playing game? What about that alert that comes in from the baby cam that says that the loinfruit is unhappy? The problem here is that you are presuming to know users' prioritiztion of alerting, etc, based solely on tradition. That is bound to fail and fail and fail as the generations who think of it as being a phone afterall dwindle and eventually die out. It isn't a phone. It's a general purpose computer with some telephony functions on it. So if there is going to be some mode that allows you to drown out *every* other bit of background/alerting that's one thing. But if you're going to start making exceptions -- which I think you must -- you've opened up a much larger problem. Mike If the user is expecting an email/text/other notification, they could opt not to go into game mode and the game will have its normal bits of choppiness. It really could be as simple as that. After the exclusive mode is exited, paused services are resumed and all is happy on the device. On Apr 19, 6:28 pm, Bob Kernsr...@acm.org wrote: Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to normal. It would ALSO boost it for a *minimum* period of time. The idea being that if you'd just done user interaction, then perhaps completing the work implied by that interaction would also be of interest to the user. The equivalent here would be to boost priority for any incoming events on the main thread, up through some number of scheduler quanta. This all worked very well, but wasn't a panacea. The real fix was usually to write the application better. Another factor to figure in here is scheduling quanta. When the foreground breaths, it allows the background to run. There will always be a minimum amount of time the scheduler will allocate to run anything it does decide to run. Otherwise, you'd waste too much time switching back and forth! Anyway, I do agree with Robert Green that giving the scheduler explicit information to aid it in policy decisions would be a good thing. You still have to consider how to handle 'exclusive mode -- do you shut out non-foreground tasks entirely, even when the foreground is idle? Because you may then be blocking the foreground for a scheduling quantum? On Apr 19, 3:32 pm, Mark Murphymmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can get a background process to significantly impact the foreground process, more than would seem to be possible if the background process was, indeed, CPU-limited. Details, including sample code, can be found in the issue I opened that was promptly closed: http://code.google.com/p/android/issues/detail?id=7844 Clearly, the failed issue was my fault, for not running around screaming about bugs in Android and not jumping to conclusions. Anyway, if anyone else has any ideas on how we can prove whether background processes are CPU-limited -- and if so, how come that's not helping much -- please
[android-developers] Re: Background processes not being CPU-limited?
Mike, The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. I'm not saying I know what should stay and what should go. I don't. I just know what causes the issue and what would work to provide a good experience at the cost of flipping the phone effectively into airplane mode but with the ability to receive calls. On Apr 19, 7:07 pm, mike enervat...@gmail.com wrote: On 04/19/2010 04:56 PM, Robert Green wrote: Bob, The idea is that an exclusive mode would cater to apps that are never idle. Games are never idle. They constantly update and draw. There are other apps that work that way as well and having a more guaranteed consistent amount of CPU available for those simulations would probably be very favorable with consumers. I know I'd personally say Yes if a game prompted me to go into an optional game mode during the duration of play. If you're playing a game, you don't need background tasks running. All you would need is to receive a phone call. It is still a phone, after all. :) I get off the bus right here. At the point that you aren't willing to say that it's not a phone while you're playing a game or whatever this mode is, you're setting yourself up for failure. Why not an IM from your boss wondering if you're working or playing game? What about that alert that comes in from the baby cam that says that the loinfruit is unhappy? The problem here is that you are presuming to know users' prioritiztion of alerting, etc, based solely on tradition. That is bound to fail and fail and fail as the generations who think of it as being a phone afterall dwindle and eventually die out. It isn't a phone. It's a general purpose computer with some telephony functions on it. So if there is going to be some mode that allows you to drown out *every* other bit of background/alerting that's one thing. But if you're going to start making exceptions -- which I think you must -- you've opened up a much larger problem. Mike If the user is expecting an email/text/other notification, they could opt not to go into game mode and the game will have its normal bits of choppiness. It really could be as simple as that. After the exclusive mode is exited, paused services are resumed and all is happy on the device. On Apr 19, 6:28 pm, Bob Kernsr...@acm.org wrote: Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to normal. It would ALSO boost it for a *minimum* period of time. The idea being that if you'd just done user interaction, then perhaps completing the work implied by that interaction would also be of interest to the user. The equivalent here would be to boost priority for any incoming events on the main thread, up through some number of scheduler quanta. This all worked very well, but wasn't a panacea. The real fix was usually to write the application better. Another factor to figure in here is scheduling quanta. When the foreground breaths, it allows the background to run. There will always be a minimum amount of time the scheduler will allocate to run anything it does decide to run. Otherwise, you'd waste too much time switching back and forth! Anyway, I do agree with Robert Green that giving the scheduler explicit information to aid it in policy decisions would be a good thing. You still have to consider how to handle 'exclusive mode -- do you shut out non-foreground tasks entirely, even when the foreground is idle? Because you may then be blocking the foreground for a scheduling quantum? On Apr 19, 3:32 pm, Mark Murphymmur...@commonsware.com wrote: We were told that, as of Android 1.6, background processes were put in a Linux process scheduling class that limited how much CPU they would use. A few weeks ago, I ran a benchmark test that seemed to validate this claim. I have run more tests, and I am no longer confident in my earlier conclusion. I can
Re: [android-developers] Re: Background processes not being CPU-limited?
Robert Green wrote: The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. That's what the background process scheduling class was supposed to do, or so I thought. Another way to help skin the cat is to provide frameworks for intelligent background processing. Think of it as providing an iPhone-style multi-tasking layer. Apps written to use those can be guaranteed (-ish) to behave well. Apps that ignore the frameworks and roll their own background processing can cause problems, and sufficient blame APIs can help users identify the problematic stuff and get rid of the apps, just as they get rid of apps that consume too much storage or use too much battery. That won't help where the OS itself is the one chewing up the CPU cycles, of course. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy _Beginning Android 2_ from Apress Now Available! -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Background processes not being CPU-limited?
On 04/19/2010 05:37 PM, Robert Green wrote: Mike, The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. I'm not saying I know what should stay and what should go. I don't. I just know what causes the issue and what would work to provide a good experience at the cost of flipping the phone effectively into airplane mode but with the ability to receive calls. Yes, that's why a solution to this is not as straightforward as just saying phone alerts are exempt, because neither you nor google have any clue if that actually matches users' *actual* alert prioritization. And it's quite possible that trying to sort that out lies madness. I'm afraid that users really do want to have their cake and eat it too. Fortuntately Moore's Law is on our side from going completely crazy. Mike On Apr 19, 7:07 pm, mikeenervat...@gmail.com wrote: On 04/19/2010 04:56 PM, Robert Green wrote: Bob, The idea is that an exclusive mode would cater to apps that are never idle. Games are never idle. They constantly update and draw. There are other apps that work that way as well and having a more guaranteed consistent amount of CPU available for those simulations would probably be very favorable with consumers. I know I'd personally say Yes if a game prompted me to go into an optional game mode during the duration of play. If you're playing a game, you don't need background tasks running. All you would need is to receive a phone call. It is still a phone, after all. :) I get off the bus right here. At the point that you aren't willing to say that it's not a phone while you're playing a game or whatever this mode is, you're setting yourself up for failure. Why not an IM from your boss wondering if you're working or playing game? What about that alert that comes in from the baby cam that says that the loinfruit is unhappy? The problem here is that you are presuming to know users' prioritiztion of alerting, etc, based solely on tradition. That is bound to fail and fail and fail as the generations who think of it as being a phone afterall dwindle and eventually die out. It isn't a phone. It's a general purpose computer with some telephony functions on it. So if there is going to be some mode that allows you to drown out *every* other bit of background/alerting that's one thing. But if you're going to start making exceptions -- which I think you must -- you've opened up a much larger problem. Mike If the user is expecting an email/text/other notification, they could opt not to go into game mode and the game will have its normal bits of choppiness. It really could be as simple as that. After the exclusive mode is exited, paused services are resumed and all is happy on the device. On Apr 19, 6:28 pm, Bob Kernsr...@acm.orgwrote: Well, after looking at your code, my suggestion for advice would be: Do no evil! :=) When I implemented something like this on Symbolics Lisp Machines back in the 1980's, I made the scheduling boost for UI actions be for a limited period of time. Perhaps something like that is going on here? I did this, because I found that there would occasionally be some bit of code or other that would do something in a UI thread (typically the mouse-handling thread) that would consume however much CPU was available, while waiting for the INTERESTING things to do to be computed by another thread. And an unlimited priority boost in the UI could tend to make the UI very difficult to debug, as well. So I had a macro that could be wrapped around various components of UI code, that would boost the priority of the UI thread. It would boost it for a maximum period of time, after which it would fall back to normal. It would ALSO boost it for a *minimum* period of time. The idea being that if you'd just done user interaction, then perhaps completing the work implied by that interaction would also be of interest to the user. The equivalent here would be to boost priority for any incoming events on the main thread, up through some number of scheduler quanta. This all worked very well, but wasn't a panacea. The real fix was usually to write the application better. Another factor to figure in here is scheduling quanta. When the foreground breaths, it allows the background to run. There will always be a minimum amount of time the scheduler will allocate to run anything it does decide to run. Otherwise, you'd waste too much time switching back and forth! Anyway, I do agree with Robert Green that giving the scheduler explicit information to aid it in policy decisions would be a good thing. You still have to consider
Re: [android-developers] Re: Background processes not being CPU-limited?
On 04/19/2010 05:43 PM, Mark Murphy wrote: Robert Green wrote: The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. That's what the background process scheduling class was supposed to do, or so I thought Well, until you have a game or some other kind of cpu sink that's right on the hairy edge that does an epic fail when the couple of expected cpu ticks don't materialize. Another way to help skin the cat is to provide frameworks for intelligent background processing. Think of it as providing an iPhone-style multi-tasking layer. Apps written to use those can be guaranteed (-ish) to behave well. Apps that ignore the frameworks and roll their own background processing can cause problems, and sufficient blame APIs can help users identify the problematic stuff and get rid of the apps, just as they get rid of apps that consume too much storage or use too much battery. Or maybe we're just thinking about this the wrong way. Games, etc want to fill to available capacity no matter what the capacity is. There is *no* well behaved background task that will satisfy them. Which is understandable because what game/etc wants to cater to the least common denominator? It won't happen. What might be better is give the game/etc the ability to predict its own degradation so that it can back off its refresh rate, etc. I'll bet that this is a more productive route. Sort of a continuous CPU autosizing loop. Which also has the nice property that it then autoscales to different CPU speeds on different phones. Mike That won't help where the OS itself is the one chewing up the CPU cycles, of course. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Background processes not being CPU-limited?
Mike, If I implemented what you are proposing where the game Backs off as other processes want CPU, the game would choke itself down to 10FPS while your email is being retrieved. Wanna know what kind of user feedback that would create? I'll tell you: 1 star - Game sucks and lags hard. Don't get it. I don't think that's the experience people want. People keep asking for real games on the platform but real games are games with better graphics, better AI, more physics, run faster and smoother, etc... That means even more CPU and GPU. Those games can't have 2000ms periods of time with half CPU like what we get right now with sync on. Users don't know why the game sucks for those 2 seconds. They almost always assume it's the game, not the platform and not the mail app. BTW - I'm generally GPU-bound on these phones anyhow. I hardly use 1-2 milliseconds of CPU on the Droid or N1 and you can still see the choppiness during sync. That says something is WRONG in my book and it's not my max 2ms updates. On Apr 19, 7:59 pm, mike enervat...@gmail.com wrote: On 04/19/2010 05:43 PM, Mark Murphy wrote: Robert Green wrote: The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. That's what the background process scheduling class was supposed to do, or so I thought Well, until you have a game or some other kind of cpu sink that's right on the hairy edge that does an epic fail when the couple of expected cpu ticks don't materialize. Another way to help skin the cat is to provide frameworks for intelligent background processing. Think of it as providing an iPhone-style multi-tasking layer. Apps written to use those can be guaranteed (-ish) to behave well. Apps that ignore the frameworks and roll their own background processing can cause problems, and sufficient blame APIs can help users identify the problematic stuff and get rid of the apps, just as they get rid of apps that consume too much storage or use too much battery. Or maybe we're just thinking about this the wrong way. Games, etc want to fill to available capacity no matter what the capacity is. There is *no* well behaved background task that will satisfy them. Which is understandable because what game/etc wants to cater to the least common denominator? It won't happen. What might be better is give the game/etc the ability to predict its own degradation so that it can back off its refresh rate, etc. I'll bet that this is a more productive route. Sort of a continuous CPU autosizing loop. Which also has the nice property that it then autoscales to different CPU speeds on different phones. Mike That won't help where the OS itself is the one chewing up the CPU cycles, of course. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Background processes not being CPU-limited?
On 04/19/2010 06:16 PM, Robert Green wrote: Mike, If I implemented what you are proposing where the game Backs off as other processes want CPU, the game would choke itself down to 10FPS while your email is being retrieved. Wanna know what kind of user feedback that would create? I'll tell you: 1 star - Game sucks and lags hard. Don't get it. I don't think that's the experience people want. People keep asking for real games on the platform but real games are games with better graphics, better AI, more physics, run faster and smoother, etc... That means even more CPU and GPU. Those games can't have 2000ms periods of time with half CPU like what we get right now with sync on. Users don't know why the game sucks for those 2 seconds. They almost always assume it's the game, not the platform and not the mail app. Well, first let's try to keep all of the different aspects separate. If Mark's previous mail is correct that there really is a scheduling mess, then obviously that needs to be resolved not just for games but for everything. Maybe that's the biggest problem, maybe there's more. BTW - I'm generally GPU-bound on these phones anyhow. I hardly use 1-2 milliseconds of CPU on the Droid or N1 and you can still see the choppiness during sync. That says something is WRONG in my book and it's not my max 2ms updates. What I'm seeing here doesn't seem to add up. The mail app (or IM, or baby cam alerter...) is most likely IO bound, and secondarily CPU bound (if at all). It's certainly not GPU bound. So obviously something is in contention if that's what you're seeing. But what? Until this is really categorized, it's rather premature to call for a give me everything, but... kind of mode, right? Because maybe the problem is just network IO and your app contenting for memory bandwidth. Or something else that wouldn't help even if you did have your mode. The right thing to do here is really find out what's really going on under the hood. That's likely to be extremely painful and time consuming, but its ultimately better to find the problem areas and potentially file bug reports than imagine a mode that isn't likely to be forthcoming because of its own law of unintended consequences. Mike On Apr 19, 7:59 pm, mikeenervat...@gmail.com wrote: On 04/19/2010 05:43 PM, Mark Murphy wrote: Robert Green wrote: The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU. That's what the background process scheduling class was supposed to do, or so I thought Well, until you have a game or some other kind of cpu sink that's right on the hairy edge that does an epic fail when the couple of expected cpu ticks don't materialize. Another way to help skin the cat is to provide frameworks for intelligent background processing. Think of it as providing an iPhone-style multi-tasking layer. Apps written to use those can be guaranteed (-ish) to behave well. Apps that ignore the frameworks and roll their own background processing can cause problems, and sufficient blame APIs can help users identify the problematic stuff and get rid of the apps, just as they get rid of apps that consume too much storage or use too much battery. Or maybe we're just thinking about this the wrong way. Games, etc want to fill to available capacity no matter what the capacity is. There is *no* well behaved background task that will satisfy them. Which is understandable because what game/etc wants to cater to the least common denominator? It won't happen. What might be better is give the game/etc the ability to predict its own degradation so that it can back off its refresh rate, etc. I'll bet that this is a more productive route. Sort of a continuous CPU autosizing loop. Which also has the nice property that it then autoscales to different CPU speeds on different phones. Mike That won't help where the OS itself is the one chewing up the CPU cycles, of course. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
