Folding Forum

John ok, I assumed there was an significant enough diffrence ( especially since x64 has more hardware registers which are used to hold pointers to data ) since there where both x86 and x64 binaries for linux.

toTow you got the source and memtest itself is also open source, get someone to combine em

toTOW wrote:...
The only thing I really miss in this program is the memory test. Without a proper memory test, we can't fully validate a system for SMP clients with this program.

You might have to start a thread in here for the IBT (Intel Burn Test) which tests both, though I have never used it.

7im wrote:

toTOW wrote:...
The only thing I really miss in this program is the memory test. Without a proper memory test, we can't fully validate a system for SMP clients with this program.

You might have to start a thread in here for the IBT (Intel Burn Test) which tests both, though I have never used it.

Yeah but afaik IBT was designed for testing temperature stability ( at first ). Now with linpack it's diffrent but I haven't used it in a long time either so idk. The main point of iBt was that it got hotter then any other tests at the time, it was also specificly aimed for dothan or desktop equivalent, and didn't do as good with regards to temps on amd. Linpack is also already superseeded with lapack which is much more cache straining then the former.

Isn't this a repeat discussion btw, I can vaguelly recall this being a subject before.

It was mentioned in the thread requesting a GPU stressor. Here, I merely suggested adding IBT to the list 3rd party tools.

Fair enough, wasn't saying it has no good qualities.

To test the stability of a (Windows) system, I usually use 3 programs :

StressCPUv2 : to test basic stability. This mostly test CPU and low amount of cache. It doesn't test enough cache on modern CPU (more than 1MB of cache)
CPU Stress MT : it also does basic tests, but it uses a bit more memory, and usually fills the cache better.
OCCT "Perestroika" : both OCCT and Linpack test, set to use as much memory as possible (Large OCCT test and 90% of memory Linpack test). This helps to test the memory subsystem.

On non Windows machines (or to get more accurate tests), I also use Memtest.

MtM wrote:toTow,
. . .
Isn't using x86 code not going to stress the cpu properly on x64 windows? Just a heads up, think you should change your opening post?

MtM wrote:John ok, I assumed there was an significant enough diffrence ( especially since x64 has more hardware registers which are used to hold pointers to data ) since there where both x86 and x64 binaries for linux.

One reason that there are so many choices is that code can put localized stresses on segments of your hardware. When you focus on one part of the hardware a benchmark may prove that you can't overtax that part but that doesn't prove that there isn't some other segment of the hardware that might be unstable when it experiences the maximum stress. A general purpose benchmark like IBT may stress everthing to, say 90%, or a specific test may reach 100% for one segment.

The whole point of StressCPU2 is to mimic the stresses imposed by Gromacs, which stresses mosty the SSE hardware (and the FPU) and does not stress the extra 64-bit registers. A good test of 64-bit integer arithmetic might find different results.

I'm afraid you'll always be stuck with running multiple tests if you really want accurate stability testing.

The download link for this program in the OP is broken and as a result so is the link in the Tools List - does anyone know where this can be downloaded from now?

Ugh, I really don't like what they've done to the GROMACS website.

Anyway the link is here: http://www.gromacs.org/@api/deki/files/ ... sscpu2.tgz

Thanks

It looks like the old site is still available here : http://oldwww.gromacs.org/component/opt ... Itemid,26/ ... I've updated the link in first post and I'll edit again if they move that page to the new site. Unfortunately, I think download is broken from this page

uncle_fungus> I tried to download from your link, I get something, but I can't open the file which looks empty.

Thanks for checking that toTOW.

Yes, the new link is corrupted, not sure how yet. The old link can be repaired as it just has the php error textx prepended to the archive with
However for people's convenience until it's fixed, I've uploaded a working copy here:

http://fire-salamander.co.uk/fah/stresscpu2.tgz

Why don't the actual clients work this fast? Timing it for about 15s, I worked out it's doing about 54GFLOPS on eight cores. Whereas I'm pretty sure the uniprocessor client is hard pressed to get over 1GFLOPS.

I'd guess the data set required to load the processors is probably much smaller than the actual simulations that Stanford is researching. The data set is probably hand picked to run fast and create max load. Actual data is more random, and probably a much larger data set.

I've hosted the file on FAH-Addict too.