Page 5 of 8 FirstFirst 12345678 LastLast
Results 81 to 100 of 144
  1. #81  
    rob how is your battery life?
  2. #82  
    Quote Originally Posted by trim81 View Post
    rob how is your battery life?
    I've been messing with it so much that I don't have a good answer yet, I'm getting battery monitor back on it (new Pre, launch day Pre finally succumbed to power button failure).

    It "feels" like better, but I've mostly been working on the methodology so far and do not have any empirical data yet to support or discount my "feel".
  3. #83  
    I found Battery Monitor wanting, so I've created a small shell script that runs from cron and logs the relevant output to a file so a reboot won't kill me. I think I'm going to have to write a small script daemon as well because I notice that Glyder2 is starting in 125MHz mode and I have to tap the screen to get it to load faster (boost to 600MHz) so I'm thinking something to watch for a SDL prog that sets the minimum to 500 or so for the duration of a SDL program.

    Now to let my little cron job run for a couple days in both my ondemand mode and also in default mode to collect enough data to be able to see if it really makes a difference.
  4. #84  
    Quote Originally Posted by netwrkr9 View Post
    I know that most of the people in this thread are concerned more about speed than energy consumption. As I posted earlier, I installed the updated Scaling 500 patch last night and so far found no ill effects or lagging from this patch. I ran the battery monitor last night to get a reading of what power consumption was when my Pre was idle and am really pleased with the results:

    Some reason the attachment option is not functioning, but here are my results, I ran the test for 9 hours and 23 minutes, power usage was at .64% with 146.72 hours of battery life remaining. At the end of the test my battery reading was at 95%. I am really happy with the results, right on par with the previous SR 500 patch I was using!
    I again ran the Battery Monitor app testing my Pre's power consumption at idle with the Powersaving Scaling 500 patch removed and after 8 hours power usage was 1.1% per hour. So the patch does conserve power but my Pre is still pretty effcient without the patch.
  5. #85  
    I've implemented this on boot with a couple changes - I'm leaving the minimum frequency and powersave bias default. Frankly, I'm not exactly sure what the powersave bias is supposed to do, but the default is the same as the OP's, so I'll just leave it.

    So far I'm very pleased with the performance (video playing, web browsing, etc.) - just hoping that battery life improves. I'll give it a day or so before posting my anecdotal evidence.
    -Joshua
    I've decided to become enigmatic.
  6. #86  
    Where is the patch?
  7. #87  
    Quote Originally Posted by number1pete View Post
    I started a thread a long time ago about using the kernels ondemand governor for cpu scaling. Back then the kernel and the OS had problems with it. Now after extensive testing, i can confirm that it is working great in WebOS 1.4 for my particular phone.

    -no more camera app jitters
    -no more video flickers
    -no more inappropriate scaling to 125-250mhz
    -no more random reboots or shutdowns on wake up

    Here are the settings that the phone really seems to like:

    min scaling freq = 500000
    max scaling freq = 600000
    scaling governer = ondemand
    sampling rate =
    powersave bias = 0
    cpu up threshold = 20% utilization


    here is the code for all you linux people. Im sure someone is willing to write a patch for you.

    echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo 20 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    echo > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias


    Simply type the above code in novaterm and if things dont work out reboot your phone and everything is reset to default. Have fun and let me know how it works for you.
    wheres is novaterm...where do I typed that?
  8. #88  
    I have been using caj2008/Marco's luna 600 with no issues whatsoever...and have found little if any battery drainage issues....I did testing using the "battery app" over many hours using many different applications for testing...
  9.    #89  
    Quote Originally Posted by Flip34 View Post
    wheres is novaterm...where do I typed that?
    novaterm is an actual program that you will need to download for the pc (assuming you have mojo sdk installed), just grab it from webos internals site.

    If you have linux or mac then it comes with the SDK install so just type novaterm into terminal.

    if you have WOSQI then just copy and paste the code into the WOSQI terminal
  10.    #90  
    Quote Originally Posted by mmprotection View Post
    Where is the patch?
    not making a patch. Instead im almost done creating a homebrew app for this!

    Give me some more time....RL has been cracking down on me.....but im 90% done and its a sweet little app.
  11.    #91  
    Quote Originally Posted by ferriskeanu View Post
    I have been using caj2008/Marco's luna 600 with no issues whatsoever...and have found little if any battery drainage issues....I did testing using the "battery app" over many hours using many different applications for testing...
    those are sripts utilizing the userspace scaling governor....totally different than scaling with ondemand governor.

    scaling is necessary since palm feels like its a bad idea to leave pre at 600mhz 24/7. I do think some phones (with the good batch of procesors) are capable of running 600mhz 24/7 for months but youll never know if your phone is till its too late.

    Plus some people are scaling down to 125-250mhz when idle to save some battery (probably minimal though, compared to 3g radio usage).
  12.    #92  
    Quote Originally Posted by Rob600 View Post
    I've been expermenting with this method as a way to both increase interactive performance and to increase battery life at the same time by allowing scaling into the 250 and 125 ranges. In other words, trying for the "best of both worlds". My tests have been with running the standards applications and using Glyder2 as my 3D test along with recording some video and playing it back. On my Pre, I am able to find a happy spot based around using 125-600 as long as I use 1000000 for the sampling rate. I've found that using between 20 and 40 for the up_treshold seems to work without issues.

    Here is my current script that I call from the command line, I have not put it into a automatcially executable mode since I won't be satisfied for a week or so and need to be able to three-finger-salute it back to standard as I use it for business purposes.

    My script (note the commented out line for 250MHz as min and uncommented for 125MHz as min)
    Code:
    # Set ondemand governor
    cpufreq-set -g ondemand
    
    # Set 30 as the up threshold
    echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    
    # Set sampling rate
    echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    
    # Set min speed (pick one)
    #echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    
    # Simple output for verification
    echo -n Governor:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    
    echo -n Threshold:
    cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    
    echo -n Sampling:
    cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    
    echo -n Min Speed:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    
    echo -n Max Speed:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    
    echo -n Cur Speed:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
    Here are my time_in_state numbers since last night with some amount of time being run without the settings which shows up as increased 500MHz time.
    Code:
    600000 757126
    550000 6852
    500000 627314
    250000 42324
    125000 3237090
    in all my testing i was unsatisfied with the 30% cpu utilization for an up threshold. It created problems durring pandora or music playback. I think anything b/t 11-20% is more appropriate. Else some music playback may skip.
  13.    #93  
    Quote Originally Posted by OverLordO**** View Post
    ok quick question related to but not about scaling.... I noticed that there is a way to overclock the Pre, at my own risk of course, and I am willing to try this out I just wanted to see how to go about this and how to insert the command. can i use wosqi and go thru the linux line and simply insert

    echo "600000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

    and if so do I adjust the number to what i would like it to run say 700000 or even 800000? I've seen the video and lets face it most phones (or atleast models) you only keep for about 2 years if that and I'd like to make my experience the best as possible and have my phone running as smooth and as fast as possible.

    Also if theres any test groups for these kinds of patches being created I'll judt say it know and stated that I'd like to participate.
    the only frequencies available to us in the current kernel are:
    125
    250
    500
    550
    600mhz

    so you can see we dont have the ability to scale above 600mhz without recompiling the kernel (witch someone did on 1.3.5.1, ask caj2008 about it). They are working on a custom kernel for webos 1.4 to scale above 600mhz so just be patient.
  14.    #94  
    Quote Originally Posted by netwrkr9 View Post
    Update on my Scaling 500 patch adventure. For the first day everything seemed fine, good battery savings while my Pre was idle, but the second day I started to get freeze ups and my screen would go black and the remedy was to pull that battery. After this happened 3 times in one hour I decided to go ahead and remove this patch. So much for experiment.
    sounds like you used someone elses patch.....no one has had those problems with the code i provided in the OP. If you are haveing freezes with my code, make sure the 500mhz min freq stuck. Some procesors dont like to go down to 125mhz since its scaling the voltage as well.
  15.    #95  
    Quote Originally Posted by ****-richardson View Post
    I've implemented this on boot with a couple changes - I'm leaving the minimum frequency and powersave bias default. Frankly, I'm not exactly sure what the powersave bias is supposed to do, but the default is the same as the OP's, so I'll just leave it.

    So far I'm very pleased with the performance (video playing, web browsing, etc.) - just hoping that battery life improves. I'll give it a day or so before posting my anecdotal evidence.
    for those that dont understand powersave bias here is a good article:

    IBM Information Center for Linux

    essentially it makes the kernel choose a frequency that is a the requested mhz lower than the frequency it would have chosen. So if it wanted to choose 600 and you had a power save bias of 100 then it would scale to 500mhz instead.
  16. #96  
    so my linux commandline in webOS Quickinstall now looks like this:

    Code:
    root@palm-webos-device: echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    root@palm-webos-device: echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@palm-webos-device: echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    root@palm-webos-device: echo 20 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    root@palm-webos-device: echo > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    root@palm-webos-device: echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
    is that correct?

    do i have to do a restart now or is it already applied? will it be gone with the next restart?

    geez, i think i need the app... ^^
    Last edited by The Day Pré Tomorrow; 03/08/2010 at 05:51 AM.
  17.    #97  
    Quote Originally Posted by The Day Pré Tomorrow View Post
    so my linux commandline in webOS Quickinstall now looks like this:

    Code:
    root@palm-webos-device: echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    root@palm-webos-device: echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    root@palm-webos-device: echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    root@palm-webos-device: echo 20 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
    root@palm-webos-device: echo > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
    root@palm-webos-device: echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
    is that correct?

    do i have to do a restart now or is it already applied? will it be gone with the next restart?

    geez, i think i need the app... ^^
    im happy to see you applying a little code. If you want to know if any of your codes stuck then you need to read them. Just use the command "cat" or "more" to read the meta file you modified. Here is an example if you wanted to know what governor you are using:

    Code:
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    and here is an invaluable table that shows you your time in each frequency. You can call this table serveral times in a row to see how your procesor is scaling.

    Code:
    echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
  18. #98  
    number1pete, thanks for the tip on 20%, I had not tested playing music in my informal workflow. On the previous post I think you meant:

    Code:
    cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
    I ran with a min speed of 125 and 250 overnight and did note a bit of difference in current draw. I'm using the Average Current reporting from the battery as my primary data point and in my early testing I saw this overnight:

    125MHz min had these as low avg currents: 3125, 2812, 3437, 3437

    250MHz min had these as low avg currents: 4921, 4921, 5156, 5000

    I'm sharing this not as a final report, but for some initial data and review of my methodology of using average current as my primary battery usage statistic.

    In other news, it appears my Pre does not mind 125MHz, but I understand that it is an issue so I plan on doing most of my tests at 125MHz and 250MHz min speeds for that reason and for validity testing.
  19.    #99  
    Quote Originally Posted by Rob600 View Post
    number1pete, thanks for the tip on 20%, I had not tested playing music in my informal workflow. On the previous post I think you meant:

    Code:
    cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
    I ran with a min speed of 125 and 250 overnight and did note a bit of difference in current draw. I'm using the Average Current reporting from the battery as my primary data point and in my early testing I saw this overnight:

    125MHz min had these as low avg currents: 3125, 2812, 3437, 3437

    250MHz min had these as low avg currents: 4921, 4921, 5156, 5000

    I'm sharing this not as a final report, but for some initial data and review of my methodology of using average current as my primary battery usage statistic.

    In other news, it appears my Pre does not mind 125MHz, but I understand that it is an issue so I plan on doing most of my tests at 125MHz and 250MHz min speeds for that reason and for validity testing.
    yeah you definately cought my copy/paste mistake.

    I like where your head is at on the power draw measurments. Cant argue with amps.

    Some pre's dont mind 125mhz (the ones with good cpu's). I ran mine at 125-600mhz scaling for like 3 months until i realized i liked power more than battery life so i do 500-600mhz now.

    The problem was that when your phone is idle at 125mhz then you get a phone call and it spikes to 600 or tries to, the people with bad cpu's get freezes from that. I never had that happen to me but we did lots of testing on tons of phones back in the day. Check some of the threads i created from a year ago if your interested.
  20. #100  
    here are my results from the patch being applied

    Processor : ARMv7 Processor rev 3 (v7l)
    BogoMIPS : 597.68

    and
    600000 233968
    550000 2674
    500000 1969
    250000 0
    125000 0

    so far lag is gone, still some here and there, which is expected, but things are running smoother. Also since I started I've tested my internet connection and been noticing my internet cnnection has been faster probably not related but still worth mentioning
    Attached Images Attached Images
    Last edited by OverLordOfYou; 03/09/2010 at 12:51 AM.
Page 5 of 8 FirstFirst 12345678 LastLast

Posting Permissions