Page 3 of 3 FirstFirst 123
Results 41 to 52 of 52
  1. #41  
    Yes, -26.
  2.    #42  
    Quote Originally Posted by pslag1 View Post
    Hmmm... it got a little worse. Version -26 without Nodoze dropped 20% in 5 hours. That was w/wifi off, but data (3G) on. Also, I used your perl governor, but with idle = 500MHz.

    Tonight I played with 125Mhz at idle, and it helped a little. Also stopped running crond and turned data off. Without Nodoze = ~ 3%/hr. With Nodoze = ~ 2%/hr.
    That sounds a bit more like it. With nodoze enabled what sort of time differences do you see between sleep/wakeup cycles when ssh'd in? Without wfi it's probably once every 2-3 seconds, with wfi there should be a bigger break.

    The 2-3% is around where it should be but I'm surprised at the results - I would expect it to be the opposite way around. How long were you testing for? If it was only running for an hour or two it might be within the realms of experimental error...

    Also, which carrier are you on and how old is your phone? I'm starting to wonder if there's some distinctly different hardware revs out there.

    Cheers, Steve
  3.    #43  
    Quote Originally Posted by QuarlesLT View Post
    I believe I found an issue with the current kernel. Some Gameloft games (I tried Oregon Trail and NOVA) will not load, they just stay at the Gameloft splash screen. I removed the kernel and they worked again, reloaded the kernel and had the same issue.
    Unfortunately those are for-pay games and I can't justify loading them on my company phone

    Have you seen any free games/demos this has occurred with?

    Cheers, Steve
  4. #44  
    Quote Originally Posted by sbromwich View Post
    That sounds a bit more like it. With nodoze enabled what sort of time differences do you see between sleep/wakeup cycles when ssh'd in? Without wfi it's probably once every 2-3 seconds, with wfi there should be a bigger break.
    Being curious... I switched back to UberK-21 for an overnight test. Turned data off along with uploadd, contextupload, and rdxd. About only thing running was Nodoze. Perl governor at 800/500/125. Over 5 hours the battery lost 2% total... 0.4%/hr.

    I'll flip back to your -26 version and test the sleep/wakeup. And will try to put some more control around the tests and get better data... looks like 'getcoulomb' holds the mAh reported for the battery.

    Caveat: I use the phone as my pager for work, so I have to be a little careful with the testing.

    Quote Originally Posted by sbromwich View Post
    The 2-3% is around where it should be but I'm surprised at the results - I would expect it to be the opposite way around. How long were you testing for? If it was only running for an hour or two it might be within the realms of experimental error...
    It was just an hour or so, so yea, probably not real valid.

    Quote Originally Posted by sbromwich View Post
    Also, which carrier are you on and how old is your phone? I'm starting to wonder if there's some distinctly different hardware revs out there.
    Sprint / launch day (6/6/09). FWIW, it seems to do fine at both 125 and 800MHz.
  5. #45  
    Quote Originally Posted by pslag1 View Post
    Being curious... I switched back to UberK-21 for an overnight test. Turned data off along with uploadd, contextupload, and rdxd. About only thing running was Nodoze. Perl governor at 800/500/125. Over 5 hours the battery lost 2% total... 0.4%/hr.
    As I expected... disregard the 0.4%/hr for now. Watching the actual mAh shows a lot of 'headroom' once the battery reaches "100%". I knew it was there, just didn't realize how much. (And yes, I am looking at the actual % and not the UI %).

    E.g, w/my battery, the % increases +1 for about every 20-30 increase in mAh. But when it reaches 100%, it still has a few hundred mAh of capacity to go. So I most likely took it off the charger when I had a "full" 100 as opposed to an "empty" 100.


    As for the sleep/wakeup cycles, I'm not quite sure I understand your question. With Nodoze running, there is no sleep. So you never get a POWERD-SLEEP message at all. I'll try to catch you in IRC sometime over the weekend to discuss.

    Thanx!
  6. #46  
    Hey!

    This is kind of Off Topic, but since you (and UnixPsycho) clearly know what the heck you're doing, I thought I'd ask.

    According to my fstab, Palm dedicates 16M RAM (tmpfs) to /var/run. I've never seen more than 48K there. It's just pid files. I've dropped it down to 7M on my Pre with zero complications. I'm thinking this doesn't even need to be tmpfs and could just comment out that line and let it use the normal file system for pid files. I'm thinking this would really help keep more RAM free for apps/compcache/etc.

    I am sorrry for the OT post as this has next to nothing to do with your kernels, but also didn't want to bother you and/or Psycho personally for such a (potentially) dumb question.

    Thank you for the time.


    M.
  7.    #47  
    Quote Originally Posted by pslag1 View Post
    As I expected... disregard the 0.4%/hr for now. Watching the actual mAh shows a lot of 'headroom' once the battery reaches "100%". I knew it was there, just didn't realize how much. (And yes, I am looking at the actual % and not the UI %).

    E.g, w/my battery, the % increases +1 for about every 20-30 increase in mAh. But when it reaches 100%, it still has a few hundred mAh of capacity to go. So I most likely took it off the charger when I had a "full" 100 as opposed to an "empty" 100.
    Ahhh, yes. Between that and the "displayed but not actually real" values it's a pain in the proverbial to trace. With the UI% (as you note) it gets even worse. I have no idea why the capacity is so variable, I had it chalked up to being lucky and having a battery with beyond-design capacity, but maybe palm have undermarked the battery as well as underclocking the CPU?

    Quote Originally Posted by pslag1 View Post
    As for the sleep/wakeup cycles, I'm not quite sure I understand your question. With Nodoze running, there is no sleep. So you never get a POWERD-SLEEP message at all. I'll try to catch you in IRC sometime over the weekend to discuss.
    I was a bit ambiguous there, sorry. What I mean was (a) the timing of powerd wakeups on kernels other than mine without nodoze and (B) timing of powerd wakeups on my kernels without nodoze. I'm mostly interested in what the battery life is in more of a stock config - the way nodoze plays around with things is the opposite perspective to how I'm doing things.

    Cheers, Steve
  8. #48  
    Quote Originally Posted by sbromwich View Post
    Unfortunately those are for-pay games and I can't justify loading them on my company phone

    Have you seen any free games/demos this has occurred with?

    Cheers, Steve
    Sorry for the late reply. I just tried it with Asphalt 5 Free and had the issue again.
  9. angiest's Avatar
    Posts
    933 Posts
    Global Posts
    952 Global Posts
    #49  
    Quote Originally Posted by QuarlesLT View Post
    Sorry for the late reply. I just tried it with Asphalt 5 Free and had the issue again.
    I was able to launch heroes of sparta while running -26.
  10. #50  
    Hmmm, I will try Hero of Sparta on mine tomorrow and report back. It may also have to do with my particular CPU as I also can't set it to 125-250mhz at all without an instant freeze.
  11. #51  
    Hero of Sparta worked for me too. I wonder if it's only the games that start with a static splash screen, like Oregon Trail, and not ones that start with a video, like HoS.
  12.    #52  
    Quote Originally Posted by Xanadu73 View Post
    Hey!
    According to my fstab, Palm dedicates 16M RAM (tmpfs) to /var/run. I've never seen more than 48K there. It's just pid files. I've dropped it down to 7M on my Pre with zero complications. I'm thinking this doesn't even need to be tmpfs and could just comment out that line and let it use the normal file system for pid files. I'm thinking this would really help keep more RAM free for apps/compcache/etc.
    tmpfs has swap as backing store so it is not a great concern (and memory is not used until allocated anyway).

    See tmpfs - Wikipedia, the free encyclopedia for details.

    Cheers, Steve
Page 3 of 3 FirstFirst 123

Posting Permissions