[KERNEL] [GPL] [GN] franco.Kernel r398

The Gingerbread Man · Feb 20, 2013

Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

reysonance said:
I do know, I'm just suggesting an alternative from MiNCO?

Not to be taken as I'm driving people away from MiNCO...

I run stock rom on both my gnex and n7

Sent from my Nexus 7 using Tapatalk HD

reysonance · Feb 20, 2013

The Gingerbread Man said:
I run stock rom on both my gnex and n7

Sent from my Nexus 7 using Tapatalk HD

Since you're using a stock rom on your GN, do you have this bug where the stock browser URL bar basically become unresponsive, goes pitch black after you refresh a page, and then erratically disappears, because that's honestly the only thing that keeping me away from stock ROM, I've cleared data+cache, factory reset, hell even reinstall the stock image and oddly enough it's still there.

osm0sis · Feb 20, 2013

I use the Labs quick controls in stock browser. Best way to get around, should avoid your browser bar issue too.

reysonance · Feb 20, 2013

osm0sis said:
I use the Labs quick controls in stock browser. Best way to get around, should avoid your browser bar issue too.

Actually the problem start appearing after I enabled the quick control, so basically I have a 60dp thick stausbar, can't enter any search terms too since everything displayed on it basically sort of freeze, so if I delete a word the word doesn't actually get deleted, if a write a new one it'll overlap the previous text.

I'll try flashing 4.2.1 and updating via OTA, maybe that'll change something.

LordDeath · Feb 20, 2013

Sometimes my device seems to be very slow and the whole system lags terribly.
According to some task managers the CPU has ~80% iowait and I don't know which app or which wrong kernel setting could cause this.
Going back to the default CM10.1 kernel also does not change this.

Could this be caused by some tweaks done by the france Kernel updater? Or is this issue totally unrelated to it?

julian.kueh · Feb 20, 2013

Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

Running 4.2.2 with Franco 365 here. No problems so far. Smooth and fast.

Sent from my Galaxy Nexus using xda app-developers app

lightingcloud · Feb 20, 2013

I don't get it. This is my 900setting

#!/system/bin/sh
# chmod -R 755 /system/etc/init.d

echo "interactive" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 15000 > /sys/devices/system/cpu/cpufreq/interactive/above_hispeed_delay
echo 95 > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo 729600 > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo 45000 > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo 85 > /sys/devices/system/cpu/cpufreq/interactive/target_loads

echo "deadline" > /sys/block/mmcblk0/queue/scheduler;
echo 512 > /sys/block/mmcblk0/queue/read_ahead_kb;

echo 0 > /sys/class/backlight/s6e8aa0/acl_set;
echo 5 > /sys/devices/platform/omapdss/manager0/gamma;
echo -5 > /sys/module/panel_s6e8aa0/parameters/contrast;
echo "-4 0 5" > /sys/class/misc/colorcontrol/v1_offset;

#sleep 2;
echo "1900000000 1950000000 2150000000" > /sys/class/misc/colorcontrol/multiplier;

#sleep 35;
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch;
echo 1 > /sys/block/mmcblk0/queue/iosched/front_merges;
echo 6 > /sys/block/mmcblk0/queue/iosched/writes_starved;
echo 3500 > /sys/block/mmcblk0/queue/iosched/write_expire;
echo 351 > /sys/block/mmcblk0/queue/iosched/read_expire;

same settings in f.ku

when I reboot, the values in f.ku are all changed to default (except color). why? ?___?

shreddintyres · Feb 20, 2013

malaroth said:
I DO have tentative row tweaks... there's no guarantee they'll fully set on boot even with an init.d script but if you'd like to try... 900rowtweaks

They're far from being perfected but they DO feel a whole lot more smooth
Franco r365
JBSourcery 4.5.5

---------- Post added at 09:06 AM ---------- Previous post was at 08:54 AM ----------

But if you're gonna use them... please give me feedback. Lemme know where you get lag and hangups, it really shouldn't happen much but I need to know if I've lowered read priority too much or not increased write priority enough

Franco r365
JBSourcery 4.5.5

I intend to start testing your values shortly, i just wanted to add what ive thought up regarding each of the different tunables, (Ive yet to have sufficient free time to really start messing around with each individual tunable and testing the way i would like to as a result of school. but here is atleast some of my theory on how the tunables MIGHT work

Config options
+==============
+1. hp_read_quantum: dispatch quantum for the high priority READ queue
+ (default is 100 requests)
+2. rp_read_quantum: dispatch quantum for the regular priority READ
+ queue (default is 100 requests)
+3. hp_swrite_quantum: dispatch quantum for the high priority
+ Synchronous WRITE queue (default is 2 requests)
+4. rp_swrite_quantum: dispatch quantum for the regular priority
+ Synchronous WRITE queue (default is 1 requests)
+5. rp_write_quantum: dispatch quantum for the regular priority WRITE
+ queue (default is 1 requests)
+6. lp_read_quantum: dispatch quantum for the low priority READ queue
+ (default is 1 requests)
+7. lp_swrite_quantum: dispatch quantum for the low priority Synchronous
+ WRITE queue (default is 1 requests)
+8. read_idle: how long to idle on read queue in Msec (in case idling
+ is enabled on that queue). (default is 5 Msec)
+9. read_idle_freq: frequency of inserting READ requests that will
+ trigger idling. This is the time in Msec between inserting two READ
+ requests. (default is 8 Msec)
+
+Note: Dispatch quantum is number of requests that will be dispatched
+from a certain queue in a dispatch cycle.

my difficulty is understanding lines 1-7 specifically when it references quantum. I've read the note and understand that Dispatch quantum has to do with the number of requests that will be dispatched(discarded?) in a cycle. What i dont understand is quantum referring to something similar to "entropy" that we see mentioned in most kernel documentation?

my understanding that increasing 1-7 will generally lead to lag and greater overhead while dropping it will lead to higher consumption of battery but potentially less overhead increasing overall performance

increasing 8 would lead to lag cuz the cpu would hang in idle longer, definitely increase battery life as power consumption at idle is negligble

increasing 9 would lead to lag and probably worsen battery life to some extent because read actions would take longer to perform and would introduce lag, reducing would lead to generally faster processing of read requests, (presently this is set at 20ms by Default in Franco kernel)

@malaroth i'd appreciate it if you could give me any more insight into what these values mean.

- Cheers

osm0sis · Feb 20, 2013

lightingcloud said:
I don't get it. This is my 900setting

same settings in f.ku

when I reboot, the values in f.ku are all changed to default (except color). why? ?___?

Your sleeps are commented out.

LibertyMonger · Feb 20, 2013

I strayed away from the Franco for the last week or so and had nothing but problems. I am back now on r365 and I notice a great difference just over night. Battery is much better, only lost 3% overnight and have already sent a few texts and my issue with screen freezing up is gone. I know other kernels are performing well for others, just not me and i haven't quite grasped the knowledge of controlling kernels yet. Haven't taken the time to study up on it and really never had to fool with any settings in the past. I usually am content with the performance right out of the box and that's how I like it! lol. Thanks a bunch Franco

sajty · Feb 20, 2013

My experience:

Ondemand+deadline,384 min,10xx max,5xx max screen off.Screen is off and i have incoming mail with sound notification enabled.Sound is very "laggy" for first few moments,then goes normal.New email and happened again.

So i tried change scheduler to noop and problem is gone.Something wrong with deadline?

ChazzMatt · Feb 20, 2013

reysonance said:
Try Mmuzzy's, a pretty good alternative for lean AOSP build like rascarlo's and minooch's, both which hasn't been updated to 4.2.2 AFAIK.

Interesting. Thanks for the suggestion. Hadn't heard of that one. I was running Xylon, but decided to go stock for 4.2.2. Before Xylon I was running a lite AOSP ROM, and think I really prefer that. Will try it this weekend, when I get some free time.

[ROM] [AOSP] MMuzzyROM for Maguro - Jelly Bean 4.2.2 - JDQ39

lightingcloud · Feb 20, 2013

osm0sis said:
Your sleeps are commented out.

With or without the comment, it still don't work. None of the command in the file. Should I put them in separate files?

Also I experienced some play store related freezes, and I noticed they happen ONLY when some app is updating/downloading and the screen is about to turn off. If I keep using the device everything is fine.

malaroth · Feb 20, 2013

shreddintyres said:
I intend to start testing your values shortly, i just wanted to add what ive thought up regarding each of the different tunables, (Ive yet to have sufficient free time to really start messing around with each individual tunable and testing the way i would like to as a result of school. but here is atleast some of my theory on how the tunables MIGHT work

Config options
+==============
+1. hp_read_quantum: dispatch quantum for the high priority READ queue
+ (default is 100 requests)
+2. rp_read_quantum: dispatch quantum for the regular priority READ
+ queue (default is 100 requests)
+3. hp_swrite_quantum: dispatch quantum for the high priority
+ Synchronous WRITE queue (default is 2 requests)
+4. rp_swrite_quantum: dispatch quantum for the regular priority
+ Synchronous WRITE queue (default is 1 requests)
+5. rp_write_quantum: dispatch quantum for the regular priority WRITE
+ queue (default is 1 requests)
+6. lp_read_quantum: dispatch quantum for the low priority READ queue
+ (default is 1 requests)
+7. lp_swrite_quantum: dispatch quantum for the low priority Synchronous
+ WRITE queue (default is 1 requests)
+8. read_idle: how long to idle on read queue in Msec (in case idling
+ is enabled on that queue). (default is 5 Msec)
+9. read_idle_freq: frequency of inserting READ requests that will
+ trigger idling. This is the time in Msec between inserting two READ
+ requests. (default is 8 Msec)
+
+Note: Dispatch quantum is number of requests that will be dispatched
+from a certain queue in a dispatch cycle.

my difficulty is understanding lines 1-7 specifically when it references quantum. I've read the note and understand that Dispatch quantum has to do with the number of requests that will be dispatched(discarded?) in a cycle. What i dont understand is quantum referring to something similar to "entropy" that we see mentioned in most kernel documentation?

my understanding that increasing 1-7 will generally lead to lag and greater overhead while dropping it will lead to higher consumption of battery but potentially less overhead increasing overall performance

increasing 8 would lead to lag cuz the cpu would hang in idle longer, definitely increase battery life as power consumption at idle is negligble

increasing 9 would lead to lag and probably worsen battery life to some extent because read actions would take longer to perform and would introduce lag, reducing would lead to generally faster processing of read requests, (presently this is set at 20ms by Default in Franco kernel)

@malaroth i'd appreciate it if you could give me any more insight into what these values mean.

- Cheers

It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought these numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.
Franco r365
JBSourcery 4.5.5

creeve4 · Feb 21, 2013

Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.

julian.kueh · Feb 21, 2013

Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

I'm running mmuzzy's aosp 4.2.2 on Franco 365. No probs.

Sent from my Galaxy Nexus using xda app-developers app

Empty Hand · Feb 21, 2013

Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

creeve4 said:
The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.

r365 is working fine for me on zaphod's toro build from today (up on Androtransfer). It's the first aokp build that it's worked on for me.

Sent from my Galaxy Nexus using Tapatalk 2

creeve4 · Feb 21, 2013

creeve4 said:
The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.

Bad kernel download. I re-downloaded from f.KU app and all is good

osm0sis · Feb 21, 2013

lightingcloud said:
I don't get it. This is my 900setting

same settings in f.ku

when I reboot, the values in f.ku are all changed to default (except color). why? ?___?

lightingcloud said:
With or without the comment, it still don't work. None of the command in the file. Should I put them in separate files?

Also I experienced some play store related freezes, and I noticed they happen ONLY when some app is updating/downloading and the screen is about to turn off. If I keep using the device everything is fine.

Did you create the file on PC and copy to phone? My only thought is you have the wrong end-of-line formatting.

malaroth said:
It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought the numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.

Just had to quote all that again to say, wow! Good read. Thanks for that brother!

bigknowz · Feb 21, 2013

Defaults changing

malaroth said:
It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought these numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.
Franco r365
JBSourcery 4.5.5

Are these tweaks being worked into ROW for r366?

[KERNEL] [GPL] [GN] franco.Kernel r398

Senior Member

Senior Member

Senior Recognized Developer / Contributor

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Recognized Developer / Contributor

Senior Member

Senior Member

Recognized Contributor

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Recognized Developer / Contributor

Senior Member

Similar threads

Top Liked Posts