[HTC Sensation] IshouldntbeHere:
Definitions and Terms you need to know​

Linux Android Kernel

Android's kernel is based on the Linux kernel and has further architecture changes by Google outside the typical Linux kernel development cycle.[57] Android does not have a native X Window System nor does it support the full set of standard GNU libraries, and this makes it difficult to port existing Linux applications or libraries to Android.[58]

Certain features that Google contributed back to the Linux kernel, notably a power management feature called wakelocks, were rejected by mainline kernel developers, partly because kernel maintainers felt that Google did not show any intent to maintain their own code.[59][60][61] Even though Google announced in April 2010 that they would hire two employees to work with the Linux kernel community,[62] Greg Kroah-Hartman, the current Linux kernel maintainer for the -stable branch, said in December 2010 that he was concerned that Google was no longer trying to get their code changes included in mainstream Linux.[60] Some Google Android developers hinted that "the Android team was getting fed up with the process", because they were a small team and had more urgent work to do on Android.[63]

However, in September 2010, Linux kernel developer Rafael J. Wysocki added a patch that improved the mainline Linux wakeup events framework. He said that Android device drivers that use wakelocks can now be easily merged into mainline Linux, but that Android's opportunistic suspend features should not be included in the mainline kernel.[64][65] In 2011 Linus Torvalds said that "eventually Android and Linux would come back to a common kernel, but it will probably not be for four to five years".[66]

In December 2011, Greg Kroah-Hartman announced the start of the Android Mainlining Project, which aims to put some Android drivers, patches and features back into the Linux kernel, starting in Linux 3.3.[67] further integration being expected for Linux Kernel 3.4.[68]

​

CIFS

(Common Internet File System) The file sharing protocol used in Windows. It evolved out of the SMB (Server Message Block) protocol in DOS, which is why the terms CIFS/SMB and SMB/CIFS are commonly used. The word "Internet" in CIFS does not refer to the global Internet but to generic internetworking. The term was coined in the 1996 time frame when Microsoft submitted CIFS to the IETF and before the global Internet had become mainstream. See file sharing protocol, SMB and Samba.

NLS UTF-8

UTF-8 allows you to work in a standards-compliant and internationally accepted multilingual environment, with a comparatively low data redundancy. UTF-8 is the preferred way for transmitting non-ASCII characters over the Internet, through Email, IRC or almost any other medium. Despite this, many people regard UTF-8 in online communication as abusive. It is always best to be aware of the attitude towards UTF-8 in a specific channel, mailing list or Usenet group before using non-ASCII UTF-8.

TUN

This allows you to access an openVPN network using your android device.

Kineto gan

this driver allows you to let your android device make phone calls over VOIP network. (Tmobile currently uses this feature)

Kernel Governors​

Ondemand

This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.

OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.

This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.

Performance Governor

This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).

Powersave Governor

The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.

Conservative Governor

This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.

Userspace Governor

This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.

Interactive Governor

Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.

Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.

However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.

Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.

Lagfree

Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.

IO Schedulers​

Input/output (I/O) scheduling is a term used to describe the method computer

operating systems decide the order that block I/O operations will be submitted

to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'.

I/O schedulers can have many purposes depending on the goal of the I/O

scheduler, some common goals are:

- To minimize time wasted by hard disk seeks.

- To prioritize a certain processes' I/O requests.

- To give a share of the disk bandwidth to each running process.

- To guarantee that certain requests will be issued before a particular deadline.

NOOP

The NOOP scheduler inserts all incoming I/O requests into a simple, unordered

FIFO queue and implements request merging.

The scheduler assumes I/O performance optimization will be handled at some

other layer of the I/O hierarchy; e.g., at the block device; by an intelligent HBA

such as a Serial Attached SCSI (SAS) RAID controller or by an externally

attached controller such as a storage subsystem accessed through a switched

Storage Area Network).

NOOP scheduler is best used with solid state devices such as flash memory

or in general with devices that do not depend on mechanical movement to

access data (meaning typical "hard disk" drive technology consisting of seek

time primarily, plus rotational latency). Such non-mechanical devices do not

require re-ordering of multiple I/O requests, a technique that groups together

I/O requests that are physically close together on the disk, thereby reducing

average seek time and the variability of I/O service time.

CFQ

CFQ, also known as "Completely Fair Queuing", is an I/O scheduler for the

Linux kernel which was written in 2003 by Jens Axboe.

CFQ works by placing synchronous requests submitted by processes into

a number of per-process queues and then allocating timeslices for each of the

queues to access the disk. The length of the time slice and the number of

requests a queue is allowed to submit depends on the IO priority of the given

process. Asynchronous requests for all processes are batched together in fewer

queues, one per priority. While CFQ does not do explicit anticipatory IO

scheduling, it achieves the same effect of having good aggregate throughput for

the system as a whole, by allowing a process queue to idle at the end of

synchronous IO thereby "anticipating" further close IO from that process. It can

be considered a natural extension of granting IO time slices to a process.

DEADLINE

The goal of the Deadline scheduler is to attempt to guarantee a start service

time for a request. It does that by imposing a deadline on all I/O operations

to prevent starvation of requests. It also maintains two deadline queues, in

addition to the sorted queues (both read and write). Deadline queues are basically

sorted by their deadline (the expiration time), while the sorted queues are sorted

by the sector number.

Before serving the next request, the Deadline scheduler decides which queue to

use. Read queues are given a higher priority, because processes usually block

on read operations. Next, the Deadline scheduler checks if the first request in the

deadline queue has expired. Otherwise, the scheduler serves a batch of requests

from the sorted queue. In both cases, the scheduler also serves a batch of requests

following the chosen request in the sorted queue.

VR

Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request. May be best for benchmarking because at the peak of it's 'form' VR performs best. Performance fluctuation results in below-average performance at times. Least reliable/most unstable.