Page 29 of 96 FirstFirst ... 1924252627282930313233343979 ... LastLast
Results 561 to 580 of 1910
Like Tree14Likes
  1. #561  
    This is a semantics issue in the label for the item in govnah. I apparently misunderstood the first post on the topic of negative and positive values for it. Simply remove the word draw from the item's label and the confusion is gone. On the topic of graphing on or off I'm not sure how much consumption it adds compared to the polling intervals to the services. The act of keeping the device awake may consume more than the graphing but we will only be able to determine that if the option to turn off graphing were available. I'm running two tests as soon as this is posted to get a baseline consumption with govnah at 1 and 2 second intervals and will proceed to longer intervals from there. These tests will take about 1.5 to 2 hours each to perform for best accuracy.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  2. #562  
    Quote Originally Posted by morrison0880 View Post
    However, when I see "draw", I think of the number being "drawn" from, or subtracted from, the battery. For me, the crux is that the label "draw" is used.
    From the perspective of the RECEIVER of the electrons, yes, you are "gaining" electrons in which case that is a positive measurement. From the perspective of the battery having it's electrons *drawn from* it, it is a negative number. That's what I'm saying.

    You and I are saying the exact same things (even using the same words!), but are looking it at from two different places in the food chain, I think.


    M.
  3. #563  
    Quote Originally Posted by Xanadu73 View Post
    From the perspective of the RECEIVER of the electrons, yes, you are "gaining" electrons in which case that is a positive measurement. From the perspective of the battery having it's electrons *drawn from* it, it is a negative number. That's what I'm saying.

    You and I are saying the exact same things (even using the same words!), but are looking it at from two different places in the food chain, I think.


    M.
    our knowledge of what's happening to the battery is the same, but the ways of describing them are different. As it is, the values shown are opposite what they should be, given the label "current draw".

    Quote Originally Posted by StoneRyno View Post
    This is a semantics issue in the label for the item in govnah. I apparently misunderstood the first post on the topic of negative and positive values for it. Simply remove the word draw from the item's label and the confusion is gone.
    You got it. That would be the correct label for the values it spits out.
    I don't understand the purpose of the line, I don't need to drink to have fun. Great, no one does. But why start a fire with flint and sticks when they've invented the lighter?

    Let's all give thanks to the app that started it all.
    http://forums.precentral.net/homebre...ebrew-app.html
  4. #564  
    Sprint pre webOS 1.4.1.1, Govnah 0.5.6, uber kernel 1.4.1-58, and battery monitor 1.0.7.

    I have discovered a error of sorts and before I reboot my pre to correct it I figure it best to post to see if there is any sort of debug command line stuff or something that can be ran to diagnose. I ran govnah for 2 hours set at the 2 second interval for my previously mentioned test for a baseline consumption for if an option were added to turn graphing on or off. I also had battery monitor open to get the mA average for the 2 hours (opened govnah first and then battery monitor put govnah in focus).

    I then closed both and proceeded to do the same for 1 second interval. This time govnah stopped updating I believe in less than 20 minutes. At this point the cpu temperature service stopped reporting to battery monitor (*** shows which I think I used to indicate failed return value in addition to missing service but not sure if both). I closed both thinking it was just a glitch. I opened govnah again to see --- in all list items and didn't update to any data. Closed and opened again several times with the same result. I'm certain a reboot will take things back to normal so I want to make sure that I cover any bases for debugging this before I do so.

    On a side note does govnah not poll during idle state when the screen is off? The reason I ask is the discrepancy between the graphing data in govnah and the mA average from battery monitor. Govnah's graph indicated a consistent 200+ mA but battery monitor (15 second poll interval) indicated an average of 30mA and the graph indicated mA nearly the whole time remained around 30mA with a few spikes here and there typically seen occurring when testing for idle consumption without any apps running. However I had expected to see at least 100mA average since polling at rapid intervals with battery monitor consumed at rates at least that high.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  5. #565  
    Quote Originally Posted by StoneRyno View Post
    Sprint pre webOS 1.4.1.1, Govnah 0.5.6, uber kernel 1.4.1-58, and battery monitor 1.0.7.

    I have discovered a error of sorts and before I reboot my pre to correct it I figure it best to post to see if there is any sort of debug command line stuff or something that can be ran to diagnose. I ran govnah for 2 hours set at the 2 second interval for my previously mentioned test for a baseline consumption for if an option were added to turn graphing on or off. I also had battery monitor open to get the mA average for the 2 hours (opened govnah first and then battery monitor put govnah in focus).

    I then closed both and proceeded to do the same for 1 second interval. This time govnah stopped updating I believe in less than 20 minutes. At this point the cpu temperature service stopped reporting to battery monitor (*** shows which I think I used to indicate failed return value in addition to missing service but not sure if both). I closed both thinking it was just a glitch. I opened govnah again to see --- in all list items and didn't update to any data. Closed and opened again several times with the same result. I'm certain a reboot will take things back to normal so I want to make sure that I cover any bases for debugging this before I do so.

    On a side note does govnah not poll during idle state when the screen is off? The reason I ask is the discrepancy between the graphing data in govnah and the mA average from battery monitor. Govnah's graph indicated a consistent 200+ mA but battery monitor (15 second poll interval) indicated an average of 30mA and the graph indicated mA nearly the whole time remained around 30mA with a few spikes here and there typically seen occurring when testing for idle consumption without any apps running. However I had expected to see at least 100mA average since polling at rapid intervals with battery monitor consumed at rates at least that high.
    I've been able to experience the not updating problem, but cannot reproduce it quickly enough yet to debug it.

    Govnah does not do anything while the screen is off. It's not trying to replace Battery Monitor.

    -- Rod
  6. #566  
    BTW, the current draw discussion overnight gave me a good chuckle, considering we just threw it in there for alpha testing without even looking at positive vs negative, and I used 'Current Draw' cause it was a similar length of text to the other labels

    I'm surprised no-one has commented yet that the graph should be filled from the top for negative values ...
    -- Rod
  7. #567  
    Quote Originally Posted by rwhitby View Post
    I've been able to experience the not updating problem, but cannot reproduce it quickly enough yet to debug it.

    Govnah does not do anything while the screen is off. It's not trying to replace Battery Monitor.

    -- Rod
    I'll reboot my pre and try and reproduce the scenario that it occurred with in my previous post. Ah I understand now then why I didn't see much of an increase if any at all while testing for consumption rate since I was testing with screen off. So I'll have to test with screen on so that I can provide data for how much each poll interval consumes per hour.

    Quote Originally Posted by rwhitby View Post
    I'm surprised no-one has commented yet that the graph should be filled from the top for negative values ...
    -- Rod
    Nobody ever commented on that with battery monitor either. The graph fills to the up and right of the origin and graph shows in absolute value rather than negative so it works for both charging and not charging.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  8. #568  
    Quote Originally Posted by rwhitby View Post
    BTW, the current draw discussion overnight gave me a good chuckle, considering we just threw it in there for alpha testing without even looking at positive vs negative
    -- Rod
    Rod-

    It makes me chuckle as well, cuz I still think it's a non issue as it seams to give proper data, if one spends a few minutes even looking at the data they see. At the same time (and maybe this comes from my experience in 12v car electronics) the term draw and the way it is represented makes perfect sense to me. Either way, it's an interesting item to have added to govnah as far as data is concerned as long as the data is correct.
  9. #569  
    Quote Originally Posted by OldSkoolVWLover View Post
    Rod-

    It makes me chuckle as well, cuz I still think it's a non issue as it seams to give proper data, if one spends a few minutes even looking at the data they see. At the same time (and maybe this comes from my experience in 12v car electronics) the term draw and the way it is represented makes perfect sense to me. Either way, it's an interesting item to have added to govnah as far as data is concerned as long as the data is correct.
    I wouldn't say it's a non-issue, since the point of all this testing is to make things as tight as possible with the apps/kernels. Pretty much anything to do with them should be analyzed. Yeah, you know by looking at it what it's trying to say, but it really should be accurately labeled if possible.

    By the way Rod, the graph should be filled from the top for negative values .
    Last edited by morrison0880; 07/12/2010 at 12:39 AM.
    I don't understand the purpose of the line, I don't need to drink to have fun. Great, no one does. But why start a fire with flint and sticks when they've invented the lighter?

    Let's all give thanks to the app that started it all.
    http://forums.precentral.net/homebre...ebrew-app.html
  10.    #570  
    Quote Originally Posted by rwhitby View Post
    I'm surprised no-one has commented yet that the graph should be filled from the top for negative values ...
    Or that the released version has 3 decimal places of unnecessary precision.
    Last edited by oil; 07/12/2010 at 12:49 AM.
  11. #571  
    Consumption test results for govnah:

    Baseline --------- 23mA/hr --- idle device (wifi, GPS, and cell radios on 3 bars of signal) no other activity occurring during the baseline test
    screen on add --- 100mA/hr --- brightness 10% --- 200mA/hr --- brightness 100%

    The following is derived by subtracting the above two from the mA average per hour thus is the mA per hour govnah consumes at each of the intervals. Per Rods post earlier govnah doesn't do anything when the screen is off so it should only be drawing power when the screen is on. I used 10% brightness but included the min and max values so consumption can be derived for others to use or confirm the data. All amounts above and below obtained using 15 second interval in battery monitor. The govnah numbers are from only one test for each interval. I prefer to run at least 12 times to be sure each amount is consistent but wanted to get preliminary numbers since the topic came up. So these numbers should not be used as fact until enough tests can be performed to make sure they aren't flawed.

    Update launcher icon setting off
    govnah ----- 77mA/hr --- 1 second interval
    govnah ----- 75mA/hr --- 2 second interval
    govnah ----- 30mA/hr --- 5 second interval
    govnah ----- 24mA/hr --- 10 second interval
    govnah ----- 21mA/hr --- 15 second interval
    govnah ----- 19mA/hr --- 30 second interval
    govnah ----- 17mA/hr --- 1 minute interval

    Quote Originally Posted by oil View Post
    Or that the released version has 3 decimal places of unnecessary precision.
    I guess I must be good at overlooking unnecessary things. Like I seen that but blocked it out. LOL I don't think any level of precision beyond whole number will improve our ability to estimate remaining time before needing to put it on the charger.

    Quote Originally Posted by StoneRyno View Post
    I'll reboot my pre and try and reproduce the scenario that it occurred with in my previous post. Ah I understand now then why I didn't see much of an increase if any at all while testing for consumption rate since I was testing with screen off. So I'll have to test with screen on so that I can provide data for how much each poll interval consumes per hour.
    Repeating my scenario previously posted about before my reply in the quote resulted in inability to reproduce the problem. I guess we don't have any more to go on to find out what may have caused the oddity. But I have a theory for possible repeatable scenario. Run at 1 second interval for between 16 and 17 minutes which is right around 1,000 polls. I believe this to be around the halting point which results in what I described. If anyone else can run it to 1,000 polls to try and confirm this it may help provide a basis for troubleshooting.
    As requested: for my works on webOS patches and apps. Twitter: @larryboytw Patches: Small icons browser start page, 5x5 launcher. I have an AAS CIS Programming degree. I enjoy working on open source projects and alpha and beta testing.
    http://install.preware.org/ for easy to get up and running for patches and apps.
  12. #572  
    I'm running the 1K Tick Test. 1,000 seconds == 16 minutes 40 seconds.


    M.
  13. #573  
    Quote Originally Posted by StoneRyno View Post
    Run at 1 second interval for between 16 and 17 minutes which is right around 1,000 polls. I believe this to be around the halting point which results in what I described. If anyone else can run it to 1,000 polls to try and confirm this it may help provide a basis for troubleshooting.

    Quote Originally Posted by Xanadu73 View Post
    I'm running the 1K Tick Test. 1,000 seconds == 16 minutes 40 seconds.

    Just as you predicted, it stopped recording somewhere in (what math says) is the 1,000th tick.

    Went through system logs. Nothing recorded about this at that time but I set my logging to minimal. I'll run the test again a little later. I actually have to work at Work from time to time... :-\

    Tried Java restart: Govnah still bonked
    Tried Luna restart: Govnah still bonked
    Shutdown/battery pull (it's been a while): Govnah back to life.


    M.
  14. Speebs's Avatar
    Posts
    297 Posts
    Global Posts
    403 Global Posts
    #574  
    Quote Originally Posted by Xanadu73 View Post
    Just as you predicted, it stopped recording somewhere in (what math says) is the 1,000th tick.

    Went through system logs. Nothing recorded about this at that time but I set my logging to minimal. I'll run the test again a little later. I actually have to work at Work from time to time... :-\

    Tried Java restart: Govnah still bonked
    Tried Luna restart: Govnah still bonked
    Shutdown/battery pull (it's been a while): Govnah back to life.


    M.
    I'm going to try this now as well. I'm not sure how important the kernel is but I am running F105 v.4.1-74 (updated this morning via Preware). Govnah is v0.5.6.

    I can already confirm that Java/Luna restarts do not fix the issue and a battery pull is the only way to get Govnah running again.

    Will update this post again in approximately 17 minutes...

    [UPDATE]

    Interesting. I was watching Govnah and at 13:05 the Frequency and Temperature graphs dropped to 0, even though the rest of the graphs continued. I opened up Battery Monitor and the CPU temperature was showing ***.

    I closed Govnah and re-opened, and the Freq and Temp monitors were still at 0 until I turned the screen off and then back on.

    For the next 20 seconds or so, the graphs worked OK, but then dropped back to 0 again for another minute or so. The other graphs continued to update during this time.

    Then, as I typed this, Govnah stopped updating completely (all graphs). Battery Monitor again shows *** for the CPU temperature. Govnah is now unusable without a full device reset.
    Last edited by Speebs; 07/12/2010 at 02:45 PM.
  15.    #575  
    Quote Originally Posted by StoneRyno View Post
    I guess I must be good at overlooking unnecessary things. Like I seen that but blocked it out. LOL I don't think any level of precision beyond whole number will improve our ability to estimate remaining time before needing to put it on the charger.
    It is already being rounded in the version in git.


    As far as the other problems, I blame the service (what else is new? haha)
  16. #576  
    Hey everyone. I have a question. I'm not sure if this is the place to post it or if it's been posted somewhere, but I've been searching for 30 min now and can't find anything.

    I updated govnah the other day to .5 and ever since, I have not been able to raise my clock speed or even set govnah to screenstate. As soon as I click on a profile in Govnah, whether or not my Pre has an overclock kernel, it freezes and I have to take my battery out to turn the Pre off and back on. I've doctored twice (the first time I had to because the Pre wouldn't turn back on) and the issue still exists. I tried updating Govnah to .5.6 and still the same issue. Brightness is at 45% to see if that would fix the issue, but nothing.


    Any help would be GREATLY appreciated.
    Twitter: @Eddie255
  17. #577  
    Quote Originally Posted by Reign25 View Post
    Hey everyone. I have a question. I'm not sure if this is the place to post it or if it's been posted somewhere, but I've been searching for 30 min now and can't find anything.

    I updated govnah the other day to .5 and ever since, I have not been able to raise my clock speed or even set govnah to screenstate. As soon as I click on a profile in Govnah, whether or not my Pre has an overclock kernel, it freezes and I have to take my battery out to turn the Pre off and back on. I've doctored twice (the first time I had to because the Pre wouldn't turn back on) and the issue still exists. I tried updating Govnah to .5.6 and still the same issue. Brightness is at 45% to see if that would fix the issue, but nothing.


    Any help would be GREATLY appreciated.
    i have the same issue -- i was using the warthog kernel and i have since installed the recovery kernel and then the uber kernel -- i was getting ready to doctor thinking the there had been damage caused by the warthog kernel??? but it seems not to have worked for you so i will hold off for awhile -- maybe the problem is govnah related?? does anyone have a more educated explanation for what is going on? -- please let me know what information to provide
    thanks
    -------------------------------------------------------------------
    Rob Chilcott

    Twitter @robchilcott
    pre2
    " I am only a stupid electrician after all"

    My house is a webOS house
    My pre 2, Touchpad 32g
    Wife Pixi, touchpad 32gb
    Daughter -- my old pre+
    of course my 16 year old son has and droid incredible but i think i remeber finding him on the porch
  18. #578  
    Finally following up on my previous question about values to expect from my Sprint Pre on bootup and during normal usage for Memory/Swap values in Govnah...

    ...With the goal of understanding how to interpret those numbers and judge whether my compcache settings were working for me and whether I could improve the settings for my usage.

    Perhaps one central question in that is whether that Swap value is the amount of the super-slow swap space in the flash memory or whether it's the compressed RAM disk of the compcache. If the former, then it seems to me that that should ideally be close to 0 during most of my usage. If the latter, it should be anything up to the memlimit I've set for compcache.

    I've seen the Swap value at something like 71MB despite my memlimit being set to (at that time...) either 24 or 32 or 48, I can't remember specifically now, which would seem to rule out that that Swap value was for the compcache, but not if the value is read out based on what the uncompressed compcache usage would be...

    Anyway, in response to my questions, Rod told me to...

    Quote Originally Posted by rwhitby View Post
    Take a look in /proc/ramzswap

    -- Rod
    Okie dokie, so I did this today (via the command line in WebOS QI), but I don't know how to interpret it. Fresh off a reboot to enable Developer Mode, I went into WebOS QI and got this output:

    root@palm-webos-device: cat /proc/ramzswap
    DiskSize: 131072 kB
    MemLimit: 65536 kB
    NumReads: 2
    NumWrites: 44
    FailedReads: 0
    FailedWrites: 0
    InvalidIO: 0
    NotifyFree: 9
    ZeroPages: 1
    GoodCompress: 100 %
    NoCompress: 0 %
    PagesStored: 43
    PagesUsed: 1
    OrigDataSize: 172 kB
    ComprDataSize: 3 kB
    MemUsedTotal: 4 kB
    BDevNumReads: 18
    BDevNumWrites: 0
    After running that, I went onto my Sprint Pre and opened up Govnah to see what the Memory/Swap values were: 230/0 MB.

    Is this good? bad? Expected? Dependent on what apps I might have installed that might be polling in the background?

    I now have Govnah 0.5.6 installed.

    Overnight, while my Pre was on the Touchstone, with Govnah settings of Screenstate 500/800, and a just-changed compcache setting from 48 MB to 64 MB before going to bed...my Sprint Pre froze. The screen was showing 7:32am, I *think* (though 7:30am seems more likely, as I have a daily 7:30am alarm set), but rather than the the alarm showing on the screen, what was on the screen was the TMC error.

    The phone was unresponsive to screen touches, opening the slider, the power button. I didn't remember to try the hold power button and slide the ringer switch method; I just pulled the battery.

    Troubleshooting ideas? or is there a log or somewhere I could look to find/provide more specific data on what might have gone wrong?

    Thanks!

    Updating with more background:
    • I'm running Ueberkernel v1.41-58.


    I just realized something...when I first asked the question, my Memory/Swap reading right after bootup was something like: 210/0. At that point, my memlimit was set to either 16MB, 24MB, or maybe 32MB.

    Now given that I upped my compcache memlimit value to 64MB last night, and now that I'm seeing a higher Memory value immediately post-boot-up now, I'm guessing that the memlimit amount is counted in the Memory value. If that's the case, then, for a memlimit of 64 MB, that's just part of the, say, 230 MB listed in the Memory readout.

    Further supporting evidence would be if I see that Memory value climb over the Pre's 256MB of RAM up to something more like...assuming a 2-1 compression ratio for the 64MB compcache...256 - 64 +128 = 320 MB.

    I'm guessing here...does that make sense? Is that right?

    Still, given that immediately post-bootup, I'm already at 230, that means that something is already using up 256 - 64 = 166 MB of my Sprint Pre's 256 MB of RAM.

    Is *that* reasonable?!
    Last edited by Shadowhawk; 07/13/2010 at 08:19 PM. Reason: Adding background...
  19. #579  
    so i am reading in another thread that if you leave the card up and running govnah will start hogging cpu and hang up -- this will cause overheating when charging -- i am not accusing anyone of anything here -- i believe in retrospect that i have experienced this -- i put the govnah icon on the quick launch bar and have taken to leaving the card open to have the temp on the icon -- it just makes me happy -- now that i think this may be happening i will start watching to see if i can cause this to happen consistantly --

    Is there any way to have the temp show up in the icon with out the card open?

    govnah has been acting wierd for me -- it will freeze if i try to change profiles and if i am not quick to close the card it will freeze the whole phone with only a full battery pull fixing the problems -- i am running uber kernel now because i was experiencing issues with both the warthog and the f105 kernels but i truly believe that the issue may have been from me leaving the govnah card open ( i leave the battery monitor open too alot to have quick visual reference for the temp of my device ) maybe this contributes

    am i crazy?
    -------------------------------------------------------------------
    Rob Chilcott

    Twitter @robchilcott
    pre2
    " I am only a stupid electrician after all"

    My house is a webOS house
    My pre 2, Touchpad 32g
    Wife Pixi, touchpad 32gb
    Daughter -- my old pre+
    of course my 16 year old son has and droid incredible but i think i remeber finding him on the porch
  20. #580  
    There does appear to be some issue with Govnah' after the recent updates. For me, it started late last week after updating Govnah' to one of the 0.5x releases. I've had Mode Switcher launching Govnah' for a long time now so I can limit my overclock speeds when charging, etc. Recently I started awaking to a frozen Govnah' card on my phone. My phone would still work, but was a bit sluggish. As posted above, Luna or Java restarts did nothing as expected, and it took a full reboot to return to normal. I haven't verified the "1000 ticks" theory, but so far it's 100% repeatable for me if I leave it open.

    Luckily I've never had the phone lock up as the last 2 posters mention. I'm also running F105 -74 (also did this with -69).

    BTW, if you stop the main Govnah' process after it hangs, it appears to return to normal operation when you start Govnah' again. You can do this from your phone easily with "Upstart Manager" or you could CLI it.
    Last edited by 4wheels; 07/14/2010 at 04:56 PM.

Posting Permissions