Downloaded and running 5.0.7 on a single thread under Win7 Pro 64bit i7-2700k stock speed.
Example:

The new version of LLR (3.8.8dev) will use AVX for Intel Sandy Bridge cores. I don't think the code actually says anywhere what it is using for the FFT, but of course the previous version did not say anything about if it was using SSE2, for example.

You can easily check if AVX is working by switching back to the older LLR (3.8.6dev) from the previous PRPnet package and you should see it run slower.

Cheers

- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

...I don't think the code actually says anywhere what it is using for the FFT...

http://uwin.mine.nu/PRPNet/prpclient-5.0.7-windows.7z
contains only llr.exe 'Program - Version 3.8.6' - code line 018F6500 - 018F6520
created June.17.2011
not the new version 3.8.8dev
version info is also to find in 'rename_llr.txt', nothing about avx

http://uwin.mine.nu/PRPNet/prpclient-5.0.7-windows-gpu.7z
contains the new llr.exe 'Program - Version 3.8.8'

download both files and copy llr.exe !?

I've started PRPClient. OS was restarted due to Windows updates. On another start at 15:37, I'm getting error from all 4 instaces.

genefer.ckpt is there, so are work_GFN32768.in and work_GFN32768.save.
genefer.log says

Ahh, I think I've seen this one before.

[2012-03-26 15:49:50 SE(Ŕ] PRPNet Client application v5.0.7 started
[2012-03-26 15:49:50 SE(Ŕ] User name Honza at email address is xxx
genefx64 2.3.0-0 (Windows x86_64 SSE2)
Copyright 2001-2003, Yves Gallot
Copyright 2009, Mark Rodenkirch, David Underbakke
Copyright 2010-2012, Shoichiro Yamada, Ken Brazier
Copyright 2011-2012, Iain Bethune, Michael Goetz, Ronald Schneider

Command line: genefx64.exe work_GFN32768.in

Priority change succeeded.
Start test of file 'work_GFN32768.in' - 15:49:50
Testing 5230052^32768+1...
Checkpoint saved by another build of genefer (22 19). This version cannot restart with it.
[2012-03-26 15:49:51 SE(Ŕ] GFN32768: No data in file [genefer.log]. Is genefer broken?

If you upgraded to the newest PRPNet while there were any GFN tasks in progress, you would see that problem. The new Genefers in the latest PRPNet distribution are not compatible with the previous checkpoint files.

If the problem persists, simply go to the directory where you're running PRPNet and delete the genefer.ckpt file. It should work fine after that.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

If you upgraded to the newest PRPNet while there were any GFN tasks in progress, you would see that problem. The new Genefers in the latest PRPNet distribution are not compatible with the previous checkpoint files.

If you upgraded to the newest PRPNet while there were any GFN tasks in progress, you would see that problem. The new Genefers in the latest PRPNet distribution are not compatible with the previous checkpoint files.

Nope, it was fresh install of OS (and latest PRPNet client).

There was no mix of genefer versions (ie. older vs newer), only 2.3.0
The one that shows time remaining :-)

The program originally was started with genefer80 (or X64 and x86 both failed with maxErr before writing a checkpoint). It was then restarted with genefX64, which aborted because an incompatible checkpoint file existed -- the correct checkpoint file from genefer80.

Each version of genefer puts a string into its checkpoint file that identifies which flavor of genefer (cuda, x64, generic, 80) write the file and what version of the checkpoint was written.

The PRPNet client will choose the flavor of genefer to run starting with cuda, then x64, etc. What is supposed to happen is that each flavor of genefer is to check to see if it's flavor wrote the checkpoint and if not, put a specific message into the log so that the PRPNet client try a different flavor of genefer. If the version of the checkpoint is incorrect (genefer was updated to a version with a different format for the checkpoint), but it was the correct flavor of genefer, then it should restart the test.

In this case, it appears the genefer80 has a bug in that it isn't restarting the test. It detected that an older version was used to start the test, but that the current version cannot use the checkpoint to continue from where it left off.

It is also possible that if the version of genefer80 did not change, then genefer80 has a separate bug that prevents it from matching up on the checkpoint version name.

Genefer 2.3.1-0 builds can now be downloaded from SVN : https://www.assembla.com/code/genefer/subversion/nodes/tags/2.3.1-0

Click on the file you want, then the download button at the right of the page.

Honza, if you could test these executables out and let me know how you get on that would be great. I'll put together new PRPnet packages soon to include these builds.
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

And to clarify, you should be able to have all the Genefers enabled, again, and it should work properly.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Only CUDA is commented-out, 3 CPU version are available in prpclient.ini

Upgrading from 2.3.0 to 2.3.1 shows:

Just to be clear, you should be able to interrupt Genefer in the middle (so it stops with a checkpoint), and then restart, and it should go through all three versions of Genefer and continue running with Genefer80 again. Does that work?


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Just to be clear, you should be able to interrupt Genefer in the middle (so it stops with a checkpoint), and then restart, and it should go through all three versions of Genefer and continue running with Genefer80 again. Does that work?

Honza, do me a favor?

Please run all three genefers (genefer, genefer80, genefX64) from the command line, in the same directory as where you're running it when you get that PRPNet error, and use the -V switch with all three programs. Then post the full output from all three here.

Thanks.


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

No luck with -V switch, it complains that

>genefx64.exe work_GFN32768.in
genefx64 2.3.0-0 (Windows x86_64 SSE2)
...
Command line: genefx64.exe work_GFN32768.in

Priority change succeeded.
Continue test of file 'work_GFN32768.in' at line 1 - 09:14:23
Testing 5299830^32768+1...
Checkpoint saved by another build of genefer (22 19). This version cannot restart with it.

>genefer.exe work_GFN32768.in
genefer 2.3.0-0 (WINDOWS x86 32-bit)
...
Command line: genefer.exe work_GFN32768.in

Priority change succeeded.
Continue test of file 'work_GFN32768.in' at line 1 - 09:15:44
Testing 5299830^32768+1...
Checkpoint saved by another build of genefer (22 18). This version cannot resta
rt with it.

>genefer80.exe work_GFN32768.in
genefer80 2.3.0-0 (Windows x86 80-bit x87)
...
Command line: genefer80.exe work_GFN32768.in

Priority change succeeded.
Continue test of file 'work_GFN32768.in' at line 1 - 09:16:40
Resuming 5299830^32768+1 from a checkpoint (561787 iterations left)
Estimated total run time for 5299830^32768+1 is 0:27:26

No luck with -V switch, it complains that

-V used with incompatible option (filename, -boinc, -d, -device, -b, -b2, -b3, -t, -r, -l, or -q).

genefx64 2.3.0-0 (Windows x86_64 SSE2)
genefer 2.3.0-0 (WINDOWS x86 32-bit)
genefer80 2.3.0-0 (Windows x86 80-bit x87)

Ok, that's what I thought (and hoped) was the case. That's the old 2.3.0-0 version, not the new 2.3.1-0 with the fix. Either you put the new files in the wrong place, or we gave you the old files again instead of the new files.

So, does this test now work correctly, with the new app versions?

Just to be clear, you should be able to interrupt Genefer in the middle (so it stops with a checkpoint), and then restart, and it should go through all three versions of Genefer and continue running with Genefer80 again. Does that work?

Yes.
I let GFN 32768 run over the weekend, doesn't need any babysitting and it was fine now during ym absence with the new app.
____________
My stats

Yes.
I let GFN 32768 run over the weekend, doesn't need any babysitting and it was fine now during ym absence with the new app.

The problem only happened when you stopped and restarted GFN, so I wouldn't expect a problem to occur if it's just left to run. Does it restart properly after interrupting a test?

The problem only happened when you stopped and restarted GFN, so I wouldn't expect a problem to occur if it's just left to run. Does it restart properly after interrupting a test?

I did several random restarts before leaving for weekend and found no problem.

Thanks Honza!
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!