benchmarking F@H

[alpha754293]

I'm wondering what people think about the benchmark results and methodology.

[uncle_fungus]

Ahhh...that's a better explanation. What's interesting though is that NOW is the first time that a purely 64-bit release is made available.

That wasn't intentional. A 32bit release will be made available eventually to allow uniprocessor users to have the latest client.

MPICH should work on 32-bit though. *shrug*

MPI+Vanilla GROMACS works fine on 32bit Linux. I know because I've tried it, however the FahCores are not vanilla GROMACS.

If you want to do any linux benchmarks with GROMACS with and without MPI, I suggest looking at the phoronix-test-suite (http://www.phoronix-test-suite.com) whose GROMACS profile was written by myself (currently uses version 3.3.3 rather than the latest 4.0.3).

[alpha754293]

Ahhh...that's a better explanation. What's interesting though is that NOW is the first time that a purely 64-bit release is made available.

That wasn't intentional. A 32bit release will be made available eventually to allow uniprocessor users to have the latest client.

MPICH should work on 32-bit though. *shrug*

MPI+Vanilla GROMACS works fine on 32bit Linux. I know because I've tried it, however the FahCores are not vanilla GROMACS.

If you want to do any linux benchmarks with GROMACS with and without MPI, I suggest looking at the phoronix-test-suite (http://www.phoronix-test-suite.com) whose GROMACS profile was written by myself (currently uses version 3.3.3 rather than the latest 4.0.3).

I actually got in touch with Erik Lindhal (I think was his name) from GROMACS in terms of benchmarking it.

They have a number of "test" data that they have posted, and I was going to do it, but I just wasn't sure how to invoke the run since there was grompp and also mdrun.

I would have presumed that they would have it so that you can just go ahead and invoke mdrun straight away, but I haven't really looked too closely at it though.

On another note:

From what I have noticed, if you boot your linux system into text only console mode; you end up with better PPD than if you didn't.

I'm currently running SLES10 again, but this time in console mode (init 3) and averaging about 6200 PPD. Shouldn't be anything earth shattering surprise, but for those that don't know...the test results show it.

(I had to switch back to SLES in preparation for some of the CFD work that I am going to be doing fairly shortly).

[alpha754293]

more benchmark results:

finally picked up two a2 WUs.

ran two clients, both "-smp 8"

(2x8*a2): 6043.3 PPD total (3016.15 + 3027.15)

5% performance loss running it this way.

It's official (at least from what I can see and the benchmarking that I've done):

two "-smp 4" client is the best (PPD and WU production wise, but not the best for WU speed).

[codysluder]

From what I have noticed, if you boot your linux system into text only console mode; you end up with better PPD than if you didn't.

That depends a lot on which GUI interface you're running. Unlike many distros, DSL uses some bare-bones GUI that adds very little overhead (I forget what it's called).

[alpha754293]

From what I have noticed, if you boot your linux system into text only console mode; you end up with better PPD than if you didn't.

That depends a lot on which GUI interface you're running. Unlike many distros, DSL uses some bare-bones GUI that adds very little overhead (I forget what it's called).

That appeared to be the case with the default installations. I didn't really bother spending a great deal of time trying to customize it given that the benchmarking itself takes a while.

I would definitely agree with anybody that says that there are gains to be had by optimizing the system and really trimming down the fat and only running what is absolutely necessary if it is to be a dedicated F@H linux system.

I'd probably even go as far to say that it would not surprise me if people already have a distribution of Linux specifically for F@H such that it runs super lean.

(And if it doesn't exist already, I wouldn't be surprised if someone is already working on one, or if there is going to be one eventually).

Up until I started the benchmarking, I was running on strictly the Windows client, but I wanted to boost my PPD, so I figure that while I'm at it, I might as well give the Linux SMP client a second try.

- * - * - * -

Here's something that's new and interesting:

I got myself one of those Kill-A-Watt things and this is what I've found on my quad AMD Opteron 880.

with two "-smp 4" clients:

when both WUs are using the a2 core, the total power consumption is ~510 W.

when one is running a1 and the other one is running a2, that drops down to ~490 W.

(The system has a 850 W PSU in it).

THAT is also something interesting.

That puts me at around 78.43 MFLOPS/W (which actually isn't all that bad, I thought that it was a lot worse), and a peak of about 12.46 PPD/W. (not so great).

I haven't tested any of my other systems yet.