Page 76 of 96 FirstFirst ... 2666717273747576777879808186 ... LastLast
Results 1,501 to 1,520 of 1910
Like Tree14Likes
  1. #1501  
    Quote Originally Posted by jellmoo View Post
    I have a potentially stupid question.

    I have a Pre 2 running a stock 2.1 kernel. When I run Govnah, it gives me a frequency that spikes between 300MHz and 1GHz, with it being on 300MHz the majority of the time.

    Is this normal? If it isn't, is there anything I can do to fix this?

    Thanks!

    Edit: This is with no other open cards.

    If memory serves me right, the Palm Stock Palm kernel on the Pre2 has the conservative governor enabled by default. What you see is it acting the way it's supposed to.


    M.
  2. #1502  
    Quote Originally Posted by Xanadu73 View Post
    If memory serves me right, the Palm Stock Palm kernel on the Pre2 has the conservative governor enabled by default. What you see is it acting the way it's supposed to.


    M.
    ondemandtcl
    Live free or DIE!
  3. #1503  
    Quote Originally Posted by Xanadu73 View Post
    If memory serves me right, the Palm Stock Palm kernel on the Pre2 has the conservative governor enabled by default. What you see is it acting the way it's supposed to.


    M.
    Thanks for the info!

    However, that clearly won't do.

    Guess I have to wait for the Pre 2 Uberkernel to be released.
  4. #1504  
    Quote Originally Posted by jellmoo View Post
    Thanks for the info!

    However, that clearly won't do.

    Guess I have to wait for the Pre 2 Uberkernel to be released.
    Ondemandtcl is quite a good governor, and clocking down to 300MHz is what you *want* it to do when the workload does not require top speed (which is what the Tcl part of ondemandtcl ensures you get).

    You want to see that graph showing 300MHz as often as possible, peaking at top speed when you're actually using the device significantly, so you get the best battery life.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  5. #1505  
    Quote Originally Posted by unixpsycho View Post
    ondemandtcl

    I thought that was yours, not Palm's. I guess I'm remembering wrong...


    M.
  6. #1506  
    Quote Originally Posted by Xanadu73 View Post
    I thought that was yours, not Palm's. I guess I'm remembering wrong...
    ondemand is a standard Linux governor.

    ondemandtcl is Palm's extension of it, which was used on the Pixi, and is now used on the Pre 2 as well.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  7. #1507  
    So what is the uberkernel default? I use this on me Pre minus and it is not bad. If i use screenstate my battery eats up??
  8. conum's Avatar
    Posts
    338 Posts
    Global Posts
    339 Global Posts
    #1508  
    Quote Originally Posted by hi-tech34 View Post
    So what is the uberkernel default? I use this on me Pre minus and it is not bad. If i use screenstate my battery eats up??
    so do i, as screenstate 500/800 brings randomly shutdowns to my pre-, webos 2.1.0, and there's noone that can help me to find out how to get the kernellog after such a shutdown.
  9. #1509  
    Quote Originally Posted by rwhitby View Post
    Ondemandtcl is quite a good governor, and clocking down to 300MHz is what you *want* it to do when the workload does not require top speed (which is what the Tcl part of ondemandtcl ensures you get).

    You want to see that graph showing 300MHz as often as possible, peaking at top speed when you're actually using the device significantly, so you get the best battery life.

    -- Rod
    Thanks for the explanation! I just created a FrankenPre on my Pre2 and noticed this today and now I know all is good.
  10. #1510  
    Quote Originally Posted by conum View Post
    so do i, as screenstate 500/800 brings randomly shutdowns to my pre-, webos 2.1.0, and there's noone that can help me to find out how to get the kernellog after such a shutdown.
    Boot into recovery mode and run

    novacom get file://klog

    -- Rod
  11. #1511  
    Quote Originally Posted by flochen View Post
    is there no way?
    with uberkernel my experience was bad. i have a pre-
    i think that the memory management of ueberkernel is not so good like with the original kernel, many a time my device stop to work for some seconds etc and slow down massive :-( so i switched back to the palm kernel
    using and tests with the "ram drive" does not solve the problem.
    Quote Originally Posted by rwhitby View Post
    Your experience is atypical.

    -- Rod
    I have mixed results. I took UK off after what seemed like longer lags than I got with the stock Kernel. Overall UK was much faster - but there were times that it seemed to lag and those lags seemed longer than what I get on my Palm Kernel. Honestly I have never used a stopwatch and the relative speediness of UK may have made the lags feel longer - hard to tell.

    I wonder if some of the lag was due to my dislike of the screenstate governor and use of the conservative or ondemand governor. I used them all but those were more commonly used.
  12. #1512  
    Quote Originally Posted by rwhitby View Post
    We do not recommend that you leave Govnah running unless you are actively looking at the graphs to confirm something.
    Actually my point was that I was surprised that when the state changes it isn't written to the log. I would have thought that at a certain debug level it would be written as a matter of normal practice.

    I was not aware of the fact that you did not recommend running Govnah unless actively looking. Good to know. Use it, and close it - got it.
  13. #1513  
    Quote Originally Posted by Unclevanya View Post
    I have mixed results. I took UK off after what seemed like longer lags than I got with the stock Kernel. Overall UK was much faster - but there were times that it seemed to lag and those lags seemed longer than what I get on my Palm Kernel. Honestly I have never used a stopwatch and the relative speediness of UK may have made the lags feel longer - hard to tell.

    I wonder if some of the lag was due to my dislike of the screenstate governor and use of the conservative or ondemand governor. I used them all but those were more commonly used.
    Lag is a side-effect of those two governors. That's why they are not used in the predefined profiles.

    You may want to determine if your dislike of screenstate has a rational technical basis.

    Quote Originally Posted by Unclevanya View Post
    Actually my point was that I was surprised that when the state changes it isn't written to the log. I would have thought that at a certain debug level it would be written as a matter of normal practice.

    I was not aware of the fact that you did not recommend running Govnah unless actively looking. Good to know. Use it, and close it - got it.
    The kernel notes state changes in /var/log/messages. Govnah does not cause state changes itself, Govnah sets the parameters with which the kernel decides to make state changes.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  14. #1514  
    Quote Originally Posted by rwhitby View Post
    You may want to determine if your dislike of screenstate has a rational technical basis.
    Ahaha, thanks for a much-needed morning laugh.

    On a more serious note, what settings are you power-users rolling with for WebOS 2.1 hacked on a Pre-?

    Whenever the phone starts to lag, running top from a CLI shows various palm-services eating up 100% CPU time (guess that's what happens when you move from Java to interpreted Javascript). I've had problems with this happening when the screen is off (CPU is running at 500mhz) and the massive drag on the CPU causing me to miss phone calls, text messages, or alarms.

    Setting the governor to "performance" keeps the device overclocked even when the screen is off, which seems to help with the above issues. Obviously battery life takes a hit, but missing phone calls is unacceptable.

    Also, what compcache settings are working the best for you guys? For me: anything over 24mb causes unacceptable lag as data is swapped out, and anything under 10mb causes TMC errors.
  15. #1515  
    Quote Originally Posted by rwhitby View Post
    Lag is a side-effect of those two governors. That's why they are not used in the predefined profiles.

    You may want to determine if your dislike of screenstate has a rational technical basis.
    From my perspective the technical side isn't my issue - I'm only looking at performance and use. What bugs me about screenstate is that when I do something that does NOT need extra speed like a crossword puzzle - I don't like the extra power used and heat generated. I would love something that combined screenstate with ondemand type scale back functionality - the idea being that when I turn on the screen it ramps up full speed and then as use continues if there is not sufficient demand it allows it to drift down until demand again peaks. The snappy instant ramp up would be helpful most of the time - but the low load reading books, doing non-proc intense stuff would be more optimized.

    BTW - In an effort to be fair I have reinstalled UK and I have been playing with screenstate. I have found that due to my use patterns I like 250/720 the best but I'm also finding that I have had to switch to default or fixed a few times to reduce heat / drain when I'm doing less intense things like reading using Kobo.

    Quote Originally Posted by rwhitby View Post
    The kernel notes state changes in /var/log/messages. Govnah does not cause state changes itself, Govnah sets the parameters with which the kernel decides to make state changes.
    Rod that's exactly what I was trying to figure out. OK so if someone wanted to look back across time and see what the kernel had picked (speed wise) at a given time they could use those logs - fantastic!
  16. #1516  
    Quote Originally Posted by Unclevanya View Post
    ... the idea being that when I turn on the screen it ramps up full speed and then as use continues if there is not sufficient demand it allows it to drift down until demand again peaks ...
    I've got good performance & good battery life with either ondemand, screenstate & screenstate-v2 (Pre- with 24MB compcache, running with lower voltages than default -YMMV-):

    *ondemand & UK kernel:
    -600 to 1000MHz,
    -sampling rate 0,5s
    -powersave bias = 1 (needed for ondemand/conservative)

    *ondemand & F105 kernel:
    -700 to 1005MHz,
    -same sampling rate & powersave bias

    *ST & UK kernel:
    -600 & 1000MHz

    *ST-v2 & F105 kernel:
    -700 & 1005MHz
    -default governor parameters (vdemand factor = medium)
    -this is the one I'm using now (voltages are 1287 & 1425mV -handle with care-)

    *ST-v2 & AV8B kernel:
    -1005MHz fixed speed
    -best performance with not that bad battery life

    You may notice that I don't like 250 or even 500MHz... I've found my Pre to work much better with higher minimum speeds, with few effect in battery life. You may try one/some of the above examples, if you like
  17. #1517  
    I would also pay attention to which I/O scheduler that you use.
    By design, "anticipatory" has a delay to allow reordering and merging of I/O requests to the flash memory (which in turn causes latency).

    For me, I have always had better success with "noop" which is just a FIFO queue.

    For reference:
    Sprint Pre (-)
    Webos 2.1
    F105-20
    Screenstate v2 (500/1005mhz)
    vdemand factor: High
    vdemand polling: 90
    no changes to default voltages
    Compcache: 24MB
    I/O Scheduler: noop
    TCP Congestion: westwood
    This space for rent or lease. Inquire within.
  18. #1518  
    Quote Originally Posted by quini View Post
    I've got good performance & good battery life with either ondemand, screenstate & screenstate-v2 (Pre- with 24MB compcache, running with lower voltages than default -YMMV-):

    ...

    You may notice that I don't like 250 or even 500MHz... I've found my Pre to work much better with higher minimum speeds, with few effect in battery life. You may try one/some of the above examples, if you like
    My PrePlus has been stable even at 125mhz but not perfect. At 250 never a problem. I've tried all kinds of OnDemand and Conservative profiles but in all honestly now that I reflect on it - I was running Govnah in a card most of the time and getting mediochre battery life which isn't surprising considering what Rod mentioned about NOT doing that recently.

    What is Screenstate V2?
  19. #1519  
    Quote Originally Posted by MudShark22 View Post
    I would also pay attention to which I/O scheduler that you use.
    By design, "anticipatory" has a delay to allow reordering and merging of I/O requests to the flash memory (which in turn causes latency).

    For me, I have always had better success with "noop" which is just a FIFO queue.

    For reference:
    Sprint Pre (-)
    Webos 2.1
    F105-20
    Screenstate v2 (500/1005mhz)
    vdemand factor: High
    vdemand polling: 90
    no changes to default voltages
    Compcache: 24MB
    I/O Scheduler: noop
    TCP Congestion: westwood
    That may be true but for some reason AS performs better. In my older kernels I used NOOP, but switched to AS. In newer kernels I am trying deadline with a single queue instead of 16 (which should give the same effect as NOOP).

    The latency introduced in AS may be shown in a "smoother" experience. Technically NOOP should be the defacto setting since it's flash, but it doesnt seem to do well in the Pre. CFQ just sux. YMMV.
    Live free or DIE!
  20. #1520  
    Quote Originally Posted by MudShark22 View Post
    I would also pay attention to which I/O scheduler that you use.
    By design, "anticipatory" has a delay to allow reordering and merging of I/O requests to the flash memory (which in turn causes latency).

    For me, I have always had better success with "noop" which is just a FIFO queue.
    I have played with them all. I like anticipatory - which I am surprised by. I decided that after playing with F102A and finding it pretty snappy. I have experimented with deadline and others and don't find a whole lot of difference - laggy comes and goes on all of them.

    One way I have found to get some non-quantitative but interesting data is to use LED Flashlight on Strobe on the fastest setting and watch the lags come and go. It seems to bog down on certain settings more than others - but nothing clear cut yet. I think some type of program that would exercise some i/o channel and cpu and then write logs to flash periodically to show how much lag is happening would be great.

    One thing I wish is that I could leave Govnah in a card without potential battery drains. I would like to put it to sleep safely and then get it back when needed without having to relaunch - this is particularly important given the fact that I don't tend to just use screenstate - but it's my default right now. EDIT - to clarify I use Govnah to switch profiles when I don't need the extra speed and still want the screen on for a while.

Posting Permissions