Page 37 of 73 FirstFirst ... 27323334353637383940414247 ... LastLast
Results 721 to 740 of 1452
Like Tree6Likes
  1. #721  
    Quote Originally Posted by prubin View Post
    Can you leave it installed for the update or do you have to remove it?
    See @webosinternals on twitter for past 24 hours.

    -- 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
  2. #722  
    Interesting results using "time dd if=/dev/zero of=/dev/null count=10000000" each test was ran 10 times and I averaged the results.

    This is a Palm Pre
    F105 Kernel
    128mb Compache Limit
    1.4.1.1


    800Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 37.61s
    user 0m 5.15s
    sys 0m 24.37s

    900Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 32.37s
    user 0m 4.69s
    sys 0m 21.66s

    1005Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 27.93s
    user 0m 4.24s
    sys 0m 18.72s

    When I do the uname -a I get. Linux palm-webos-device 2.6.24-palm-joplin-3430 #1 Mon Jun 28 16:36:27 UTC 2010 armv7l unknown My question is, did you go back to 2.6.24 kernel or is this still the newer .7 one
    Last edited by xadjustx; 07/02/2010 at 01:17 PM.
  3. hofs1's Avatar
    Posts
    460 Posts
    Global Posts
    473 Global Posts
    #723  
    Quote Originally Posted by unixpsycho View Post
    But there's an easy fix... Simply dont have your screen set too low, remove conflicting apps that get in the way of reading the screen level, and turn off the LCD on the Touchstone - then it would scale down to 500MHz.
    I finally set up Mode Switcher to turn off screen when on the touch stone and it seems much cooler while charging now.....only time will tell....and pandora still plays fine at the 500mgz speed but screen is Off.

    http://forums.precentral.net/webos-p...ml#post2420066
    T300 - T600 - T650 - T700p - T755p - T800w - Pre
  4. #724  
    Quote Originally Posted by hofs1 View Post
    I finally set up Mode Switcher to turn off screen when on the touch stone and it seems much cooler while charging now.....only time will tell....and pandora still plays fine at the 500mgz speed but screen is Off.

    http://forums.precentral.net/webos-p...ml#post2420066
    Um! Mode switcher... I didn't know about this. :-)
  5. #725  
    If you have your screen "on" brightness set to a low/normal level (I use 11% brightness), the screenstate governor will set it to the 1GHz. Then when the normal screen dim occurs, it will drop to the 500MHz after sitting on the Touchstone for a bit.

    If you use Mode Switcher (MS) then you can have it automatically set the brightness wherever you want when on the Touchstone, to force a speed switch, and also choose whether to leave the screen on or off. Just choose an appropriate low brightness setting to force the screenstate switch to low speed.
  6. Tigrao's Avatar
    Posts
    110 Posts
    Global Posts
    111 Global Posts
    #726  
    Quote Originally Posted by xadjustx View Post
    Interesting results using "time dd if=/dev/zero of=/dev/null count=10000000" each test was ran 10 times and I averaged the results.
    This is very interesting to me. It really shows that the higher clock speeds are making a good difference in some computations and that it isn't just some kind of "placebo effect." Just for fun I put my Pre back at the 500 Mhz stock speed and this is what I got:

    10000000+0 records in
    10000000+0 records out
    real 0m 45.36s
    user 0m 8.55s
    sys 0m 36.08s

    Those values are quite a bit higher than any values that you posted. The stock Pre is way slow compared to an OC'ed Pre!
  7.    #727  
    Quote Originally Posted by xadjustx View Post
    Interesting results using "time dd if=/dev/zero of=/dev/null count=10000000" each test was ran 10 times and I averaged the results.

    This is a Palm Pre
    F105 Kernel
    128mb Compache Limit
    1.4.1.1


    800Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 37.61s
    user 0m 5.15s
    sys 0m 24.37s

    900Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 32.37s
    user 0m 4.69s
    sys 0m 21.66s

    1005Mhz
    root@palm-webos-device: time dd if=/dev/zero of=/dev/null count=10000000
    10000000+0 records in
    10000000+0 records out
    real 0m 27.93s
    user 0m 4.24s
    sys 0m 18.72s

    When I do the uname -a I get. Linux palm-webos-device 2.6.24-palm-joplin-3430 #1 Mon Jun 28 16:36:27 UTC 2010 armv7l unknown My question is, did you go back to 2.6.24 kernel or is this still the newer .7 one
    I dont know why the tests are interesting? Isnt it expected? These were the same tests I did with the 1st overclocking kernel. I'm glad you ran the tests tho, I was starting to think no one knew what it was.

    F105 is not 2.6.24.7. Palm's new kernel is way newer so I am not putting any more work into forward porting. Also F104A, F102A, and F105 are not using my original build system, so the version will look different.
    Live free or DIE!
  8. #728  
    Quote Originally Posted by unixpsycho View Post
    Palm's new kernel is way newer so I am not putting any more work into forward porting.

    How way newer is "way newer". Are they using something in the 30's at least?



    M.
  9.    #729  
    Quote Originally Posted by A.Stice View Post
    I'm sorry, but let me see if I understand properly what's going on with the kernel.

    When the screen is on, the clock is 1GHz, when it's off the clock is 500MHz. Also, when the phone is charging it is at 500MHz (except on touchstone) but it takes a screen cycle to set this. Govnah is an app that reads info from the kernel sets flags to control the clock speed.

    Compcache compresses a small amount of ram to provide a large, mid-speed place to store memory to ease the transition from fast memory to slow swap. Also, the TMC error has been disabled.

    The processor is being undervolted to save battery, correct?

    If these assumptions are right, I have a couple of question-suggestions for you. Would it be possible to integrate the functionality of mode switching in to the clock speed control of Govnah? For example, the clock could automatically change from screenstate to userstate with a fixed clock speed when placed on the charging via cable/touchstone or when your battery gets below 20%. I could also potentially see a use for time of day changes, though not nearly as often as the battery level/touchstone charging.

    Also, what about a control for the voltage levels? Every processor is going to have a wide variation in the amount of undervolting it can perform stably with, which would greatly limit any hard coded settings into the kernel (has to be stable on just about every device, right?). A user setting would provide for much better battery life on many phone.

    Anyway, from my testing the battery life, stability and temperatures of this kernel have been excellent. I haven't noticed any significant increase in battery drain over the 800MHz clock, in fact I would lean towards better battery life.

    I have noticed hangs on occasion when loading apps or the launcher, but it's been inconsistent. As I'm using a Sprint Pre I imaging it's more related to the memory being full than to the kernel being unstable, but it still might be relevant.

    As far as temperature testing, I ran sunspider tests back to back for a little over an hour and I played various PDK games (Asphalt, Hero of Sparta, etc) for extended periods of time without problems. The highest temperature that I noticed was about 42C.

    I'm confident that with proper undervolting many of these phones will be able to handle clocks greater than 1GHz, but not at the current voltage settings. Even though the temperatures have been well in the acceptable range they are still 2-3C higher than the 800MHz kernel. Another 200MHz jump would raise them (by my estimation) at least 5-8C. Greater undervolting on the phones that can handle it would probably counter a lot of this.
    You are more than welcomed to make a userspace app to do all these things. We voted against it. I actually had a Touchstone sysfs variable in for F104 for a while then pulled it out. The whole purpose of moving these things into the kernel is to avoid massive overhead within userspace.

    How is undervolting more stable? I am running 1.2gig now and it will not work at all undervolted. PC overclockers know you cant overclock without increasing the voltage and with more cooling.

    The hangs are from IO scheduling and the VM subsystem. Other things need to be tuned since other parts of various subsystems are being hammered due to the faster speeds.
    Live free or DIE!
  10.    #730  
    Quote Originally Posted by Xanadu73 View Post
    How way newer is "way newer". Are they using something in the 30's at least?
    I am not at liberty to say which version.

    But if you look at 2.6.34 you'll see a huge merge of OMAP34xx code into mainline.
    Live free or DIE!
  11. #731  
    Quote Originally Posted by unixpsycho View Post
    I dont know why the tests are interesting? Isnt it expected? These were the same tests I did with the 1st overclocking kernel. I'm glad you ran the tests tho, I was starting to think no one knew what it was.

    F105 is not 2.6.24.7. Palm's new kernel is way newer so I am not putting any more work into forward porting. Also F104A, F102A, and F105 are not using my original build system, so the version will look different.
    My reasoning for it being interesting is I thought that 1005 was all placebo. I honestly thought that the speed wouldn't increase anymore past 900. But it's a steady climb in speed the entire way from 500 up into 1005. I wonder will 1.2Ghz report the same steady climb. And thanks for explaining the kernel version, so in 1.4.5 the kernel is updated?
  12.    #732  
    Quote Originally Posted by xadjustx View Post
    My reasoning for it being interesting is I thought that 1005 was all placebo. I honestly thought that the speed wouldn't increase anymore past 900. But it's a steady climb in speed the entire way from 500 up into 1005. I wonder will 1.2Ghz report the same steady climb. And thanks for explaining the kernel version, so in 1.4.5 the kernel is updated?
    1.2GHz does report steady climb.

    1.4.5 uses the same kernel as 1.4.x. The next major version of webOS is a major overhaul in the way everything works; kernel, UI, internals.
    Live free or DIE!
  13. #733  
    Quote Originally Posted by unixpsycho View Post
    I dont know why the tests are interesting? Isnt it expected? These were the same tests I did with the 1st overclocking kernel. I'm glad you ran the tests tho, I was starting to think no one knew what it was.

    F105 is not 2.6.24.7. Palm's new kernel is way newer so I am not putting any more work into forward porting. Also F104A, F102A, and F105 are not using my original build system, so the version will look different.
    So does this mean that overclocking development is on hold for awhile? With the next major update will we have an overclocked kernel then or will there not be need for it with the changes? When and if 1.4.5 hits the states will we have an overclocked kernel for the Pre?
  14.    #734  
    Quote Originally Posted by mamouton View Post
    So does this mean that overclocking development is on hold for awhile? With the next major update will we have an overclocked kernel then or will there not be need for it with the changes? When and if 1.4.5 hits the states will we have an overclocked kernel for the Pre?
    ssshhhhh. There are already 1.4.5 builds of F105 available and working.

    When the next major version comes along it will take a while to hack it to overclock.
    Live free or DIE!
  15. #735  
    Quote Originally Posted by mamouton View Post
    So does this mean that overclocking development is on hold for awhile? With the next major update will we have an overclocked kernel then or will there not be need for it with the changes? When and if 1.4.5 hits the states will we have an overclocked kernel for the Pre?
    There are 1.4.5 builds of all our kernels in the testing feed.

    Once I get some wider feedback on UberKernel on 1.4.5 (it works fine for me) I'll push it to the public feed.

    -- Rod
  16. #736  
    Quote Originally Posted by unixpsycho View Post
    You are more than welcomed to make a userspace app to do all these things. We voted against it. I actually had a Touchstone sysfs variable in for F104 for a while then pulled it out. The whole purpose of moving these things into the kernel is to avoid massive overhead within userspace.

    How is undervolting more stable? I am running 1.2gig now and it will not work at all undervolted. PC overclockers know you cant overclock without increasing the voltage and with more cooling.

    The hangs are from IO scheduling and the VM subsystem. Other things need to be tuned since other parts of various subsystems are being hammered due to the faster speeds.
    I can quite understand why you guys would vote against it, and considering that I don't know how to write something like that, I'm fine with how it is. Just thinking out loud.

    As far as undervolting being more stable, I believe I need to clarify some. Undervolting isn't inherently more stable, however there are voltage tiers for each clock speed that you want to run it at where it will run stably. Exactly where those tiers are depends on the tolerances of the individual chip. Because undervolting uses less power and thus produces less heat the lowest tolerable voltage for each clock tier would be the MOST stable state for that clock. In other words, if you're going to run it at 1GHz the lowest voltage your chip can handle should be the most stable in the most situations. Not a big deal, just something to think about.
  17. #737  
    Quote Originally Posted by unixpsycho View Post
    1.2GHz does report steady climb.

    1.4.5 uses the same kernel as 1.4.x. The next major version of webOS is a major overhaul in the way everything works; kernel, UI, internals.
    Would I be wrong to assume that since the Android community topped overclocking of the same processor at 1.3GHz that, that is where we stop seeing the steady climb of about 5 Seconds per 100mhz.
  18. #738  
    Quote Originally Posted by A.Stice View Post
    I can quite understand why you guys would vote against it, and considering that I don't know how to write something like that, I'm fine with how it is. Just thinking out loud.

    As far as undervolting being more stable, I believe I need to clarify some. Undervolting isn't inherently more stable, however there are voltage tiers for each clock speed that you want to run it at where it will run stably. Exactly where those tiers are depends on the tolerances of the individual chip. Because undervolting uses less power and thus produces less heat the lowest tolerable voltage for each clock tier would be the MOST stable state for that clock. In other words, if you're going to run it at 1GHz the lowest voltage your chip can handle should be the most stable in the most situations. Not a big deal, just something to think about.
    Undervolting also reduces the noise margin on the switching thresholds, lowering your stability (which may not be immediately obvious, and will also be temperature and process variation dependent).

    It's a multi-variate problem ...

    -- Rod
  19. #739  
    Quote Originally Posted by xadjustx View Post
    Would I be wrong to assume that since the Android community topped overclocking of the same processor at 1.3GHz that, that is where we stop seeing the steady climb of about 5 Seconds per 100mhz.
    The processor is not the only device in the system, and you can be sure there will be differences in the voltage regulation circuitry and control.

    -- Rod
  20. #740  
    Quote Originally Posted by rwhitby View Post
    Undervolting also reduces the noise margin on the switching thresholds, lowering your stability (which may not be immediately obvious, and will also be temperature and process variation dependent).

    It's a multi-variate problem ...

    -- Rod
    Absolutely, and it's all about optimizing as many variables as you can, my suggestion was mostly oriented toward giving power users who understand a little about it the ability to tweak the settings to get the most performance and stability out of their individual device. After all, there's no real way to fully optimize a broad scale kernel, since every device is so different.

Posting Permissions