Hi all,

We are getting ready to release Genefer version 3.2.9, which has a couple of new features:

• OCL2 and OCL3 extended B-limit transforms
  
• Progress trickle reporting for BOINC
  

Builds for testing are available from the SVN:

Mac: https://www.assembla.com/code/genefer/subversion/nodes/939/trunk/bin/mac
Windows: https://www.assembla.com/code/genefer/subversion/nodes/939/trunk/bin/windows
Linux: https://www.assembla.com/code/genefer/subversion/nodes/939/trunk/bin/linux

A spreadsheet to record testing progress is available here:

https://docs.google.com/spreadsheets/d/1wbJOyqZP7oJ8k4bcJKNUfU8v5U3EGx-xNB8clqVcX84

Please read the instructions, reserve and execute any tests that you can. There are 2 kinds of tests available:

• Manual tests of all the builds on all platforms for two small (n=16, n=17) candidates
  
• BOINC tests of all apps on all platforms (using app_info.xml)
  

Although the transform implementations have not changed apart from OCL2 and OCL3, there have been various changes to the build environment and we'd like to check everything works before releasing on BOINC.

Thanks

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

We are aware of an issue where the Mac OCL2 app fails on ATI hardware (the OpenCL compiler returns an error), however I have tested it and found it to work on an Intel HD integrated graphics card.

If anyone has access to a Mac with ANY graphics card can you please try the OpenCL apps (esp OCL2). We need to understand if the app works on Nvidia hardware, and if it works on any ATI cards at all.

It's enough to run ./geneferocl2 -t and check that some primes are reported.

Please post your results here, thanks!

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

Command line: ./geneferocl2_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL2"

Testing 9999924^32+1...
Using OCL2 transform

Running on platform 'Apple', device 'ATI Radeon HD 5770', version 'OpenCL 1.2 ' and driver '1.2 (Aug 28 2015 19:26:19)'.

Error: build program failed.
Error returned by cvms_element_build_from_source
Error: OpenCL error detected: CL_BUILD_PROGRAM_FAILURE.

Command line: ./geneferocl2_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL2"

Testing 9999924^32+1...
Using OCL2 transform

Running on platform 'Apple', device 'GeForce GTX 680', version 'OpenCL 1.2 ' and driver '10.5.2 346.02.03f01'.

Starting initialization...
Initialization complete (0.000 seconds).
9999924^32+1 is a probable prime. (224 digits) (err = 0.0000) (time = 0:00:22) 10:29:45

Testing 9999822^64+1...
Using OCL2 transform
Starting initialization...
Initialization complete (0.000 seconds).
Estimated time remaining for 9999822^64+1 is 0:00:00
9999822^64+1 is a probable prime. (448 digits) (err = 0.0001) (time = 0:00:01) 10:29:46

Testing 8999972^128+1...
Using OCL2 transform
Starting initialization...
Initialization complete (0.000 seconds).
Estimated time remaining for 8999972^128+1 is 0:00:02
8999972^128+1 is a probable prime. (891 digits) (err = 0.0001) (time = 0:00:04) 10:29:50

Command line: ./geneferocl2_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL2"

Testing 9999924^32+1...
Using OCL2 transform

Running on platform 'Apple', device 'HD Graphics 4000', version 'OpenCL 1.2 ' and driver '1.2(Jul 29 2015 02:40:37)'.

Starting initialization...
Initialization complete (0.000 seconds).
Testing 9999924^32+1... 743 steps to go
maxErr exceeded for 9999924^32+1, 0.5000 > 0.4500 during final check

Command line: ./geneferocl2_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL2"

Testing 9999924^32+1...
Using OCL2 transform

Running on platform 'Apple', device 'ATI Radeon HD Tahiti XT Prototype Compute Engine', version 'OpenCL 1.2 ' and driver '1.2 (Jul 29 2015 02:43:15)'.

Error: build program failed.
Error returned by cvms_element_build_from_source
Error: OpenCL error detected: CL_BUILD_PROGRAM_FAILURE.

With OCL2 I only had success on a gtx 680 (results in separate posts).

OCL3 appears to work on a 5770:

Command line: ./geneferocl3_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL3"

Testing 100014^32+1...
Using OCL3 transform

Running on platform 'Apple', device 'ATI Radeon HD 5770', version 'OpenCL 1.2 ' and driver '1.2 (Aug 28 2015 19:26:19)'.

Starting initialization...
Initialization complete (0.000 seconds).
100014^32+1 is a probable prime. (161 digits) (err = 0.0000) (time = 0:00:03) 10:42:18

Testing 100234^64+1...
Using OCL3 transform
Starting initialization...
Initialization complete (0.000 seconds).
Estimated time remaining for 100234^64+1 is 0:00:00
100234^64+1 is a probable prime. (321 digits) (err = 0.0000) (time = 0:00:00) 10:42:18

geneferocl appears to work on an r9 280x

Command line: ./geneferocl_macintel -t

Priority change succeeded.
Running tests for transform implementation "OCL"

Testing 100234^64+1...
Using OCL transform

Running on platform 'Apple', device 'ATI Radeon HD Tahiti XT Prototype Compute Engine', version 'OpenCL 1.2 ' and driver '1.2 (Jul 29 2015 02:43:15)'.

Starting initialization...
Initialization complete (0.000 seconds).
Estimated time remaining for 100234^64+1 is 0:00:00
100234^64+1 is a probable prime. (321 digits) (err = 0.0000) (time = 0:00:04) 10:41:19

Thanks Van Zimmerman,

So OCL2 also fails on your ATI card (which is a different model to mine) with the same error that I saw.

I see that you get a round-off error on the HD 4000, but that runs OK on my Iris Pro.

Could you take the Mac/Nvidia tests in the testing spreadsheet?

- Iain

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

The question was specifically about OCL2. We know there's a problem with OCL2 and want to see how widespread it is. OCL and OCL3 aren't affected.

No need to post "OCL works" or "OCL3 works". We know. It will just clutter up the thread and make it harder to find the information about OCL2. Thank you!

(EDIT: I'm pointing this out not to criticize you for trying to be thorough and helpful. I want to prevent 100 other posts saying "OCL works!" by everyone else. It's just OCL2 on the Mac that's problematic.)
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Will do.

Specifically OCL2 failed on 2 ATI cards, a 5770 and an r9 280x.

Will do.

Specifically OCL2 failed on 2 ATI cards, a 5770 and an r9 280x.

Hmmmm ...

Looking at the test matrix, it's probably not feasible to do the BOINC test of the 32 bit CPU app on an actual 32 bit CPU. Even with the deadline extension to 84 days for the n=21 tasks, which is about 2000 hours, most actual 32 bit CPUs can't complete the task that quickly. Mine will take about 3000 hours. Jim's is about the same speed. I think there are some 32 bit CPUs that have SSE2 which could probably do it within the deadline. It will still be very slow, but might be fast enough to make the deadline. I doubt it's worth the wait to use a real 32 bit CPU for the BOINC tests. We certainly don't want to be testing the apps for the next three months!
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Will do.

Specifically OCL2 failed on 2 ATI cards, a 5770 and an r9 280x.

And I was really hoping it was just Iain's machine. ::sigh::

While we're testing stuff -- do any of your Macs have both an integrated GPU and a discrete GPU? If yes, when you run any of the OCL apps (OCL, OCL2, or OCL3), which GPU does it run on?

I realized I may be doing something futile-testing the 32 bit windows binaries for AMD/ATI on a 64-bit machine. Should I stop?

I realized I may be doing something futile-testing the 32 bit windows binaries for AMD/ATI on a 64-bit machine. Should I stop?

Genefercuda on the mac appears to be hard coded to the 6.0 toolkit:

dyld: Library not loaded: @rpath/libcufft.6.0.dylib
Referenced from: /Users/vzimmerman/Downloads/test/cuda/./genefercuda_macintel
Reason: image not found
Trace/BPT trap: 5

I have libcufft.7.5.dylib

Genefercuda on the mac appears to be hard coded to the 6.0 toolkit:

dyld: Library not loaded: @rpath/libcufft.6.0.dylib
Referenced from: /Users/vzimmerman/Downloads/test/cuda/./genefercuda_macintel
Reason: image not found
Trace/BPT trap: 5

I have libcufft.7.5.dylib

It was a bit more complex than that, but I got it working. Had to copy the files to /usr/lib and rename them to *.6.0.dylib (symlinking didn't seem to want to work, as did either the original files or the renamed files in the executable directory), but all is well now.

Genefercuda on the mac appears to be hard coded to the 6.0 toolkit:

dyld: Library not loaded: @rpath/libcufft.6.0.dylib
Referenced from: /Users/vzimmerman/Downloads/test/cuda/./genefercuda_macintel
Reason: image not found
Trace/BPT trap: 5

I have libcufft.7.5.dylib

When used in BOINC, we ship the necessary dll's and libraries along with the rest of the app.

Please download the two libraries from https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/lib/mac and place them in the same folder as your executable. Those are the 6.0 libraries.

All three of the apps attempt to use the discrete (AMD 6770M) GPU. OCL3 successfully, OCL2 fails with the same error as with other attempts, and OCL doesn't find any usable devices.

Will do.

Specifically OCL2 failed on 2 ATI cards, a 5770 and an r9 280x.

And I was really hoping it was just Iain's machine. ::sigh::

While we're testing stuff -- do any of your Macs have both an integrated GPU and a discrete GPU? If yes, when you run any of the OCL apps (OCL, OCL2, or OCL3), which GPU does it run on?

All three of the apps attempt to use the discrete (AMD 6770M) GPU. OCL3 successfully, OCL2 fails with the same error as with other attempts, and OCL doesn't find any usable devices.

We are short of testing on Linux - in particular 32 bit linux with NVidia or ATI GPUs and 64 bit linux with ATI. If you have either of these systems please help! If you have any question about what to do please post here or PM me. The manual tests should only take a few hours to complete.

Cheers

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

We are short of testing on Linux - in particular 32 bit linux with NVidia or ATI GPUs and 64 bit linux with ATI. If you have either of these systems please help! If you have any question about what to do please post here or PM me. The manual tests should only take a few hours to complete.

Cheers

- Iain

We are short of testing on Linux - in particular 32 bit linux with NVidia or ATI GPUs and 64 bit linux with ATI. If you have either of these systems please help! If you have any question about what to do please post here or PM me. The manual tests should only take a few hours to complete.

Cheers

- Iain

Working on the 32 bit tests now. If I have time before work I'll do the 64 bit as well (needs a fresh install). Probably won't be able to do any BOINC testing.

32 bit Linux OCL tests done. Will try the 64s tonight. For the CUDA, can anyone tell me what packages (in ubuntu) are required to get CUDA going so that cufft*.so is located by the program? I've got 304 and 349 drivers installed (304 is the latest for easy OCL) and several other NV packages, but still get that error.

Since there was an error on my Windows OCL2 NV Boinc test, I'm rerunning it on two machines, the original and another. Since the spreadsheet is understandably locked for that cell, here are the links to the two tasks.

http://www.primegrid.com/result.php?resultid=651635241
http://www.primegrid.com/result.php?resultid=651635232
____________
Eating more cheese on Thursdays.

32 bit Linux OCL tests done. Will try the 64s tonight. For the CUDA, can anyone tell me what packages (in ubuntu) are required to get CUDA going so that cufft*.so is located by the program? I've got 304 and 349 drivers installed (304 is the latest for easy OCL) and several other NV packages, but still get that error.

Since there was an error on my Windows OCL2 NV Boinc test, I'm rerunning it on two machines, the original and another. Since the spreadsheet is understandably locked for that cell, here are the links to the two tasks.

http://www.primegrid.com/result.php?resultid=651635241
http://www.primegrid.com/result.php?resultid=651635232

32 bit Linux OCL tests done. Will try the 64s tonight. For the CUDA, can anyone tell me what packages (in ubuntu) are required to get CUDA going so that cufft*.so is located by the program?

Since there was an error on my Windows OCL2 NV Boinc test, I'm rerunning it on two machines, the original and another.

If you saw my earlier post regarding Linux CUDA libraries before I edited it, the libraries need to be renamed (remove _32bit or _64bit).
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Okay, thanks for the CUDA help, running now. Should anyone search and find this later (and that includes me), some helpful notes:
Driver 304 is the latest with built in OpenCL, but won't run Cuda 5.5 (346 will)
The libraries should be placed in the /lib/ folder to be easily found.

On the subject of the OCL2 tasks, it failed again on my main machine and is still running on the trusty 580. I'm giving it one last go with the lowest clocks I can set (being the Strix 980 ti OC model, that's still 1277 MHz boost on the core and 6600 on the memory) and the fans on 50% in case it is a clock/stability issue.
____________
Eating more cheese on Thursdays.

On the subject of the OCL2 tasks, it failed again on my main machine and is still running on the trusty 580. I'm giving it one last go with the lowest clocks I can set (being the Strix 980 ti OC model, that's still 1277 MHz boost on the core and 6600 on the memory) and the fans on 50% in case it is a clock/stability issue.

On the subject of the OCL2 tasks, it failed again on my main machine and is still running on the trusty 580. I'm giving it one last go with the lowest clocks I can set (being the Strix 980 ti OC model, that's still 1277 MHz boost on the core and 6600 on the memory) and the fans on 50% in case it is a clock/stability issue.

A 980 Ti was found to hit problems with core clock at 1535MHz but OK at 1500 here: http://www.primegrid.com/forum_thread.php?id=6391&nowrap=true#87809

What OC were you running when it failed?

On the subject of the OCL2 tasks, it failed again on my main machine and is still running on the trusty 580. I'm giving it one last go with the lowest clocks I can set (being the Strix 980 ti OC model, that's still 1277 MHz boost on the core and 6600 on the memory) and the fans on 50% in case it is a clock/stability issue.

On the subject of the OCL2 tasks, it failed again on my main machine and is still running on the trusty 580. I'm giving it one last go with the lowest clocks I can set (being the Strix 980 ti OC model, that's still 1277 MHz boost on the core and 6600 on the memory) and the fans on 50% in case it is a clock/stability issue.

Did it fail at the same place?

I could do some BOINC testing on linux64 for ATI. Will need some help with the app_info.xml, though (I suspect my issue is with plan_class). My "closest" to success resulted in either a string of computation errors, or a single work unit sitting ready to start and not executing.

I could do some BOINC testing on linux64 for ATI. Will need some help with the app_info.xml, though (I suspect my issue is with plan_class). My "closest" to success resulted in either a string of computation errors, or a single work unit sitting ready to start and not executing.

OCL2 Windows done and done and validated :)

http://www.primegrid.com/result.php?resultid=651679238
____________
Eating more cheese on Thursdays.

OCL2 Windows done and done and validated :)

http://www.primegrid.com/result.php?resultid=651679238

No luck. My was identical except for the linux-related changes and the api stuff (for 7.2.42). It downoads a work unit, and it sits in "ready to start".

Is there a link somehwere as to what the apropos choices for plan_class are for genefer?

The machine otherwise happily crunches gfn tasks with no app_info present.

http://www.primegrid.com/workunit.php?wuid=448117770

I could do some BOINC testing on linux64 for ATI. Will need some help with the app_info.xml, though (I suspect my issue is with plan_class). My "closest" to success resulted in either a string of computation errors, or a single work unit sitting ready to start and not executing.

Here is the app_info I'm using successfully on my Windows ATI machine. The file is pretty OS/platform agnostic, so changing the file names to their linux equivalents (preceded by ./ I believe) should hopefully work for you.

<app_info> <app> <name>genefer</name> <user_friendly_name>genefer</user_friendly_name> </app> <file_info> <name>geneferocl2_windows.exe</name> <executable/> </file_info> <app_version> <app_name>genefer</app_name> <version_num>308</version_num> <api_version>7.0.64</api_version> <coproc> <type>ATI</type> <count>1</count> </coproc> <file_ref> <file_name>geneferocl2_windows.exe</file_name> <main_program/> </file_ref> </app_version> </app_info>

On a semi-related topic, now that all the standalone testing has been completed and there is only Boinc testing left, I wonder if there is something that can be done about the length of the tasks we run. Would there be a way to temporarily create a smaller GFN subproject that admins can give testers special account permission to access that might be seeded with old verified results to operate against (e.g. our recent double-check efforts on 18 and 19)?

Thanks to mackerel's Boinc on Linux thread, I'd love to sit down and get it working on my installs, and if I can run shorter tasks in testing I can finish it in a couple days or less (instead of the 3-4 weeks calculated, assuming no errors) and jump into the WSS challenge (or even get in the back end of the TRP). I'll note for the curious that all my linux testing is done serially on one computer by manually swapping OS drives and GPUs to the appropriate combo for a test. It's a 3930k with 4x8gb ram, and someday I'll see if there is a performance difference if the system can only utilize the capacity of less than half a single stick of memory.

Is there a link somehwere as to what the apropos choices for plan_class are for genefer?

Not sure why either, it has made the difference between working and not, at least on a mac.

Many thanks. It lives! Testing commenced. Should be just under 14 hours for ocl.

Not sure why either, it has made the difference between working and not, at least on a mac.

Many thanks. It lives! Testing commenced. Should be just under 14 hours for ocl.

To echo Grebuloner's sentiment, http://www.primegrid.com/workunit.php?wuid=447576738 is 98 hours in, and 72% complete. Assuming OCL2 (which this task is running) is faster than OCL on mac-cuda, I suspect the OCL run will take quite a while. OCL3 took just under 30 hours to complete http://www.primegrid.com/workunit.php?wuid=447803055.

On a semi-related topic, now that all the standalone testing has been completed and there is only Boinc testing left, I wonder if there is something that can be done about the length of the tasks we run. Would there be a way to temporarily create a smaller GFN subproject that admins can give testers special account permission to access that might be seeded with old verified results to operate against (e.g. our recent double-check efforts on 18 and 19)?

Thanks to mackerel's Boinc on Linux thread, I'd love to sit down and get it working on my installs, and if I can run shorter tasks in testing I can finish it in a couple days or less (instead of the 3-4 weeks calculated, assuming no errors) and jump into the WSS challenge (or even get in the back end of the TRP). I'll note for the curious that all my linux testing is done serially on one computer by manually swapping OS drives and GPUs to the appropriate combo for a test. It's a 3930k with 4x8gb ram, and someday I'll see if there is a performance difference if the system can only utilize the capacity of less than half a single stick of memory.

To echo Grebuloner's sentiment, http://www.primegrid.com/workunit.php?wuid=447576738 is 98 hours in, and 72% complete. Assuming OCL2 (which this task is running) is faster than OCL on mac-cuda, I suspect the OCL run will take quite a while. OCL3 took just under 30 hours to complete http://www.primegrid.com/workunit.php?wuid=447803055.

Apologies.

Bearing that out, my boinc test run(s) on linux64 w/ati finished 4 units at 13.5 hours each w/ocl. I started ocl2 runs and calculating out, am looking at around 150 hours. Interestingly, but not necessarily surprisingly, the card is running 7c or so cooler. Also interestingly, the ocl2 tasks (its running a 7990) restarted themselves several times at approximately .010% before proceeding cleanly forward (so far).

To echo Grebuloner's sentiment, http://www.primegrid.com/workunit.php?wuid=447576738 is 98 hours in, and 72% complete. Assuming OCL2 (which this task is running) is faster than OCL on mac-cuda, I suspect the OCL run will take quite a while. OCL3 took just under 30 hours to complete http://www.primegrid.com/workunit.php?wuid=447803055.

You have it backwards. OCL2 is several times slower than OCL. OCL3 is usually somewhat slower than OCL, but may be faster than OCL on some GPUs. Both are (much) faster than OCL2.

Putting numerical values on it, faster being better, OCL is an 8, OCL3 is usually a 6 or 7, but sometimes as high as 9, and OCL2 is a 2 or 3.

On most systems, OCL is the fastest available app.

...I wonder if there is something that can be done about the length of the tasks we run. Would there be a way to temporarily create a smaller GFN subproject...

I have discovered a new bug in 3.2.9, at least in the Windows version of the CUDA and GPU apps. I don't know if it affects other builds. It's a BOINC interface problem, so it will only be seen when running real BOINC apps under app_info.

The problem is that the app isn't updating the BOINC client with its progress. Normally, you'll see the % complete bar go up periodically, and the time-remaining will change accordingly. Those updates aren't happening, so the BOINC client is faking the progress, incrementing the progress by exactly 0.001% each time, and never changing the time-remaining estimate.

For anyone who is currently running 3.2.9 under app_info, you might want to check to see if the progress is updating correctly. "Correctly" means A) the progress is going up by more than 0.001% at each increment, and B) the time remaining varies somewhat.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I currently have 2 tests in flight.

For cuda/mac, it is incrementing by 0.001%, when it increments. It increments every second for 4-7 seconds or so, then increments every other second or so, then repeats. Time remaing varies by roughly 30-50 seconds each increment. Time remaining would appear to be overestimated. Time elapsed, just under 20 hours, progress, just under 60%, estimated time remaining 591 hours.

For linux64/amd running ocl2, it is incrementing by 0.001%, when it increments, which is every 4-5 seconds. Time remaining changes a bit. Time remaining appears to be underestimated. Time elapsed 91 hours, 62%, time remaining 20 hours.

...I wonder if there is something that can be done about the length of the tasks we run. Would there be a way to temporarily create a smaller GFN subproject...

We may have something to say about this idea in the next couple of days.

...I wonder if there is something that can be done about the length of the tasks we run. Would there be a way to temporarily create a smaller GFN subproject...

We may have something to say about this idea in the next couple of days.

32768 and 65536 are open for beta testing!

If you go to the PrimeGrid preferences page, you'll see that you can now choose 32768 and 65536 tasks. You'll also see that it says "beta" next to every check box.

The server is now providing 32768 and 65536 tasks. However, with one exception, it's NOT yet sending you the apps for those tasks. We're still testing them. You asked for shorter tasks for the 3.2.9 tests, and now you have them. You'll need to use app_info.xml, just like you were with n=21.

What's the exception? We want to give OCL2 and OCL3 a good workout comparing residues against the older genefer residues, so if you select the OCL checkboxes for either Nvidia or ATI/AMD, the server will send you the app -- no app_info.xml is needed. For 32768 the server is sending the OCL2 app, and for 65536 the server is sending the OCL3 app. Note that the tests are technically small enough to run with OCL, but we want to give OCL2 and OCL3 a thorough shakeout.

You may also notice that GFN-WR now has a CPU checkbox. It's also in beta, but if you check it and use app_info, you can get CPU apps for the world record tasks.

EDIT: I forgot to mention that OCL2 is NOT available for Mac on ATI/AMD GPUs. This affects 32768, but not 65536.

EDIT 2: Also note that we will be double checking all prior PRPNet and external work before moving on to new numbers.

Okay, so my 970 grabbed a few of the 65536 tasks. This so weird... after being used to the week long, GFN WR tasks, those 2min< tasks just seem insane. So far, 2 (edit: 3) validated already, everything seems fine.

Gonna see how it behaves overnight....

EDIT 2: It just whines like a train hitting the brakes......

Regarding the PRPNet ports, once we're out of beta on 32768 and 65536 (i.e., you no longer need app info and the server is sending out OCL instead of OCL2 or OCL3) we'll be setting the PRPNet 32768 and 65536 ports to "no new work", and shut them down completely once all outstanding tasks are returned.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

You may also notice that GFN-WR now has a CPU checkbox. It's also in beta, but if you check it and use app_info, you can get CPU apps for the world record tasks.

Ok so here's a stupid question...

I managed to compile a genefer cpu app (3.2.9) for FreeBSD 64 bit and am currently testing it. Is the Genefer WR cpu app going to be the same as the Genefer cpu app found at:

https://www.assembla.com/spaces/genefer/subversion/source/HEAD/trunk/src/genefer

?

Okay, so I was playing with the new apps... Ain't credit a bit on the low side?

My last GFN-WR for the CUDA app (so it uses almost no CPU at all) gave me a 103k PPD.
My last GFN-21 for the OCL app gave me 104k PPD.

However, GFN-16 is giving around 53k PPD. And that's because it's using OCL3, which runs much faster on Maxwell cards than the regular OCL does, so I'd expect people with older cards to have even lower yelds. GFN-15 is at 21k, which I guess comes from the fact that it runs the "uber slow" OCL 2.

Doesn't feel like crunching small WUs when long ones reward you so much better.......

OH. Is that why?

Okay, so I was playing with the new apps... Ain't credit a bit on the low side?

My last GFN-WR for the CUDA app (so it uses almost no CPU at all) gave me a 103k PPD.
My last GFN-21 for the OCL app gave me 104k PPD.

However, GFN-16 is giving around 53k PPD. And that's because it's using OCL3, which runs much faster on Maxwell cards than the regular OCL does, so I'd expect people with older cards to have even lower yelds. GFN-15 is at 21k, which I guess comes from the fact that it runs the "uber slow" OCL 2.

Doesn't feel like crunching small WUs when long ones reward you so much better.......

OH. Is that why?

Keeping up with my ongoing theme of forgetting to include useful information, here's the app and plan_class names you'll need to get app_info working correctly on 32768 and 65536:

For 32768:

app name: genefer15

plan class names:

cpuGFN15 (for CPU apps)
cudaGFN15 (for CUDA -- not sure if the server will send these since you can't select them.)
OCLcudaGFN15 (for OCL/OCL2/OCL3 on Nvidia GPUs)
atiGFN15 (for OCL/OCL2/OCL3 on ATI/AMD GPUs -- Windows/Linux only)
openclGFNMAC15 (for OCL/OCL2/OCL3 on ATI/AMD GPUs -- Mac only)


For 65536:

app name: genefer16

plan class names:

cpuGFN16 (for CPU apps)
cudaGFN16 (for CUDA -- not sure if the server will send these since you can't select them.)
OCLcudaGFN16 (for OCL/OCL2/OCL3 on Nvidia GPUs)
atiGFN16 (for OCL/OCL2/OCL3 on ATI/AMD GPUs -- Windows/Linux only)
openclGFNMAC16 (for OCL/OCL2/OCL3 on ATI/AMD GPUs -- Mac only)

Note that for openclGFNMAC15 and openclGFNMAC16 we expect the OCL2 app to fail. It's a known bug, with no known fix at the present time.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

For World Record (N=22) CPU tasks, the app name is genefer_wr and the plan class is cpuGFNWR.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

Thanks Michael! Giving my test machine a break from the PRP challenge, I got BOINC GPU crunching up and running on the Linux 32 partition, and have begun running 15/16 WUs (after making a small correction, apologies for 142 aborted WUs!). Updating the testing matrix as I go.

On GFN15/16, are the b's low enough for OCL to run? It'll save me some time before I swap out the 7950 for a 480 to start Nvidia crunching.
____________
Eating more cheese on Thursdays.

On 15/16, b is currently low enough for anything to run.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

On 15/16, b is currently low enough for anything to run.

I have not seen any progress anomalies on linux64/amd or mac/nvidia. The only one of those two suites I haven't run yet is linux64/amd ocl3, which I'll fire up tomorrow morning.

On 15/16, b is currently low enough for anything to run.

Because I felt adventurous, I tried OCL 3 on GFN-WR. Looks like this one was a fail.. http://www.primegrid.com/result.php?resultid=653284461

EDIT: Max err 1.000 >0.450...... great. I thought our beta estabilished that I could run at 1569mhz just fine (http://www.primegrid.com/forum_thread.php?id=6391&nowrap=true#87809), but I guess 1480mhz is not doing it for actual WUs. I'll play with it a bit further later.



Also, I've seen one of the GFN-16 tasks get stuck on 99% progress once. Both CPU and GPU usage were at 0%, the task was just idling there for no reason. Suspending and resuming the task fixed, though, and it was able to resume computation at the last checkpoint (around 54%).

My 150 hour estimate after 20 minutes of run time for linux64/amd/ocl2 turned into 145.73 hours actual, so I'd have to say the progress indicator was pretty accurate.

It is interesting to see the peformance variations across platforms/cards.

On Mac/Nvidia w/gtx680, I got the following run times (hours)

cuda 33.62
ocl 24.88
ocl2 135.24
ocl3 29.72

On linux64/amd w/7990, I got the following (for one unit on one gpu w/2 running)
ocl 13.51
ocl2 145.73
projecting ocl3 150.22 after 2 hours run time

Curious that a card that is so much better at DP looks like it gets clobbered by ocl3.

32768 and 65536 are now in normal production mode.

CPU and OCL apps are are available by selecting the corresponding check boxes; app_info is not needed. Note that this is the original OCL app, which is substantially faster than OCL2, and on most GPUs is faster than OCL3. On some GPUs, notably Nvidia Maxwell architectures, OCL3 may be faster than OCL. For now, if you want to use OCL3 you'll have to use app_info. We have plans to make this automatic in the future, but I don't yet have a reliable estimate of when that will happen.

The N=22 (World Record) CPU tasks are still in "beta" testing, so you still need to use app_info if you want to test that app.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

32768 and 65536 are now in normal production mode.

CPU and OCL apps are are available by selecting the corresponding check boxes; app_info is not needed. Note that this is the original OCL app, which is substantially faster than OCL2, and on most GPUs is faster than OCL3. On some GPUs, notably Nvidia Maxwell architectures, OCL3 may be faster than OCL. For now, if you want to use OCL3 you'll have to use app_info. We have plans to make this automatic in the future, but I don't yet have a reliable estimate of when that will happen.

The N=22 (World Record) CPU tasks are still in "beta" testing, so you still need to use app_info if you want to test that app.

Question since the original is faster, when selecting these for work, will you give us the option of using the OCL of our choice in the future?

Also, I noticed a post earlier that these are all double checks and as such a 2nd dc was not going to be done (at least I think I read that) so, if we get a hit will it count as a DC?

One more thing about OCL -- on such small tasks, GPUs aren't as efficient as you're used to on the larger tasks. Especially with these smaller B values where AVX/FMA3 is usable. I can do four 32768s on the CPU in about 80 seconds (drawing about 60 watts), and one task on the GPU in about 30 seconds (drawing close to 200 watts). If I was going to crunch those GFNs, I'm not sure I'd use the GPU until the B values get large enough so the CPU is using x87 and the GPU is using OCL3. Right now, I think I'd stick with the CPU.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I was looking at the GFN Preference page, and I saw this:

9 At this time the OCL2 app (used only for n=17-mega) is not available for Mac computers with ATI/AMD GPUs.

One more thing about OCL -- on such small tasks, GPUs aren't as efficient as you're used to on the larger tasks. Especially with these smaller B values where AVX/FMA3 is usable

GFN-15 only

i7-2600k 3.4 GHz ~100s
i5-4570s 3.2 GHz ~80s
i7-6700k 4.0 GHz ~35s

R9 280X mostly ~35s, one unit 21s, some units >150s
GTX 980Ti ~45s
GTX 960 ~60s

Systems are running 3 CPU tasks and 1 GPU task at the same time. I note the AMD GPU doesn't seem to take noticeable CPU but to be safe I'm still leaving a core free for it.

Odd the R9 280X seems to have quite variable runtimes. This doesn't appear to be happening on nvidia cards.

GFN-16 only

i7-2600k 3.4 GHz ~392s
i5-4570s 3.2 GHz ~332s
i7-6700k 4.0 GHz ~226s

R9 280X mostly ~97s, some units <81s, longest unit >300s
GTX 980Ti ~113s
GTX 960 ~204s

Still the variation on the AMD GPU.

I assume since we're in double check, and units are currently very small, they might go up rapidly. So I don't know how long these timings will be useful for.

After my little fail at the GFN-WR with the OCL3, I decided to try again. I thought that the issue was my card reducing voltage due to thermals (and thus causing instability), so I closely monitored my temps and voltages to make sure I'd keep stability on my OC. At first, everything seemed fine. The WU was crunching away.... until it happened, I got the Max Err 1 > 0.45 again. I was pretty pissed; after all, the WU was doing just fine before.

So I just said "screw it, I'm running stock speeds again, enough OC problems for today". But to my surprise, even at stock, it just keeps getting the error! At this rate, I'll have to abort the task and waste another 2h of work.

Any ideas? It's the second time it happens, with or without OCing. Is that the app with problems, or am I doing something wrong?

When you say without OC, is the card running at stock nvidia clocks, or is it factory overclocked anyway? I forget exactly which card it was but I had a factory OC one. It wouldn't crunch stably until I reduced it to nvidia standard clocks.

Are there new Badges for this tasks?

When you say without OC, is the card running at stock nvidia clocks, or is it factory overclocked anyway? I forget exactly which card it was but I had a factory OC one. It wouldn't crunch stably until I reduced it to nvidia standard clocks.