[KERNEL][OC][STOCK/CROMI] JB 4.2.1 ★ Hundsbuah ★ 10.6.1.14.10 ★ v3.4.0 ★ BETA v3.4.4

[KERNEL][OC][STOCK/CROMI] JB 4.2.1 ★ Hundsbuah ★ 10.6.1.14.10 ★ v3.4.0 ★ BETA v3.4.4

1Thanks to: _that, sbdags, steveman29 and all testers out here

If you like my work you can donate by clicking the link below:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=BGD8ETXAPXNEQ
Please tell me your xda nickname in the donation!

Donators: steveman29, bads3ctor, Douglas Wing, pastorbob62, Yamir Gonzalez, ziggy71, sbdags, Mackis, Daruniafx, MotoFlasher, tijsva, JoinTheRealms, faustus1005, ubefuct, LetMeKnow


IMPORTANT:
Please always try to undervolt the CPU as much as you can/as its running stable! Less VCORE, less heat, more batterylife!
If you get reboots and/or cpu gov scaling errors, you have undervolted too much!



PLL Calculation Excel:
I have also made a cpu pll calculation excel sheet. there you can calculate your correct M,N values for a specific freq
Download here: http://www29.zippyshare.com/v/35204606/file.html

Printout hexdumps from edp.c:
I also wrote a small c-programm to print out the content of the edp hex-dump.
just copy the hex values from your edp.c in edplimits.c. look in the file and you know how to.
Its an eclipse project.
The output is a file called: edp_entrys.txt
Check out your speedo_id and regulator id and search for it in the .txt file


Download here: http://www58.zippyshare.com/v/40584147/file.html

Source:

Kernel:
https://github.com/Hundsbuah/tf700t_10_6_1_14_4

MyApp:
https://github.com/Hundsbuah/HundsbuahsKernelTweaks


If you dont make any changes to my kernel here my recommendation:

- Use asus batterysaver for (as the name sais: powersaving)
- use asus balanced mode for gaming or heavy loaded apps (this is not oc too much so it wont burn ur hand away)
- use asus normal/performance mode for daily use (surfing, browsing apps, just the normal daily use (except gaming!!)
- if you have our own frequency setting, i recommend for gaming: 1600MHz CPU Quadcore max. and 600MHz GPU max


Need help - Still something unclear?: THX lucius.zen
http://xdaforums.com/showthread.php?t=2232715



Android App for my Kernel:

v2.3
v2.4

Linux Installer (needed by my App):

v1.0
BETA RELEASES JB4.2:

v3.4.1

v3.4.2
v3.4.3
v3.4.4
STABLE RELEASES JB4.2:

v3.4.0
data2sd patch:
Bugs:
- you tell me


Please report any problems / feedback

TCP Congestion Algorithm Testing

Hey Guys,

Did some testing of TCP congestion algorithms to determine which is best for use on our device. For a brief explanation of TCP/IP protocols and network congestion control algorithms see the "Appendix" at the bottom of this post.

Overview:
I decided to test "cubic" as it is default as well as "reno", "lp", and "westwood" because what little data others have gathered indicates these algorithms have the most promise but need further testing. I ran more tests using "cubic" because the variance of the data set was very high. If we want to accurately compare mean values from two data sets we must be sure that the variance within the two data sets does not exceed the variance between the two data sets. This is typiclly done using a formal statistical hypothesis test, however, I am too lazy to calculate the standard deviation of each set. Thus, to ensure variability doesnt throw off our comparison I ran extra tests using cubic so that we can rest assured despite having not utilized formal hypothesis tests. I won't go into details but comparing the means of seperate data sets is completely useless unless we account for variance within the data through hypothesis tests or other measures. Do not listen to anyone who tells you otherwise lol. Averages are moot unless variance is accounted for.

Method:
The following alrogithms were tested in sequential blocks. Within each block tests were completed immediately following each other - nothing was done in between tests aside from taking a screenshot to record data. After completing a block of trials a terminal was opened and the TCP congestion algorithm was changed utilizing a script. The next block of tests immediately followed. All tests were completed from exactly the same location. This methodology was utilized to keep conditions as consistent as possible for the purpose of minimizing the influence of external factors, which are particularly plentiful when testing wifi speed.

Measures:
n = number of tests
p = ping (ms)
d = download speed (mb/s)
u = upload speed (mb/s)
v = standard deviation - not actually calculated - simple ranking of the relative variance of each data set - yes, this involved the use of eyes and not a calculator; however, I made sure I ran enough tests to understand the degree of variability within each data set

Results:
Cubic:
n = 14
p = 57.6
d = 8.65
u = 6.19
v = 4

LP:
n = 8
p = 40.3
d = 9.07
u = 4.51
v = 1

Reno:
n = 8
p = 42
d = 8.47
u = 3.53
v = 3

Westwood:
n = 8
p = 39.5
d = 9.66
u = 4.28
v = 2

Conclusion:
It appears that "westwood" is the most promising TCP congestion algorithm. However, I would like to run "reno" and "westwood" through another 8 trials to increase confidence as their data had a moderate degree of variance. The algorithm "yeah" also is yet to be tested. Once these tests are finished I will do another preliminary comparison to estimate which two TCP congestion algorithms are best. The top two algorthms will then be subjected to a formal hypothesis test to confirm my final results.


Appendix - TCP/IP Protocols and Network Congestion Control Algorithms:
TCP/IP is a core set of communication protocols used to transfer data over the Internet and similar networks. IP packets are the vehicle devices use to transfer data between an application program and a web host. They are comprised of a header containing the source/destinatin address (among other things) and a payload, which contains the actual data to be sent. TCP, part of the transport internet layer, provides intermediate communication between an application program and a host.

When sending large chunks of data an application program can issue a single request to TCP instead of breaking down data into a series of IP packets and requests. Due to network congestion and other factors IP packets are often lost. TCP maintains the ordered delivery of packets by detecting packet loss, requesting retransmission, reordering data, and minimizing network congestion. When a host receives a stream of packets it reassembles the data into the form that it was originally sent. Once the receiver confrims the soundness of the data it sends a packet acknowledging its retrieval. To avoid overloading a connection between a program and a host this aknowledgement must occur before more packets can be sent/recieved.

For each connection TCP maintains a congestion window. The TCP congestion window is maintained by the sender and is used to prevent network congestion/overload due to packet loss. When packet aknowledments are received the size of the TCP congestion window increases exponentially until a timeout occurs or the receiver reaches its bandwidth limit. Thus, as more packets are acknowledged the maximum segment size (specifies the largest amount of data in a single TCP segment) of the congestion window becomes larger; every round-trip time the maximum segment size effectively doubles. A mechanism called "slowstart" controls the maximum segment size of the TCP congestion window. To prevent network overload TCP congestion avoidance algorithms modify TCP window size, "slow-start", and the slow-start threshold. Thus, TCP congestion avoidance algorithms have a significant impact on the speed of packet delivery between a sender and receiver

Some thoughts on latest update

Hey Hundsbuah,

Just wanted to give some feedback considering some things ive noticed since using the first kernel you released. Up until this point v1.4.4 gave me the best performance, stability, battery life, and had the least heat. For some reason it worked incredibly well, without data2SD i was getting an average score of 7500 in quadrant. I even converted my external hard drive to FAT32 just so that I could stay on that kernel lol.

However, after seriously tweaking the voltage table v1.9 gives me the best performance and is very stable. The battery drain is a little higher but that is to be expected. When i first installed v1.9 my cpu was producing way too much heat, wasnt stable, and performance was all over the place. I tried undervolting the kernel by -25, then -50, and -75, but it did not improve things at all. cpu consumption at idle was all over the place, the cpu was constantly jumping between really high and low frequencies, and the temperature was very high and would take a long time to drop when the cpu scaled back to lower frequencies. The cpu was also primarily using a few select frequencies, it was only using 475, 910, 1.15, 1.5, and 1.85. I figured that the reason the cpu was jumping so much was bc the voltages were not set right, only certain frequencies were used bc the scaling of the voltage table was off, battery temp took a long time to drop even when frequencies were low bc the voltages for low frequencies were too high. To try and fix these issues i rescaled the voltage table. I created a table that was similar to what you initially had, but i set much lower voltages for lower frequencies and smoothly sclaed the voltages up as frequencies and worload get higher. High frequencies are also running at much lower voltages and i still get great performance.

After rescaling the voltage table my cpu temp is much better, I sit around 30C when idle and go up to 40-42 when running bench marks in performance mode. After finishing a benchmark my cpu temp immediately drops back to 35C, as voltages are scaled back more drastically when my cpu is running lower frequencies. My average score in quadrant is 7450 and performance is excellent, even in power savings mode i rarely get any lag, and i am not using data2SD. When idle my cpu consumption is around 1%-5%. Before i rescaled the voltage table it was betwen 1%-25%. Times spent at different frequencies are much more evenly distributed now, the cpu is better at adjusting its frequency to changes in workload. Things are also more stable, i used to get random reboots when browsing pages with heavy java and flash bc the cpu temp would jump to around 55C. Now i never get random reboots and things are stable, cpu temp never goes over 41C (unless im benchmarking, it sometimes goes up to 44C).

So far I have gotten really great results, i will upload a copy of my voltage table that i saved using android tuner so that you can check it out. If you have android tuner just put this file in the "voltages" directory in the "at" directory in your internal storage so you can load it from the voltage tweaking page in android tuner.

EDIT - for some reason xda doesnt like it when i try to upload anything. Here is the table from top to bottom so anyone can try it out. voltages without frequencies beside them fall to the frequency to the left, saves me time from writing them all out lol.

1300(1.85), 1225(1.7), 1175(1.5), 1150, 1137, 1125, 1112, 1100, 1075(1.4), 1062, 1050, 1037, 1012(1.3), 1000, 987, 975, 950(1.15), 937, 925, 912, 900, 887(1Ghz), 875, 862, 850, 837(910Mhz), 825, 800(760), 787, 775, 762, 750, 737(620), 725, 712, 700, 675(475), 662, 650, 637(1Mhz)

Hope it works as well for you as it has for me.

Lucius

AW: [KERNEL][OC][STOCK/CROMI] Hundsbuah ★ 10.4.4.25 ★ v1.8.3 ★ dualboot

steveman29 said:

Could you revert back to 1800 MHz cpu too? I think it would be better for heat and battery life.

Στάλθηκε από το ASUS Transformer Pad TF700T μου χρησιμοποιώντας Tapatalk 2

Click to expand...

Click to collapse

i figured out the problem why it was unstable and why it was getting so hot. ill upload a new version today

PLEASE DONT USE THE 1.8.x versions any more!

Gesendet von meinem ASUS Transformer Pad TF700T mit Tapatalk 2

New testkernel v2.2 20130405:

- removed gpu_oc interface
- removed gpu_og_volt interface
- setting the frequency limit is now done via cpuX.sh or a terminal emulator
- pwr_cap_limit_1: CPU1, pwr_cap_limit_2: CPU2, pwr_cap_limit_3: CPU3, pwr_cap_limit_4:CPU4
- module parameters can be used in cpuX.sh files or in a terminal emulator with superuser rights (see below for a howto, i recommend to edit the cpuX.sh files ( /system/etc/cpuX.sh) with root explorer i.e)
- voltage table has changed due dvfs table cleanup!!!! dont use your init.d scripts to set the voltages at startup
(delete or disable the scripts first, then install this new testkernel!!)
- added a new module parameter to notify the cpu that the cpu2.sh file was executed and cpu freq limits are (correct) set (look at system/etc/init.d/99bootcompleted)
you dont have to do anything, just dont delete it or you will stuck at 1700MHz (system/etc/init.d/99bootcompleted)
- lpcore oc now works (760MHz lp oc)
- you need a working init.d support!!

HOWTO:

Limiting the CPU:

possible cpu frequencys that can be used to set the maximum allowed frequency (applied via module parameter: echo "1800000" /sys/module/cpu_tegra/parameters/pwr_cap_limit_1):
Here you set frequency values to the module parameters (gpu is different - see below)

Example:

This will limit core1, core2, core3 and core4 to a maximum frequency of 760MHz



Limiting the GPU:

Here you set !!VOLTAGE!! values to the module parameters (not frequencys as by the cpu module parameters!)
You need four calls:
1. echo 1350 > /sys/kernel/tegra_cap/cbus_cap_level
2. echo 1350 > /sys/kernel/tegra_cap/core_cap_level
3. echo 1 > /sys/kernel/tegra_cap/cbus_cap_state
4. echo 1 > /sys/kernel/tegra_cap/core_cap_state

possible (best) gpu voltage values that can be used to limit the gpu frequency to a specific frequency (applied via four parameter settings as described above):

Example: (REMEMBER TO SET THE VOLTAGE AND NOT THE FREQUENCY!!)

This will limit the maximum gpu frequency to 600MHz (good for asus power saver mode i.e) and takes care of clocks depending on gpu clocks


You can also go lower than 1350mV but the gui transisions feels a bit slower then.

Here is the complete VOLT/FREQ Table (in mV and kHz):

You can change the cpu1.sh (asus powersaver mode), cpu2.sh(asus balanced mode) and cpu3.sh(asus normal/performance mode) cpu frequency and gpu voltage (located int: /system/etc/)
to your needs.

Tip: Get rid of the naming of the asus power modes. You can let the cpu1.sh as a powersaver but you can use balanced mode as a max. power mode (1800MHz for cpu revision 9
and 1900MHz for tablet who can handle this frequency and 750MHz GPU) for working/surfing (not gaming!) etc. to make the tablet as fast as possible to respond to your inputs.
cpu3.sh can now be used as a gaming profile (you set cpu to 1600MHz max. and gpu to 650 or 700MHz i.e, so the tablet wont get too hot when playing games/high load)

I have resetted the voltage table to stock voltages because i rebuilded the dvfs table for the cpu0 and cpug.
Therefore as always: Please try to undervolt as much as you can!

Download:

http://www.androidfilehost.com/?w=files&flid=3972

Enjoy the new kernel! And have a nice weekend

/edit: Updated sources on github