Jump to navigation Jump to search
An App to do things.
Available in the WebOS Internals Testing Feed
- Main Scene
- Title Header (like preware/wirc/etc webos-internals apps)
- Current Governor (Tap to go to Governor Settings)
- Current Frequency
- Misc Stats
- Graph of CPU temp over time
- Auto-generate wallpaper with current graphs
- CPU Governor Scene
- Dropdown to change governor (SelectList)
- Form of all current settings for selected governor (dynamically generated from information provided by service)
- IO Scheduler Scene
- Dropdown to select scheduler (cfq, noop, as etc.)
- TCP Congestion Algo Scene?
- App Icon (changes to display indication of CPU temp)
- Govnah is saving data to an array which grows over time and sucks down CPU time/memory iterating over the array.
- Use sqlite db for saving?
- To reduce disk writes, have a preference option to save to /media/ramdisk if the user is only interested in the current session for pinch zooming - should reduce disk writes and improve performance though data will be lost on boot.
- Preference setting for frequency of polling.
- Use fixed array or circular buffer instead, though this will stop pinch scrolling from going back too far (another preference option?)
- Generic items (needed for all)
- scaling_max_freq - Set the maximum frequency your CPU(s) are allowed to scale to. Look at the output from scaling_available_frequencies
- scaling_min_freq - Same as scaling_max_freq but setting a value that will not allow the CPU(s) to go below.
- sampling_rate - This is measured in microseconds (one millionth of a second). This is how often you want the kernel to look at the CPU usage and to make decisions on what to do about the frequency. Typically this is set to values of around '10000' or more. If you wanted to set the sampling rate to 1 second you would set it to 1000000 like in the following example.
- sampling_rate_(min|max) - This is minimum and maximum sampling rates available that you may set 'sampling_rate' to. I believe in microseconds also.
- up_threshold - This defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether or not it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.
- ignore_nice_load - This parameter takes a value of '0' or '1'. When set to '0' (its default), all processes are counted towards the 'cpu utilization' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the overall usage calculation.
- powersave_bias - This modifies the behavior of the ondemand governor to save more power by reducing the target frequency by a specified percentage. By default, (powersave_bias = 0), the ondemand governor selects the minimum processor frequency that can still complete a workload with minimal idle time. Doing so should result in the highest performance to power efficiency ratio. In some cases, you might prefer a greater emphasis on power efficiency than performance. In this case, set the powersave_bias parameter to a value between 1 and 1000 to reduce the target frequency by one-thousandth of that value. For example, set powersave_bias to 100 for a one-tenth reduction in target frequency. In this case, if the governor chooses a target frequency of 2 GHz (with powersave_bias = 100), the governor instead will request 1.8GHz – a one-tenth reduction. If 1.8 GHz is an exact match with an available hardware frequency (listed in the scaling_available_freq parameter), the processor is set to this frequency. If 1.8 GHz is not available, the processor fluctuates between the closest available upper and lower frequencies for an average frequency of 1.8 GHz. (from IBM web page). The original author of the ondemand powersave_bias code explains it as "For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8" (from http://osdir.com/ml/kernel.cpufreq/2006-07/msg00114.html ) - the key word appears to be "average". The author also warns "In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz".
- freq_step - This describes what percentage steps the CPU freq should be increased and decreased smoothly by. By default the CPU frequency will increase in 5% chunks of your maximum CPU frequency. You can change this value to anywhere between 0 and 100 where '0' will effectively lock your CPU at a speed regardless of its load whilst '100' will, in theory, make it behave identically to the "ondemand" governor.
- down_threshold - This is same as the 'up_threshold' found for the "ondemand" governor but for the opposite direction. For example when set to its default value of '20' it means that if the CPU usage needs to be below 20% between samples to have the frequency decreased.
- sampling_rate - same as ondemand.
- sampling_rate_(min|max) - same as ondemand.
- up_threshold - same as ondemand.
- ignore_nice_load - same as ondemand.
- scaling_setspeed - one of the values from scaling_available_frequencies
- NB - when userspace is selected LunaSysMgr will change the frequency as it feels.
- Nothing special
- Nothing special
- http://www.pdfgeni.com/book/Performance-analysis-of-loss-based-high-speed-TCP-congestion-control-algorithms-pdf.html - collection of documents on implementation of different IPv4 congestion control methods.