Notices

Wise statement. Realistically, you don't have to overclock much at all to get 720p. I seem to recall several testers of it were running 800Mhz. I personally run 500-900Mhz, but locking is a rather silly concept. Btw: even locking in general still leaves two levels, one of which is 0, or the resting state. But locking at a high rate means one rogue widget could suck your battery and turn your phone into a pocket warmer.

As for overclocking, the simplest way to do so is use the kernel-config command. Look at the documentation page for it for options, set it up the way you want to... test it out, and if it all seems happy, save it as a profile and set that profile to be the default one. You can do all that via command line just using kernel-config. Or, you can load one that's already done for you, like the dsp config.

The only "speed up app" I trust is swapolube, for the simple reason that it has a button marked "default" that restores the kernel's default settings. It also shows you what it's doing, and gives you all the proper internal names so you can look-up what the value tweaks and why you may or may not want to touch it. Any app that lets you reset what it's done in a clear and transparent method is generally good IMHO.

Keep in mind though, any time you install anything, you're taking a risk that it can cause instability. The less you know about it, the more likely it can screw things up. If you don't know what it does, or how it does it, best to stay away from it all together, because you probably don't need it anyway.

this is your opinion guys
but just a small correction

speedpatch doesn't do permanent changes as woody stated
i have no idea why are you saying this
but my best guess is :

when a user have a problem and he has speedpatch or batterypatch installed
you tell him to remove it
then when he does
the problem is not gone
--->it made you think that speedpatch does unreversed changes
but the problem was not caused by speedpatch in the first place

and for batterypatch conflict with HD rec
it has no conflict as i use it and record/watch HD almost every day
becuase it has the same dsp values as dsp profile
correct me if am wrong

and oh
i moved speedpatch/batterypatch to the repo according to users requests and their feedbacks
such as

or this
and would you think i would have left speedpatch/battterypatch in repos if they kill you device ?
the answer is no

so my question is
what is the bloody hell way to proove to you that speedpatch speeds up and batterypatch saves up ?

and please if you want to continue disscution
then do it in the dedicated thread

... And this way, another thread is in danger of becoming never-ending, useless /speedpatch discussion.

*unleash voodoo powers to cleanse this topic from evil presence*

So why don't you make an serious warning in the description?

OK, i have now toped it at 850 would this be enough? I think that if it's dynamic i could let it get up to 900.
Why low limit at 500? Any issue with using 250 or 125?

I ussually try to avoid anything that has any serious warning or does not makes me feel sure enough.
As i know my limitations i usually dont go too far on unknow terrain. (when i want to go far i start asking a lot of questions )


Never mind this... i found i have preview now... It's ALIVE, It's ALIVE!!!

IIRC freemangordon suggested locking of the CPU while recording in HD for a better performance... if I'm not mistaken. And I personally think it is reasonable as it leaves more cycles for crunching rather than scaling. Yet again, I could be wrong

AFAIK, You're wrong. Such suggestion was made looong time ago, and, IIRC, for testing purposes.

Using actual KP and 720p video recording "stuff", it's not needed to lock frequency.

/Estel

850 should be fine. I (and many others) use 500 as the low point for a few reasons. One is the "race to idle" theory, where in if you have short jobs that happen on occasion (a CPU wakeup to check on a file or what not) if that happens at 500Mhz vs slower, it completes faster and thus goes back to sleep sooner, saving power. There's also a tested and proven fact that the power vs cpu use efficiency is maxed out very close to 500Mhz. It's what the chip was designed to work at, and where most of the power-saving comes into play.

Also, FYI: 125 is in many cases unstable. Enough so that Nokia dropped it from their scaled listing, starting at 250 instead.

Same thing I do. Nothing wrong with asking questions when you're not sure what's going on. The three most useful and honest words in English are "I don't know". You should never be afraid to admit that, or to question what you know.

Thanks to everyone who answered, this is working like a charm on every way.

At the beginning.i left 250 as lower and 850 as max, then i raised it to 900, but it went bananas and rebooted. As my settings weren't saved as default it then remained 500 and 850, a couple of days now and nothing strange nor killing battery so i'm very happy with this.

Thanks a lot to everyone, specially the masterminds behind this awesome project.

Now i'll be roaming around to seek how many other ways could i squeeze my phone.

The current version does, in fact, do permanent changes. On install it replaces your .profile and .bashrc files, but fails to restore them when uninstalling. (See prerm and postinst for the deb if you don't believe me.) It also sets your kernel config to "default" which on most systems is (250-600), without mentioning it anywhere.

So, since I bothered to grab the latest versions to see what it actually does, lets take a look-see shall we?

All "speedpatch 2.0" seems to do is add a separate cgroup for CLI commands and adds shell-scripts to that cgroup as they run. Nowhere do I see it adding groups for desktop and applications, as stated in it's description. Which means it's not really doing anything but lumping shell scripts and xterms together into a shared cgroup. How does that help speed? Since most apps are not shell scripts, I don't see how that helps anything. Further, it depends on KP without specifying it as a pre-req. Everything I'm seeing would indicate that speedpatch has a better chance of slowing things down by setting the kernel back to default than it does speed things up.

As for Batterypatch 4.0: The current version also sets your config to default kernel config, on install and on uninstall. All it seems to do is set the nice levels on a few apps and loads a kernel config if your close the keyboard and it goes into sleep mode. Namely, it renices modest, browserd, image-viewer to a value of 1 and ignores nice loads. It loads a separate config for when you open it, and when a call is going on. I note that it tries to renice "background apps" via a call into /dev/cgroups, but unless you have speedpatch installed (not a pre-req!) it will find nothing there, as cgroups aren't mounted by default.

The "speed" from battery patch comes from the fact that you're heavily overclocking the system (705-850!) when the system is awake. For calls, you're using a (250-805) config that's closer to stock, but still overclocking. (Are you telling people that your scripts overclock their devices?) And for the sleeping system a (125-600) config that ignores nice loads.

This means when an app in the nice list (modest, browserd, etc) wake the system up to do something, when it's closed, it will run at 125Mhz until done. Weather this is even saving battery or not is questionable, since it's against the "race to finish" idea in multiple ways. Also, it's enabling 125Mhz, which just about everyone including Nokia, Titan, and Lehto believe is unstable.

So what does the combo of these two do? From what I'm seeing, next to nothing, except that it screws with your configuration, enables a kernel speed that Nokia and others avoid because it's unstable, and adds a user cgroup to lump scripts and shells together for sharing resources. Not something I'd care to inflict on anyone.

You've been asked, on several occasions (even on your dedicated thread) to explain what these patches are doing, and why it's helpful. You've declined to give much information at all, and what information you have given (the package description, for example) is patently false. So maybe that's where you should start in your "proof" of what either package does.

The fact that the entire install is nothing but scripts that tinker with kernel settings in a way you're incorrectly describing doesn't lend any confidence that anything you're saying about this is correct.