I compiled it for maemo.

@sLumPia - modest. It has been working all the time, no problem here.

@SirSocke AFAIK batterysuckpatch does more than just switching OC profiles on idle/resume, it play with vfs_cache_pressure and who knows what else kernel parameters. Which is not bad when done with understanding on what is actually going on behind the scenes, but I still fail to see such in Karams explanations what his "magic" patches do (if there are such explanations at all). Those patches are just shots in a dark and that is why everyone here having some knowledge/understanding recommends to NOT use them. It is up to you of course whether you will use them.


@The Winter - instead of calling me liar, you can just check your wifi power savings(Settings->Internet Connections->Connections->[your connection]->Edit->Next->Next->Advanced). On the last tab (Other) there is Power Saving, Turn it to On (maximum). Of course if you connection to laptop is ad-hoc, that won't work, ad-hoc connections does not support power management. In that case go buy a 15$ tp-link router, set-up your wifi in a correct way and come here to give me your apologies.

would you share it?

Sorry not providing .deb, could not find it. Put it under /opt/helium and don't forget to change permissions to 755 or so. And you will need some additional packages (like libqtm-sensors, what else?) installed.


EDIT: Have in mind that i have CSSU installed (Qt 4.7.4) have no idea if it works under Qt 4.7.0

apologies to freemangordon ,i didnt mean to call ya a liar but really thanks to you for clearing me about adhoc and regular tp wifi connections ;; sorry buddy ..

x2................

Conclusion - consensus about overclocking is that there is no consensus And that is good to hear in this case, as there are many use cases/preferences, and there is no point in creating "one universal rule".

Personally, I use 500-900 limits, due to race-to-idle (as per battery savings) and performance. Even if one isn't playing games, there are many situations, where having more resources available is helpful. From Easy Debian - especially, that thanks to Sulu's research (with my very, very little addition), ED is now running pure Squeeze - to pentesting. Not that IMm not one for emulating some great games through Dosbox, where MPU timing is most important.

There are some - amongst knowledgeable ones - that think overclock is wrong at all, but we wouldn't know why, cause they tend to get irrationally irritated on OC discussions, and tend to withdrawn when talking goes beyond basic electromigration stereotypes, to more wide-horizont approach (i.e, when real fun about new possible rationale start). And that's ok, cause no one is forced to OC (although, knowledge of less tech-advanced ones would definitely benefit from meritocratic discussion, so it's somehow pity).

There are some, that run device up to 1150 occasionally/ all the time using on-demand governor. I think it's quite unsane - considering, that our SoC is cooled 100% passively (don't confuse it with heat-pipe usage), and while it does awesome job on 'sane' frequencies (normally, up to 900 is considered 'sane'), we got no idea, how hot SoC get after ten minutes of constant 1150 mhz. We can only guess, cause our SoC doesn't have temp sensor. There are some bullsh|t packages like "save CPU" that claim to term throttle it, but they're based on battery pin temp sensor (sic!), so it doesn't have anything to do with real SoC temperature, not to mention MPU itself (basically, such packages are another cycle-waster, as they watch battery temperature all the time [= daemon], and change max frequency accordingly. Can't call it different than useless memory/cycle waster...). Bu, of course, if someone want to risk their devices to such degree, it's up to them.

And, there are people that use all kind of 'magic' packages - from mentioned save CPU, through battery/speed patches, to whatsnot. Well, if using placebo makes them feel better, why bother? At least, unless they irritate honest people with UFO bug reports about other packages (usually, KP), where error origin is untraceable due to overall mess their system presents.

Add to that common myths - like, that 805 is more "stable" than 850 and 900 mhz (this origin from vanilla [broken] SR efuse values, that were calculated for 600 mhz, and many times worked on up to 805 mhz), and You don't have much room for consensus. I'm pretty sure, than year or two from now, You will still find many folks propagating long-died myths about OC.

Yet, I agree, that it would be great to update wiki's 'Overclocking the N900' page, as it's highly outdated, full of assumptions, that were proved wrong for ages. I'll try to fix it, but as I have pretty full schedule -both personal, and one related to maemo.org - don't hold Your breath, and be my guest if You (=anyone) can start this process right now.

/Estel

Yeah, it was a bit jarring to notice that once I got to know my n900 pretty well the standard thing-to-do became to pretty much read up on everything on the forums (for the latest info) and graciously proceed to ignore all of those wiki pages unless specifically pointed towards them by the general chatter on the forums. A shame, really, that a lot of those pages on kernel-power, overclocking, NITdroid - you name it - are a bit deprecated now.

@freemangordon
I think you have some little problem with karam, eh?
The battery-patch switches between some profiles and modify the vfs_cache_pressure - nothing else. I've created something like battery-patch myself and then found out that karam has created nearly the same in a .deb. So I've downloaded and analysed his work and can't find anything strange within. For his speed-patch I think you're right: Nearly nobody knows what it really do.
Greetings

AFAICT, he doesn't have *any* problem with karam, they both converse peacefully in some threads, where batteryspeedmagic patches are not involved Yet, if You're pushing this further - switching profiles by *any* "patch" require constant event monitoring. That eats up CPU (=some power) and some RAM (=little bit of performance). Yet, when they finally got something to do - like switching profiles to underclocked ones - it does *not* save any energy. In fact, it waste it again, as it cripple user device of race-to-idle capability. It's just based on *wrong* assumptions, from the beginning, to the very end. And, increasing vfs_cache_pressure - lol, it doesn't have anything to do with power usage. It just decrease performance of programs that require filesystem cached data (as it's kicked out to swap), at the same time increasing chance, that other RAM angry programs will get fresh free RAM faster. Generally, tweaking vfs_cache_pressure alongside other swap_related settings can make sense (but not, when done standalone, without other tweaks), but it doesn't have a sh|t to do with power saving. What does it do in so called ''battery patch''?!

As for speedpatches, it screws up cgroups. Some older version did funny thing - kicked every process to one cgroup, and rised priority only for ones started directly via xterm (for less knowledgeable ones - it destroyed *any* priority settings, flattening everything). It seems, that it was corrected in later versions, but still it mess with cgroups and other kernel/system tuneables. In totally undocumented way, without any measureable proof that it increases performance - just many (most of the times, beginners) claiming that they "feel" it does, and at least same ammount of people claiming that it decreased they performance, or messed something to they point where it's unable to trace down origins.

---

Can we give this ages old myth a deserved rest, and finally end this part of discussion (unless someone have meritocratic, measurable arguments, of course)? Hearing about "magic" patches is becoming almost as irritating, as "ecosystem".

/Estel

while we talk abt overclock & powersave
what about POWERSAVE_BIAS is it affect performance??