Page 59 of 96 FirstFirst ... 949545556575859606162636469 ... LastLast
Results 1,161 to 1,180 of 1910
Like Tree14Likes
  1. ght
    ght is offline
    ght's Avatar
    Posts
    772 Posts
    Global Posts
    886 Global Posts
    #1161  
    Ha! That was the first thing I thought of days ago, but forgot about it. Glad it's something so simple.

    If I delete the Screenstate 500/1000 profile, will it regenerate itself after a crash (which I hope not to experience)?
  2. #1162  
    Quote Originally Posted by rwhitby View Post
    Are you in a position to be able to run Linux commands on the device (using novaterm to access it, not WOSQI cause it's Linux command line feature doesn't work well for capturing more than one line of output) and post the output?

    I would need the output from running:

    "dbus-util --capture govnah"

    by starting that command on the Linux command line, then opening Govnah immediately after boot, and then capturing the output as Govnah opens and displays the wrong profile and posting it here.

    -- Rod
    I thought i had the 1ghz bug fixed but i did not I am not sure how to get to the command line other then WebOS QI unless there is another way of doing it. As stated before i did a full doctor and all but it keeps going back to the 1ghz I made a profile 500/720 screen states thats all i have changed is the max speed and the low 500/720 screen state saved it as a new profile and it works fine unless i do a reboot then its always right back to 1ghz I deleted all profiles but palm default and my 720 screen state profile but after a reboot weather i use the power button or the device reset

    UPDATE: My Roomies pre and my sisters pre are all doing the same thing tried to doctor all 3 of them also just installed pre ware uber and govnah and thats all the mods i have done and still does it
    Last edited by gitit20; 10/15/2010 at 01:03 AM.
    Sprint Palm Pre/Verizon Pre Plus On Sprint/Sprint Pixi Hybrid with WIFI
  3. #1163  
    Quote Originally Posted by rwhitby View Post
    Swipe to delete the Screenstate 500/1000 profile, and it will show your custom profile as being selected.
    @ oil,

    why didn't you tell me about this 'solution' to display my customized uberkernel profile?!

    not sure if you answered this before, but can/will govnah offer the option to create a profile from scratch?

    thanks.

    p.s. does uninstalling/re-installing govnah 'reset/clear' settings in the case that i remove all profiles or something like that?
  4. #1164  
    OK, so I have been having problems with sticky profiles

    this is what I've done to fix it - maybe someone who has been working on govnah will have more insight into whats' going on

    So, I can create my own profile, setting max_freq to 800 mhz
    if I look at /var/palm/event.d/org.webosinternals.govnah-settings

    echo -n 'screenstate' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo -n '125000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo -n '800000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    echo -n '69 66 65 60 48 36 30' > /sys/devices/system/cpu/cpu0/cpufreq/override/vdd1_vsel
    echo -n '55' > /sys/devices/system/cpu/cpu0/cpufreq/override/cpu_hightemp_alarm
    echo -n '50' > /sys/devices/system/cpu/cpu0/cpufreq/override/cpu_hightemp_reset
    echo -n '25' > /sys/devices/system/cpu/cpu0/cpufreq/override/battery_scaleback_percent
    echo -n '500000' > /sys/devices/system/cpu/cpu0/cpufreq/override/battery_scaleback_speed
    echo -n '0' > /sys/devices/system/cpu/cpu0/cpufreq/override/override_charger


    So it looks like it's doing the right thing.

    So I wasn't sure if this script was getting run, so I put a

    cat 'done' > /log/govnah_log.txt, and on next reboot, done was in that txt file

    for some reason, the script is being executed, however if I do a
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq I get 1ghz

    So, I put a sleep 10 above the settings, and now my max freq is right...

    coincidence? some wierd boot up timing problem?

    any ideas?

    thanks
  5. #1165  
    Quote Originally Posted by rwhitby View Post
    Are you in a position to be able to run Linux commands on the device (using novaterm to access it, not WOSQI cause it's Linux command line feature doesn't work well for capturing more than one line of output) and post the output?

    I would need the output from running:

    "dbus-util --capture govnah"

    by starting that command on the Linux command line, then opening Govnah immediately after boot, and then capturing the output as Govnah opens and displays the wrong profile and posting it here.

    -- Rod
    I couldn't get it to paste into a text file so I just snapped a print screen of it. Thanks for your help on this.
    Edit: I added my event.d files from - /var/palm/
    Attached Images Attached Images
    Attached Files Attached Files
    Last edited by lopezpm; 10/15/2010 at 10:42 AM. Reason: added event.d files
  6. #1166  
    so far soo good, even after a clean reboot the only thing that changes in my custom profile is the low speed changes from 1ghz to 125mhz. no matter what. the phone doesn't seem any slower and i still think this is a visual only bug of sorts.
  7. #1167  
    Searched, to no avail. Is it possible to reorder profiles in the list?
  8. #1168  
    Quote Originally Posted by Psychonaut View Post
    Searched, to no avail. Is it possible to reorder profiles in the list?
    No. You can only add to the end, and swipe to delete.

    -- Rod
    Last edited by rwhitby; 10/17/2010 at 10:36 PM.
  9. #1169  
    Quote Originally Posted by rwhitby View Post
    No. You can old add to the end, and swipe to delete.

    -- Rod
    Thanks for the quick reply.
  10. #1170  
    I noticed in the most recent update for Govnah, there were help areas that described nearly everything except the TCP congestion controls. Since iḿ using unixpsychoś f104 kernel with loads of different tcp congestion controls.. I compiled a list of descriptions for each one. I plan on doing some testing for which one is best when the phone is on EVDO and the whatś the best for Wifi.. Any way you could have govnah switch to a different TCP congestion control when someone turns on their wifi?
    For instance.. cubic does moderately well on EVDO, but on Wifi.. Westwood owns it. There are others that work even better.

    Heres the list


    TCP congestion Control

    TCP Tahoe/Reno are the classical models used for congestion control. They exhibit the typical slow start of transmissions. The throughput increases gradually until it stays stable. It is decreased as soon as the transfer encounters congestion, then the rate rises again slowly. The window is increased by adding fixed values. TCP Reno uses a multiplicative decrease algorithm for the reduction of window size. TCP Reno is the most widely deployed algorithm.

    CUBIC is a less aggressive variant of BIC (meaning, it doesn't steal as much throughput from competing TCP flows as does BIC).

    Vegas emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets.

    TCP Hybla aims to eliminate penalization of TCP connections that incorporate a high-latency terrestrial or satellite radio link, due to their longer round trip times.

    BIC uses a unique window growth function. In case of packet loss, the window is reduced by a multiplicative factor. The window size just before and after the reduction is then used as parameters for a binary search for the new window size.

    Westwood+ addresses both large bandwidth/RTT values and random packet loss together with dynamically changing network loads. It analyses the state of the transfer by looking at the acknowledgement packets. Westwood+ is a modification of the TCP Reno algorithm.

    Highspeed TCP: The main use is for connections with large bandwidth and large RTT (such as Gbit/s and 100 ms RTT).

    H-TCP was proposed by the Hamilton Institute for transmissions that recover more quickly after a congestion event. It is also designed for links with high bandwidth and RTT.

    TCP Vegas introduces the measurement of RTT for evaluating the link quality. It uses additive increases and additive decreases for the congestion window.

    YeAH-TCP is a sender-side high-speed enabled TCP congestion control algorithm, which uses a mixed loss/delay approach to compute the congestion window. It's design goals target high efficiency, internal,
    RTT and Reno fairness, resilience to link loss while keeping network elements load as low as possible.

    TCP Veno is optimised for wireless networks, since it was designed to handle random packet loss better. It tries to keep track of the transfer, and guesses if the quality decreases due to congestion or random packet errors.

    Scalable TCP is another algorithm for WAN links with high bandwidth and RTT. One of its design goals is a quick recovery of the window size after a congestion event. It achieves this goal by resetting the window to a higher value than standard TCP.

    TCP-Illinois uses packet loss information to determine whether the window size should be increased or decreased, and uses queueing delay information to determine the amount of increment or decrement. TCP-Illinois achieves high throughput, allocates the network resource fairly, and is incentive compatible with standard TCP.

    TCP Low Priority (lp) is an approach to develop an algorithm that uses excess bandwidth for TCP flows. It can be used for low priority data transfers without "disturbing" other TCP transmissions (which probably don't use TCP Low Priority).

    P.S. This friday is payday, so you guys will definitely be seeing a donation from me to show my appreciation for all this kick *** coding you guys do
  11.    #1171  
    Quote Originally Posted by Psychonaut View Post
    Searched, to no avail. Is it possible to reorder profiles in the list?
    You will be able to in the next release: git.webos-internals.org Git - applications/govnah.git/commit

    Quote Originally Posted by ghostinator View Post
    I noticed in the most recent update for Govnah, there were help areas that described nearly everything except the TCP congestion controls. Since iḿ using unixpsychoś f104 kernel with loads of different tcp congestion controls.. I compiled a list of descriptions for each one.
    Thanks, I will get this in there for the next release.
  12. #1172  
    Quote Originally Posted by ghostinator View Post
    I noticed in the most recent update for Govnah, there were help areas that described nearly everything except the TCP congestion controls. Since iḿ using unixpsychoś f104 kernel with loads of different tcp congestion controls.. I compiled a list of descriptions for each one. I plan on doing some testing for which one is best when the phone is on EVDO and the whatś the best for Wifi.. Any way you could have govnah switch to a different TCP congestion control when someone turns on their wifi?
    For instance.. cubic does moderately well on EVDO, but on Wifi.. Westwood owns it. There are others that work even better.

    Heres the list


    TCP congestion Control

    TCP Tahoe/Reno are the classical models used for congestion control. They exhibit the typical slow start of transmissions. The throughput increases gradually until it stays stable. It is decreased as soon as the transfer encounters congestion, then the rate rises again slowly. The window is increased by adding fixed values. TCP Reno uses a multiplicative decrease algorithm for the reduction of window size. TCP Reno is the most widely deployed algorithm.

    CUBIC is a less aggressive variant of BIC (meaning, it doesn't steal as much throughput from competing TCP flows as does BIC).

    Vegas emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets.

    TCP Hybla aims to eliminate penalization of TCP connections that incorporate a high-latency terrestrial or satellite radio link, due to their longer round trip times.

    BIC uses a unique window growth function. In case of packet loss, the window is reduced by a multiplicative factor. The window size just before and after the reduction is then used as parameters for a binary search for the new window size.

    Westwood+ addresses both large bandwidth/RTT values and random packet loss together with dynamically changing network loads. It analyses the state of the transfer by looking at the acknowledgement packets. Westwood+ is a modification of the TCP Reno algorithm.

    Highspeed TCP: The main use is for connections with large bandwidth and large RTT (such as Gbit/s and 100 ms RTT).

    H-TCP was proposed by the Hamilton Institute for transmissions that recover more quickly after a congestion event. It is also designed for links with high bandwidth and RTT.

    TCP Vegas introduces the measurement of RTT for evaluating the link quality. It uses additive increases and additive decreases for the congestion window.

    YeAH-TCP is a sender-side high-speed enabled TCP congestion control algorithm, which uses a mixed loss/delay approach to compute the congestion window. It's design goals target high efficiency, internal,
    RTT and Reno fairness, resilience to link loss while keeping network elements load as low as possible.

    TCP Veno is optimised for wireless networks, since it was designed to handle random packet loss better. It tries to keep track of the transfer, and guesses if the quality decreases due to congestion or random packet errors.

    Scalable TCP is another algorithm for WAN links with high bandwidth and RTT. One of its design goals is a quick recovery of the window size after a congestion event. It achieves this goal by resetting the window to a higher value than standard TCP.

    TCP-Illinois uses packet loss information to determine whether the window size should be increased or decreased, and uses queueing delay information to determine the amount of increment or decrement. TCP-Illinois achieves high throughput, allocates the network resource fairly, and is incentive compatible with standard TCP.

    TCP Low Priority (lp) is an approach to develop an algorithm that uses excess bandwidth for TCP flows. It can be used for low priority data transfers without "disturbing" other TCP transmissions (which probably don't use TCP Low Priority).

    P.S. This friday is payday, so you guys will definitely be seeing a donation from me to show my appreciation for all this kick *** coding you guys do
    Thanks. Now we just need someone to translate this into terms that an end-user can use to make a decision about which one to use. But this is a great set to include in the meantime.

    At the moment the sticky profiles don't include this info. When they do, you will be able to use Mode switcher to change profiles automatically.

    -- Rod
    Last edited by rwhitby; 10/17/2010 at 11:55 PM.
  13. #1173  
    Ill work on making them less techie. I still havent had a chance to play with the mode switcher much. I just got my 6th refurb pre so Iĺl go ahead and download everything and give it a whirl. Ill have this list less techie sounding by friday hopefully.
  14. #1174  
    I have been able to diagnose and reproduce the performance 125/1000 issue that has been reported:

    kernel: [ 0.570000] OMAP: Setting up clocks.
    kernel: [ 0.570000] OMAP: OPP mismatch: current/target=2:3
    kernel: [ 0.570000] OMAP: Change MPU speed: 250 => 500 MHz
    kernel: [ 0.570000] OMAP: ARM/DSP clock at 500/360 MHz.
    kernel: [ 0.570000] BogoMIPS: 498.07 @500000 KHz
    kernel: [ 1.680000] OMAP cpufreq driver initializing.
    kernel: [ 1.680000] setting new policy for CPU 0: 125000 - 1000000 kHz
    kernel: [ 1.680000] new min and max freqs are 125000 - 1000000 kHz
    kernel: [ 1.680000] governor switch
    kernel: [ 1.680000] governor: change or update limits
    kernel: [ 1.700000] cpuidle: using governor menu
    kernel: [ 11.680000] CPUFreq: battery low! < -1401111936%
    kernel: [ 11.680000] setting new policy for CPU 0: 500000 - 500000 kHz
    kernel: [ 11.680000] new min and max freqs are 500000 - 500000 kHz
    kernel: [ 11.680000] governor: change or update limits
    kernel: [ 13.610000] setting new policy for CPU 0: 500000 - 500000 kHz
    kernel: [ 13.610000] new min and max freqs are 500000 - 500000 kHz
    kernel: [ 13.610000] governor switch
    kernel: [ 13.730000] governor: change or update limits
    kernel: [ 13.730000] setting new policy for CPU 0: 600000 - 500000 kHz
    kernel: [ 21.690000] CPUFreq: battery OK
    kernel: [ 21.690000] setting new policy for CPU 0: 125000 - 1000000 kHz
    kernel: [ 21.690000] new min and max freqs are 125000 - 1000000 kHz
    kernel: [ 21.690000] governor: change or update limits
    root@palm-webos-device:/# cat /var/palm/event.d/org.webosinternals.govnah-settings
    description "Govnah Settings"

    start on stopped finish

    script

    [ "`/usr/bin/lunaprop -m com.palm.properties.prevBootPanicked`" = "false" ] || exit 0
    [ "`/usr/bin/lunaprop -m com.palm.properties.prevShutdownClean`" = "true" ] || exit 0
    [ "`/usr/bin/lunaprop -m -n com.palm.system last_umount_clean`" = "true" ] || exit 0

    echo -n 'performance' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    echo -n '600000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    echo -n '600000' > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

    end script
    root@palm-webos-device:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    performance
    root@palm-webos-device:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    125000
    root@palm-webos-device:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    1000000
    The failure mechanism is this:

    1) The kernel boots with the userspace governor, with the limits at 125MHz and 1GHz, but the boot speed set correctly to 500MHz.
    2) The battery is sampled, but the battery one-wire device driver has not been initialised yet. The routine for sampling the battery percentage returns -1 to indicate an error.
    3) An incorrect battery scaleback is initiated, and the current min and max frequencies are saved so that they can be restored later.
    4) The Govnah sticky profile is applied. The governor changes to performance 600/600 in this case. However, since the max freq is 500MHz, the new max of 600MHz is not accepted by the kernel. Applying a sticky profile while a battery or temperature clamp-down is in effect will not work correctly.
    5) The battery is sampled, and the the battery one-wire device driver is now operational and reports the true battery percentage. The saved values for min and max freq (125MHz/1GHz) are restored, but incorrectly write over the values from the sticky profile.
    6) Govnah correctly reports the current state of the kernel when opened.

    So it's a kernel bug, not a Govnah bug.

    -- Rod
    Last edited by rwhitby; 10/18/2010 at 06:53 AM.
    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
  15. #1175  
    Just updated to v0.7.3 and now the setting stick. I can reset from either the
    Device Info --> Reset Options
    or
    Holding the power button down and "Device Reset"

    I had tried Doctoring it, uninstalling and installing UK and Govnah.
  16. #1176  
    Quote Originally Posted by rwhitby View Post
    I have been able to diagnose and reproduce the performance 125/1000 issue that has been reported:

    <...snip...>

    So it's a kernel bug, not a Govnah bug.

    -- Rod
    Easy enough patch... guess I should never assume other drivers are loaded and polling before loading the governor.
    Live free or DIE!
  17. #1177  
    Quote Originally Posted by lopezpm View Post
    Just updated to v0.7.3 and now the setting stick. I can reset from either the
    Device Info --> Reset Options
    or
    Holding the power button down and "Device Reset"

    I had tried Doctoring it, uninstalling and installing UK and Govnah.
    im going to try this right now... awesome!
  18. #1178  
    Quote Originally Posted by rwhitby View Post
    I have been able to diagnose and reproduce the performance 125/1000 issue that has been reported:







    The failure mechanism is this:

    1) The kernel boots with the userspace governor, with the limits at 125MHz and 1GHz, but the boot speed set correctly to 500MHz.
    2) The battery is sampled, but the battery one-wire device driver has not been initialised yet. The routine for sampling the battery percentage returns -1 to indicate an error.
    3) An incorrect battery scaleback is initiated, and the current min and max frequencies are saved so that they can be restored later.
    4) The Govnah sticky profile is applied. The governor changes to performance 600/600 in this case. However, since the max freq is 500MHz, the new max of 600MHz is not accepted by the kernel. Applying a sticky profile while a battery or temperature clamp-down is in effect will not work correctly.
    5) The battery is sampled, and the the battery one-wire device driver is now operational and reports the true battery percentage. The saved values for min and max freq (125MHz/1GHz) are restored, but incorrectly write over the values from the sticky profile.
    6) Govnah correctly reports the current state of the kernel when opened.

    So it's a kernel bug, not a Govnah bug.

    -- Rod
    hopefully it can get sorted out, i knew i wasn't crazy!
  19. #1179  
    Quote Originally Posted by fixxxer1022 View Post
    im going to try this right now... awesome!

    Read Rod's post (and 'Psycho's follow up)...


    M.
  20. #1180  
    Quote Originally Posted by Xanadu73 View Post
    Read Rod's post (and 'Psycho's follow up)...


    M.
    yeah the setting still won't stick after reboot. i still get the 125/1ghz bug. will the kernel be updated at all?

    i also notice the delta kernel reads 125/800 in govnah as well.

Posting Permissions