Hi, Your logic is correct but the timing of 60 seconds was incorrect. It was the bench mark of something else I was checking. I had mistakenly thought it was how long it took to open LXDE without OCing, My bad.

So to be clear:

without OCing it took 35 seconds to open LXDE on my N900
with OCing it took 27 seconds on karman's N900
a 30% improvement. (35/27-1)*100

OCing did better when launching open office (from icon on maemo screen I assume):
without OCing it took 45 seconds (my N900)
with OCing 25 seconds (karman's N900)
(45/25-1)*100 =80% improvement
Not bad!


Of course one major flaw with this study is that one should use the same n900 for this comparison!

EDIT: The percentage improvements were incorrectly calculated. They are now correct. Used formulas in post #82.

Is this way of doing maths correct? :P I would say:
35/27 = more or less 1,3 times faster
or
27/35 = it works in 0.77 of time without overclocking
or
((35-27)/35)*100% = more or less 23% of speed improvement

45/25 = more or less 1.8 times faster
or
25/45 = it works in 0.56 of time without overclocking
or
((45-25)/45)*100% = more or less 44% of speed improvement

Indeed - these comparisons are only marginally better than an educated guess - there's loads of things which could influence the results - background processes, widgets, email checking, daemons running, other tweaks, etc, etc, etc, etc, etc.

You really can't take the timings from two different devices and make a conclusion that this tweak is better than another one. The only way of doing it would be to do it on the same device - ideally one that's been freshly flashed and has been fiddled with as least as possible!

Well, I think it depends on the convention you want to use and what is more meaningful . For case of 45/25 being 1.8 faster. It is equilalent to 80% improvement in speed. Also 25/45 =.56 works because you are then saying it takes about half as much time to run.


EDIT: 180% was corrected with 80%. There was an inconsistency between speed improvement and time improvement. Text corrected/modified. Sorry about that!

All these calculations are on specific operations and not on the overall operation of the N900. Even if you can run LXDE or whatever 130% faster, this does not prove that your N900 runs 130% faster in general, unless all you do all day is start LXDE.

I stand by my estimate that after doing all the changes mentioned, my N900 is 30% or so faster.

I don't get ANY of the bad results mentioned. I don't think I've spontaneously rebooted for a year or so, for example.

Cool. Settled. Now take a 0 out of the title, OP.

I also think that even the LXDE and OpenOffice timings show only 30(+/-10)% of speed improvement (see my previous post for calculations), they (mscion and karam) and us just use different measures... for me 100% speed improvement would be doing everything in (almost) 0 time... and doing something 2 times faster is 50%, not 100%... it's not even linear, god damn it... I think that proper formula is ((time_without_tweak-time_with_tweak)/time_without_tweak)*100%, not the strange one used by mscion. Let's imagine something took 10 seconds without overclocking.
1. Then after one tweak it takes 5 seconds.
Time gain = 5 seconds.
My way of counting = ((10-5)/10)*100% = 50% speed gain, so 1 second is 10 percentage points.
His way of counting = (10/5)*100%= 200% speed gain, so 1 second is 40 percentage points.
2. After removing this tweak and applying some different tweak it takes 3 seconds.
Time gain = 7 seconds.
My way of counting = 70% speed gain, so 1 second is 10 percentage points.
His way of counting = (10/3)*100% = 333% speed gain, so 1 second is 47 percentage points.
So it's not consistent...
and more important:
3. After removing the second tweak and applying some different, let's imagine device is less responsive and operation now takes 20 seconds.
Time gain = -10 seconds (10 seconds loss)
My way of counting = ((10-20)/10)*100% = -100% speed gain (100% speed loss), so 1 second is 10 percentage points.
His way of counting = (10/20)*100% = 50% speed gain, so 1 second is (50pp)/(-10)= -5 percentage points.

Summarizing:
- This strange way of counting speed gain used by mscion is inconsistent. Between situations 1 and 2 using your way of counting the speed gain jumps from 200 to 333 points suddenly, while using my way it's consistent (every second faster gives equal number of percentage points in speed gain %).
- This strange way of counting gives positive speed gain even if the speed gain is NEGATIVE, so it's definitely wrong.
- I think that speed gain is "seconds saved while doing some task", so it's (time_without_tweak - time_with_tweak). And to make it into percentage, one should take it, divide it by base time (time_without_tweak), so the formula is (time_without_tweak - time_with_tweak) / time_without_tweak. And multiplied by 100% ofc.

Thank you for reading Maybe that's why in the thread title there is number "300%", it's actually around 60-70% speed gain (well, 2 times more than measured by these tests, but who knows, maybe on their devices something worked two times faster it's more probable than 10 times faster ) Anyone with me? :P

And don't forget that timing how long it takes to load an app is a really bad benchmark as 2nd time will always be faster due to caching, etc.

ETA
Really? My phone is consistently consistent, so to speak. I always assumed that due to limited memory that was disabled. Did you try this out?

End ETA

That's a bit conservative, IMO. It is about 30% faster doing stuff but the times spent waiting on UI and the like was reduced visibly. My "feel" was closer to a 50%, on the round up side. We do, however have (most likely) different usage patterns. E.g., I spend at least 20 minutes a day on VNC.

Even so, seeing the wild numbers here, we're on the same page.

Oh, and, to some of the math here: 110 is 10% faster than 100, not 110%. So, what I was saying, is that 60 seconds over 30 is 100% improvement, 60 over 60 is 0%.

"(35/27)*100" is a ratio, 1.29. The improvement is 29%, not 129%. Because "this is 100% faster" means twice as fast, not exactly the same.

Work is being done in 35 seconds, so it's W/35. the other is W/27. We do a ratio, so division is the key. Division of fractions is multiplying with the inverse, so it's (35/W)*(W/27), and work is reduced (since it's a ratio, no measurements, makes sense), it falls to 35/27, or 29.6% improvement.

If you want, it takes 1000 ticks in 35 seconds to do work, so it's 28.5 TPS (ticks per second), versus 1000/27, which is 37.0 TPS. Now it becomes clear that 37 is a 29% improvement over 28.5.

Can't call it Hertz or MIPS because it's not aligned with a second, but it's the general idea.

In my case, the rough 50% corresponds to upping the 600 MHz to 900 MHz, a rough increase of ... what do you know, 50%

ETA?

Yes - It's more apparent for smaller apps that take less memory. And don't forget swap space will also come into the equation.