[Droid Eris Q&A, Help & Troubleshooting] bftb0:
Well, there are two things going on.

The first is that your phone hardware is like any other macroscopic object in the universe - they have variable characteristics. Go to the store and look carefully at the apples they have for sale - pick a given variety, and you'll notice that every one of them is just slightly different from the next.

If you were to zoom in and have a look with a good microscope at the transistors in your processor chip - you would first notice that: (a) there are millions of them!, and (b) they all look very similar, but are not exactly identical. That's just the nature of things - the manufacturing processes have some amount of (hopefully well controlled) variations.

But, when it comes to computer chips executing software instructions, we definitely want them to all behave identically. So, what to do? The answer is, run them all at a sufficiently low enough speed (and a large enough voltage) that the small natural variations from transistor to transistor never make a difference in how the outputs from those transistors are interpreted.

You've heard the expression "timing is everything", yes? Nowhere does this expression apply better than in computer chip design. I'll use a stupid analogy to illustrate how this works.

Suppose you had a marching band ... not like the ordinary kind, but instead, a band full of morons. So stupid, in fact, that you teach them to play songs like this:

"You nearest two neighbors will hand you a note just before each beat of the kettle drum, and you will decide based on those notes what note to play yourself after you hear the next kettle drum beat - and then you will hand that note to your neighbor".

In this analogy, each (transistor) logic gate in the chip is a moron band member, and the kettle drum is like the system clock.

Well, each moron (transistor logic gate) in the band will need to take some time to decide what note to play next. And it is plainly obvious, that if the moron's neighbors (other morons/gates) don't hand their notes off by the time the kettle drum beats, the wrong decision will be made. Chip designers call this "setup time".

Also, since we presume that the band members are morons, they actually need to some amount of time to stare at the notes from their neighbors to make up their mind - sometimes so slowly that the beat of the kettle drum has already been heard some time ago before they make up their mind. If the neighbor moron band members were to "yank their notes away too quickly", the receiving moron band member (logic gate) might again make the wrong decision. Chip designers call second sort of timing measurement "hold time".

So, this is a very simplistic view of chip design: the designer needs to make sure that the inputs (notes) to every gate (moron band members) arrives well enough ahead of the clock (kettle drum beat), and stay stable for a short period of time after the clock (kettle drum) beat. And they also have to consider how slowly each gate (moron) can "make up his mind" - because of course, that introduces delay in passing off information to other gates (morons) at the next beat of the clock (drum).

If you followed this analogy closely, the question might have also occurred to you, "what happens if the morons in the band don't all hear the kettle drum beat at precisely the same time?" In the analogy to chip design, this is the problem of clock distribution - because at each moron (gate), the decisions are made when they individually hear the kettle drum (clock) beat. So, there could be some major trouble if a moron (gate) was supposed to receive notes (signals) from other morons (gates) that were hearing the kettle drum (clock) either much to early, or much too late, compared to their neighbors.

Now, marching bands are only a little bit like this, especially since we said in our example that only nearby neighbor morons (gates) were involved; but in chip design, both clocks and signals may need to be passed great distances away, not just to nearest neighbors.

A major part of chip design revolves around exactly these concepts: trying to compute exactly what the "setup", "hold", and "delay" time min/max values are for millions and millions of gate and signal paths in the chip, and also knowing exactly how long it will take for the signals and clocks to travel from their source to destination(s).

If only a single one of the millions of morons (gates) gets this wrong, the whole song is ruined.

So, it should be clear that if you run the system clock really, really slowly, you generally won't bump in to any setup or delay hazards (hold is a little trickier, but we can ignore that). The clock beats so slowly that signals have plenty of time to reach their destinations, and also the amount of delay through each gate is negligible compared to the long amounts of time that using a slow clock grants you.

But as you increase the clock faster and faster, you start shaving away available time for signals to get to their destinations, and come closer and closer to one of these hazards - a "setup" or "hold" violation. Not only that, but the delays across the chip - which are negligible for a slow clock - start to become really important.

Now, I spent a lot of words up there to illustrate something: the timing problem only very weakly depends what software is running on the phone, it is a function of the hardware alone. You can't "install some software" to make this problem go away. Your microprocessor will run flawlessly up until a certain clock speed, and then disaster!.

And that disaster could be the fault of a single transistor out of tens of millions - generally, a transistor which for some reason, is "weaker" than most of it's neighbors - or it has to push a signal through a line which is oddly more resistive than it should be - and therefore slower.

The second thing to be aware of is that these benchmarks are being run on a multitasking operating system - if you run them 5 times in a row, you will see that you get a different benchmark value each time you run them - because other activities on the phone and the kernel's scheduler conspired to give your benchmark app slightly less or slightly more total attention during the elapsed (wall) clock time of the benchmark.

So, since that website records the "best of the best" - make sure you run your benchmark twenty to fifty times, see if you can diddle the oom_adj value of your process while it is running, and delete all other applications from your phone so that it is the only thing running.

To illustrate that there's no "magic" going on here, I'll give you a concrete example. Two days ago I ran that Linpack app on my Eris. Here's what I did:

OS: GSB v1.2

min cpu = 748 Mhz

max cpu = 748 Mhz

governor = performance

JIT on

killed off most idle apps

And I got linpack scores that varied from 4.8 to 5.1 over two or three runs.

Now, let's compare (the best of) those results to the ones reported in the Benchmark results, but scaled to a different frequency:

(844 Mhz / 748 Mhz) * 5.1 = 5.75

Note that this is plenty close the the value reported at 844 Mhz.

If you want to convince yourself that your phone is fine, set the cpu speed min=max = whatever. Then run the benchmark a couple of times, and compare your result

(844 Mhz / whatever ) * your_best_result

And you will see that your phone is no "different" than the best Eris out there - except that it can't run at 844 Mhz. That latter part is just the luck of the draw.

bftb0