yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II Original Android Development] AndreiLux:
The explanation is correct for the lay-man user.

When stepping up from a frequency below freq_for_responsiveness, it takes up_threshold_for_min as the trigger threshold for scaling up to a higher frequency and trigger the up-scaling logic.

When scaling down, we are using the normal up_threshold or up_threshold_at_fast_down (Don't be confused, it's a new thing for next release) as the on-demand frequency target threshold ( current frequency * (up_threshold - down diff) ), and if the virtual load frequency is below that then we enter the down-scaling logic. We set up a new target frequency of virtual load frequency * (up_threshold - down_differential) for the next period.

Now if the target frequency is below freq_for_responsiveness, it additionally checks if the load frequency exceeds the new target frequency by (up_threshold_at_min_freq - down diff) percent, it will disregard the computed target frequency and take freq_for_responsiveness as the next frequency.

if (policy->cur > dbs_tuners_ins.freq_for_fast_down)
up_threshold = dbs_tuners_ins.up_threshold_at_fast_down;
else
up_threshold = dbs_tuners_ins.up_threshold;

if (max_load_freq <
(up_threshold - dbs_tuners_ins.down_differential) *
policy->cur) {
unsigned int freq_next;
unsigned int down_thres;

freq_next = max_load_freq /
(up_threshold -
dbs_tuners_ins.down_differential);

/* No longer fully busy, reset rate_mult */
this_dbs_info->rate_mult = 1;

if (freq_next < policy->min)
freq_next = policy->min;

[B][COLOR="Red"]	down_thres = dbs_tuners_ins.up_threshold_at_min_freq
- dbs_tuners_ins.down_differential;

if (freq_next < dbs_tuners_ins.freq_for_responsiveness
&& (max_load_freq / freq_next) > down_thres)
freq_next = dbs_tuners_ins.freq_for_responsiveness;[/COLOR][/B]

Now back to reality; The above thing is good for 2 reasons: We get more aggressive scaling on the lost most frequencies for better fluidity and "get out faster" from the sluggish parts. Secondly on continuously light loads, even though the lower frequencies could compute that load just fine, we want to do it on the faster ones so that we can race the CPU to idle. The CPU isn't always clocked at whatever frequency but most of the time it is clocked at 0 Hz, i.e. the idle modes turn off the core clock and this is done on a 5µS granularity level.

And lastly, I'm not able to reproduce your music argument unless I up the freq_for_responsiveness to something high, and then it's caused by not compensating up_threshold_at_min_freq by raising it higher. You're breaking the purpose of the that scaling function and of course it doesn't really work that well anymore.

Come next version the governor will gain even more complexity with a few new features. The various parts shouldn't be viewed as a whole as a swiss army knife but surgical scalpels each trying to do their own little purpose. It gets bloody.
[Galaxy Note II Original Android Development] nyarnon:
Very enlighting andreilux please keep that comming is helps us to gain more insight looking forward to the next release.

--

Sent from my N7100 with Perseus 26.1 Omega 7.2 Recovery Clockwork Touch 6.0.1.9 Thanks too the devs and teams.
[Galaxy Note II Original Android Development] gundal:
SO the bolded code, ensures that next freq it hits is the freq for responsiveness (if the load is still greater then the down threshold, and we are under the freq for responsiveness)

meaning it wiill jump to that freq and then start scaling down as needed

I think I understand why my test results proved as they did.

I did not think about the downdifferential being calculated from the up threshold min but still from the normal up thres

which means it wouldnt step down to lower level unless cpu load was under 60 (70 up thres min and 10 down diff)

still. it is hard to see the processor needing > 60% of its power at 1100 mv to run music in the background with screen off.

and you tried to reproduce it? Set the freq for responsiveness to 300 then run a music app,

load cpu tuner, hit reset timers and instantly turn off the screen.

Let the music play for 15 seconds turn on screen and refersh timers, cpuspy will show all of that time at 300

if you do same test with 1400 it will force the cpu to be 1400.

You did make a mention of how this quick upscaling is great for getting us out of the inefficient low frequencies (when computing a fixed high load) its logical, finish the task at hand ASAP and then step down to sleep. However music is not a task that can be accomplished faster, if its decoding properly and not chopping then there is no benefit of being at a higher frequency, I was trying to tune these paramaters to have music play at 200mv, and I was able to by raising the up threshold min to 84, 83 or anything lower would have it step up.

I very much look forward to the next release, most of all because of that usb 1400mhz bug, but now extra governor parameters are getting me excited too lol

thanks for all your work Andrei, you are the man!!
[Galaxy Note II Original Android Development] AndreiLux:
Tried that, stays at 200 for me.

Yes it does, because you're not adjusting the threshold and the logic gets ****ed up.

No that's not what race to idle is about. Of course you can decode music faster, it is not something that is done continuously but something that is done in chunks and buffered. The faster you do the chunks, the more time you stay in idle mode, and power is saved. Any fixed computational load benefits from this, if the computational load is dynamic (Things can always be rendered more fluidly, needing more power) then it isn't as prevalent.

Actually I already deployed the new version on the S3, just waiting a bit before releasing it on the N2.
[Galaxy Note II Original Android Development] gundal:
Hm i just tried this again and even with 40 as min threshold i get it jumping to the freq for responsiveness. You are on the sgs3 right..
[Galaxy Note II Original Android Development] sjkoon:
is it related new commit?
[Galaxy Note II Original Android Development] xonone:
loving the kernel sir. Made my SCH-R950 alot faster and battery life is GREAT.
[Galaxy Note II Original Android Development] gundal:
oooh just read the changelog for alpha 27... o excited for STweaks and not having to use scripter and root browser to confirm changes over and over :p

When do you anticipate releasing it for SGH-i317?
[Galaxy Note II Original Android Development] yahyoh:
WOW i just saw ur update for s3 :cool:

waiting our update :good:

thank u :cowboy:
[Galaxy Note II Original Android Development] gundal:
Hey Andrei,

back to the music arguement and decoding in packets and chunks of the music, in theory it sounds great, but ive noticed my phone will never deep sleep if im listenting to music, it has to be at 200mv min constantly to output the sound.. so would it not make more sense to be constantly active at 200 instaed of active at say 500 then scale to 200 when the decoding is done?

You are clearly very knowledgeable, so please take no offense to my inquires I just want to hear your input!
[Galaxy Note II Original Android Development] SaschaHa:
Had this kernel for a few hours. Sadly the 3D performance was worse than with stock kernel although I set GPU frequence to 533 MHz. Otherwise a great kernel! Thx for this great job! ;)
[Galaxy Note II Original Android Development] albireox:
What do you mean by 3D performance? In games or in benchmarks? Because, if it's the latter, it's irrelevant.
[Galaxy Note II Original Android Development] yahyoh:
i have same problem

like open app's animations sometimes there's dropped frames and on scrolling sometimes ( not so smooth )
[Galaxy Note II Original Android Development] SaschaHa:
@yahyoh:

Both...

In Quadrant it was stuttering and in the last two benchs I had only ~40 fps instead of up to 58.

In Antutu I got less points than with stock kernel (I think, don't know the exact score anymore... also could be that I confused GPU score with 3D score, because 2D+3D = GPU in Antutu)).

In games like "Beach Buggy Blitz" I noticed some stutters. Not as bad as it sounds like, but it was even noticeable.

And also the app drawer (Nova Launcher Prime) was not as fluidy as with stock kernel.

In every other way the kernel was very well :)
[Galaxy Note II Original Android Development] yahyoh:
noticed the same but other than that its great kernel

i hope next build will fix this issue :rolleyes:
[Galaxy Note II Original Android Development] SaschaHa:
There is an other thing, that makes me trouble since ICS update on Galaxy S2, and this still exist on Note 2 (it's not a specific kernel-problem, but seems to be a problem with mali 400 driver or in new Android quellcode)...

So, since ICS came to S2 I noticed rendering issues at particle effects or some other OpenGL ES effects... It's difficult to describe, so here an old thread of mine in Galaxy S2 forum: Rendering issues since ICS

I know, that has nothing to do with Perseus kernel, but the issue is still here on ALL Note 2 devices (and S2 and maybe on some other mali 400 devices) and maybe there can be found a solution :cowboy:

The most users don't realize these issues because of the high resolution of the Note 2-display. But it's still there ;)

Sorry for posting it here but hope dies last ;)
[Galaxy Note II Original Android Development] Sammath:
Been flashing back and forth between the kernels available on the note 2.

I always go back to Perseus in the end, the performance and battery life is the best for me! (overclocked and undervolted)

No problems whatsoever with 3d performance for me.

Maybe it's a rom problem?
[Galaxy Note II Original Android Development] SaschaHa:
Using stock rom.. Don't think so, other kernels are great in 3D
[Galaxy Note II Original Android Development] SandeepEmekar:
@Andreilux

Are you going to add support to stweaks?
[Galaxy Note II Original Android Development] AndreiLux:
I've told several times that yes, I've been working on my implementation for a week. The new version is out already on the S3. The N2 version will be out tonight probably.
[Galaxy Note II Original Android Development] SandeepEmekar:
I'm sorry, I didn't read the complete thread. :|

But it is good to know! :D
[Galaxy Note II Original Android Development] AndreiLux:
I'm getting bored and none of my testers were available for 3 days, so here's a blind build with the new features.

If somebody tests it and tries to see if everything is fine I'll put it up in the first page.
[Galaxy Note II Original Android Development] Pyr0x64:
Thanks Andrei, looking forward to trying the 7105 build :)
[Galaxy Note II Original Android Development] Sammath:
Thanks, gonna test for you and report back :)
[Galaxy Note II Original Android Development] EdgaBimbam:
same features as for s3? ;D sorry if it is noobie question
[Galaxy Note II Original Android Development] AndreiLux:
Yes roughly the same changelog. Just check it out if everything works and after that I'll write up the rest in the OP.
[Galaxy Note II Original Android Development] kevin_diu:
Just wait for n7105 test build :)
[Galaxy Note II Original Android Development] Sammath:
Ok, sound works perfectly fine for me.

Over clocking the cpu and gpu works :)

Thanks for this kernel yay!
[Galaxy Note II Original Android Development] yahyoh:
I will test it ASAP

edit : same bug as red pill : lock screen will hang on lock and on wake up :( :(

do u need Dmesg ? logcat? anything ?
[Galaxy Note II Original Android Development] CitizenLee:
Sweet! Will flash now and report back later this evening :good:
[Galaxy Note II Original Android Development] AndreiLux:
You used the kernel I sent to you per PM before I found somebody else to test it, and only after that and some bug sqashing did I post this thread with another version which you apparently didn't bother to download. I don't know you but please quit the attitude. Also CyanogenMod doesn't work properly on any stock kernel, you don't have full hardware encoding in the camera for example.

The benchmarks I wrote were in response to gokhanmoral's post and nothing to do with H/W acceleration.

DicePlayer uses their own libraries for hardware acceleration on a different layer than the OS, since it's a Korean production and they somehow had access to the MFC documentation. It was plainly for troubleshooting and isolating any other issues beyond the kernel, if DicePlayer works, then the kernel works, I changed nothing related to the MFC driver.

@CekMTL Very impressive voltages on the higher frequencies above 1000MHz, almost -75 to -100mV less than what we're capable to do on the S3. And about -200mV over stock. :good:
[Galaxy Note II Original Android Development] CekMTL:
Yeah, taking into account that I upped + 25mV on all those stable, so in reality they should be what you see + 25mV more :D

I still can't believe it, and in reality, I din't try to go lower on the lower frequencies... din't even bother :p

Thx again AndreiLux, anything you need tested, just bring it xDDDD

PS1: Was playing Borderlands2 LAN hehe, so I don't know if I explained myself right: what I mean is that 1.8Ghz I can run at 1.225 but I upped it to 1.250 an so forth with all the other freqs.

---------- Post added at 11:22 PM ---------- Previous post was at 11:10 PM ----------

Yeah! ... really impressed... wasn't expecting THAT much from my N2 :cowboy: :D :laugh:

PS2: In reality, the 1.0/1.1/1.2 all were running PERFECT with 0.950mV, but it felt so weird to run 1.2 at that low voltage, that I just thought, what the heck, just use that perfect "stair Vcc table", heheheh.... weird... xD
[Galaxy Note II Original Android Development] AndreiLux:
Well they seem they tuned 32nm HKMG quite a bit in the last months, and these chips seem to be very highly binned compared to the REV_1.1 chips on the S3. Here's a kernel with 1704 replaced with 1904 and 1800 replaced with 2000MHz. I'm curious if you can run these stable. Also: for real full stability testing run the performance governor please.
[Galaxy Note II Original Android Development] CekMTL:
Hahahaha shhhhhh-izzles... I was about tu tuck myself in bed, but then I saw your post... damn, you know how to convince me! xD

PS1: OK!, all set, let the fun begin, first with 1.904 ... Will be posting my results here as they are happening! :)

So... there's something weird going on: PERFORMANCE Gov. min/max:1904 @ 1.350 Vcc , no crash or problems, BUT, it pegs @ 800 MHz, so it means something is holding that speed when in full blast... the phone is MILDLY warm, so it shouldn't be heat throttling... maybe some other lock they put? ... that din't happen to me before (going down to 800 Mhz).

After like 45 seconds of Stability, it locks onto 800Mhz, again, NOT HOT, just mildly warm where the camera lens is (cpu), and the funny thing is that if I go back to Setcpu, and touch again the lowest speed and set it to 200 for example, it jumps again to 1904, instantly and stays there... so can't be throttling imo...

Exactly the SAME behaviour with 2.000Mhz @ 1.400 Vcc ... no chrash or anything, but same thing as 1.904...

Ok time for some real time dmesg action (cat /proc/kmsg)

<6>[ 1179.600624] c3 logger_release: took 0 msec

<6>[ 1180.136156] c0 logger_release: took 0 msec

<6>[ 1180.136188] c0 logger_release: took 0 msec

<6>[ 1180.256590] c0 EXYNOS4x12_tmu interrupt: INTSTAT = 0x00000001

<6>[ 1180.675515] c0 logger_release: took 0 msec

<6>[ 1180.675552] c0 logger_release: took 0 msec

<6>[ 1180.800235] c0 sec-thermistor sec-thermistor: notify_change_of_temperature: uevent: TEMPERATURE=450

<6>[ 1181.213657] c0 logger_release: took 0 msec

<6>[ 1181.213684] c0 logger_release: took 0 msec

<6>[ 1181.813980] c2 logger_release: took 0 msec

<6>[ 1181.814007] c2 logger_release: took 0 msec

<6>[ 1182.255810] c3 notify_change_of_tmu_state: uevent: 1, name = TMUSTATE=1

<6>[ 1182.260212] c3 throttling: set cpufreq upper limit.

<6>[ 1182.435411] c2 logger_release: took 0 msec

<6>[ 1182.435450] c2 logger_release: took 0 msec

<6>[ 1183.000112] c0 [SSP]: debug_work_func(61) - Sensor state: 0xef, TO: 0, BC: 0, RC: 0

<6>[ 1183.000165] c0 0 : -4, 3, 1058 (200ms)

<6>[ 1183.000192] c0 6 : 0, 0, 0, 0 (200ms)

<6>[ 1183.075432] c2 logger_release: took 0 msec

<6>[ 1183.075465] c2 logger_release: took 0 msec

<6>[ 1183.260117] c3 change state: 1st throttle->normal.

<6>[ 1183.669563] c1 logger_release: took 0 msec

<6>[ 1183.669596] c1 logger_release: took 0 msec

<4>[ 1183.774018] c3 !@Sync 38

<6>[ 1184.225035] c1 logger_release: took 0 msec

<6>[ 1184.225123] c1 logger_release: took 0 msec

<6>[ 1184.260110] c0 notify_change_of_tmu_state: uevent: 0, name = TMUSTATE=0

<6>[ 1184.265241] c0 normal: free cpufreq_limit & interrupt enable.

<6>[ 1184.856218] c0 logger_release: took 0 msec

So there it is... CPU THROTTLING... but.. I SWEAR it's not hot, just mildly warm to the touch!
[Galaxy Note II Original Android Development] AndreiLux:
That indeed is heat throttling, it takes milliseconds for the internal temp gauge to reach high temeratures. Heat throttle happens at 80°C. I will not disable nor change that. So if it can't handle that speed without heat throttle, then it might as well not handle it at all. I'll leave the kernel up for more feedback, but if more people report the same, I'll keep the current 1800 limit.
[Galaxy Note II Original Android Development] Reb0rn:
Mine is stable at 1900... 2ghz boots and all but crashes on heavy loads. Ramped up volts to compensate but that didnt do much.

So 1900 should be doable to most/all.

Edit. Mine did not get stuck at 800. Full 1900mhz.
[Galaxy Note II Original Android Development] CekMTL:
Yep, check my last posts with dmesg output... well if it can't be, it can't be ;) ... I'm pretty happy with 1.8 don't have a need for more, and don't care about benchmarking contests.
[Galaxy Note II Original Android Development] questionmark:
Same here unstable at high load crashed when buble upnp streamed 1080p 2001 space Odyssey to dice popular while attempting to use quadrant to check stabitybhigh load

Still at 2gz writing device is warm but kinda ok.

Basically only crash with quadrant mkv Palin no problem

Thanks much
[Galaxy Note II Original Android Development] CekMTL:
Madness again! ... so... weirdly enough, 1.904Mhz is TOTALLY STABLE @ 1.300 Vcc (till the Throttling at 800Mhz kicks in of course, but it could take 2-3 minutes!).

It continues with a +50mV per high step, as my 1.800 was 1.250mV ... nice chip in deed and ossom for battery! :)

2Ghz needs the full 1.400mV and not even then is stable, so for me, my cliff is 2Ghz, and 1.9 should be doable @ 1.300mV or a security cushion to run 1.8 without worries :)

Ok, this councludes my testing round for me! Thx all for your contributions, time for me to recover backup and get back to my perfectly stable experience :D (and to sleep!!!)
[Galaxy Note II Original Android Development] questionmark:
Yes I'm stable too at 1900 @ 1.325 will go to 1.300 and see how it goes tomorrow

Cheers
[Galaxy Note II Original Android Development] dachness:
Wow, very exciting. Thank you for the kernel and those for testing. Will have to give it a go when the Note 2 is released on AT&T.
[Galaxy Note II Original Android Development] questionmark:
In deep sleep over night it crashed using 1900mhz at 1.300 mv the other voltage were set to same values as shown in previous thread. Back to 1.325 for 1904mhz with same values for other freq.

Cheers
[Galaxy Note II Original Android Development] CekMTL:
Thx for the info, good to know for/if when the time comes :)

Enviado desde mi Nexus 7 usando Tapatalk 2
[Galaxy Note II Original Android Development] CekMTL:
Getting astonishingly low vcc numbers in low freqs... still painstakingly investigating... but it's hard to believe... 200Mhz is working flawlessly @ 0.700mV with stabilitytest... is it real?

Can the rail go as low as that?

Enviado desde mi Nexus 7 usando Tapatalk 2
[Galaxy Note II Original Android Development] questionmark:
Hey thanks for that. I use your posted values except for 1904mhz where as you know I use now 1.325. Like to test your low freq values and will report how it goes.
[Galaxy Note II Original Android Development] atsavlis:
AndreiLux just a quick question. Everything is running super smooth with your latest version. I am currently running Wanams rom, that incudes a init.d script that has some governor value tweaks in it. Is it a good idea to delete init.d scripts so that they dont "interfere" with your kernel, or is it ok to run them?

On a side note, cant wait for you to develop and release your kernel control app!!! Thanks for all your hard work!
[Galaxy Note II Original Android Development] Ferranza:
+1

Inviato dal mio GT-N7100 con Tapatalk 2
[Galaxy Note II Original Android Development] CekMTL:
Yeah np my pleasure!

For now just taking it one step at a time to secure the "first batch" (200_600) of uv, and giving it time and proper usage to see if something weird happens.

Running solid for many hours and not a single problem... I'm used to fighting, but my N2 is as sweet as pie... some crazy undervolts for now all the way up to 600Mhz.

600 is running perfect (for now knock on wood) with 800mV ...wow

Ps1: just noticed the 800mV... nope in reality it is running at 700mV solid... silly mistake I dint spot sooner!

Enviado desde mi Nexus 7 usando Tapatalk 2
[Galaxy Note II Original Android Development] AndreiLux:
The rail goes as low as 600mV. The lower frequencies don't seem that dramatic in change compared to the S3 though, I can run 682.5mV at 200MHz and 837.5mV at 600MHz. But of course if you're coming from a different phone with an older manufacturing process, this might surprise you.

@atsavlis: I don't know what wanam included in his ROM, but you can just delete it and test for yourself. Yes my default configurations are different than stock. The kernel control app might take some time so don't expect it soon.
[Galaxy Note II Original Android Development] questionmark:
Hi

This are my values with it I experienced a crash again while sleeping loading the device. And just one now after taking snapshot and opening xda so need to pump up some if these trying to find the sweet spot.

Cheers
[Galaxy Note II Original Android Development] AndreiLux:
I'll do a blanket release for all variations in an hour or two after more people report back everything working fine.
[Galaxy Note II Original Android Development] EdgaBimbam:
so far no problems, everything runs smoothly, btw maybe later you are going to implent to stweaks app (choosing scheduler, disable/enable android logging?) ;D
[Galaxy Note II Original Android Development] kevin_diu:
I can't wait for it. I tried another kernel but finally i back to perseus . ;D Thanks for your work hard.
[Galaxy Note II Original Android Development] AndreiLux:
Disabling logging does almost nothing. Anyway yes I will extend it in the future with some new unique features but it will remain like this for this major release (v27).
[Galaxy Note II Original Android Development] seavers11:
Flashed and running for 30 Minutes without any issue very smooth and stable. ..thx

Gesendet von meinem GT-N7100
[Galaxy Note II Original Android Development] gundal:
can you put up the sgh-i317m variant. I will test right now for you!
[Galaxy Note II Original Android Development] SandeepEmekar:
I'm on Alpha27.

Working cool!
[Galaxy Note II Original Android Development] nyarnon:
Looks fine running smoothly with configuration below. Thanks.

--

Sent from my N7100 with Perseus 27.3 Omega 7.3 Recovery Clockwork Touch 6.0.1.9 Thanks too the devs and teams.
[Galaxy Note II Original Android Development] CitizenLee:
First impressions are very good. It's fast and stable, with no noticeable issues.

Now to see what battery life is like over the next few days.

Thanks again for the hard work AndreiLux :good:
[Galaxy Note II Original Android Development] yahyoh:
ok started from scratch with XXDLJ2 odin which will wipe every thing even internal memory then flashed tar file and lock screen still stuck here :/ :crying:

i had no such problem with 26 whatsoever
[Galaxy Note II Original Android Development] AndreiLux:
I'll upload them in the i317 forum in a few minutes. Please read/reply to your PMs.

What do you mean by stuck? ...