| Author |
Message |
|---|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
                               
|
|
Thanks to the work of MANY people, there's a new version Genefer available for ALL three major platforms.
If you're using app_info.xml, please read Genefer v1.06 is now Deprecated
If you're not using app_info.xml, no action is necessary on your part. You will get the new application the next time a GFN task is sent to your computer. (If you don't know what app_info.xml is, don't worry about it -- you're not using it.)
This release includes both GPU (GeneferCUDA) and CPU (Genefx64) variants, both of which are available for Mac/Intel, Linux, and Windows. (The real version number is 2.3.0-0, but BOINC can't handle that so it's 1.07 or 1.08 on the BOINC web pages.) For non BOINC usage, particularly on PRPNet, there's also corresponding releases of Genefer and Genefer80.
Please note that the CPU apps are only used for the Short WUs. CPUs can't complete the Long (World Record) WUs within the deadlines, so only GPU apps are used for the long WUs.
GeneferCUDA/Genefx64 2.3.0-0 has the following fixes and enhancements, as compared to v1.06:
- New code base that combines the 4 Genefer variants. This greatly improves the ability to perform maintenance going forward.
- The truncation of stderr output under BOINC has been fixed.
- "-b3" benchmark added. This displays the expected run times for a variety of GFNs.
- Benchmark time reduced from 10000 to 1000. Benchmarks will run ten times faster.
- For GPU initialization errors such as the 295 driver sleep error, delay up to an hour before returning an error. This reduces the load on the server and also allows the WU to continue running should the condition causing the error be resolved. Applies to both BOINC and PRPNet.
- BOINC censorship behavior changed. We now display the number, but don't display the result (i.e., prime or composite).
- While processing a WU, the predicted total run time of the WU is displayed after enough iterations have been run to get a stable timing estimate. On PRPNet or when run from the command line, this is shown on he console before the periodic update messages. Under BOINC, this can be found in the stderr.txt file in the appropriate slot directory. Accuracy should be better than 99%.
- Under PRPNet or when used via the command line, the periodic update messages now display the predicted remaining time to completion. Accuracy should be better than 99%.
- For PRPNet: SHIFT default values can be overridden by specify SHIFT= in the configuration file "genefer.cfg". On systems where the default values are not the fastest, this will provide a speed increase when running GeneferCUDA under PRPNet.
- Fixed a bug where rounding errors at the very end of the calculation weren't being detected.
- The periodic checkpoint process is now more resistant to having files locked by backup programs and virus scanners. This eliminates one cause of crashes.
- Fixed that pesky problem with the Linux Benchmarks.
- Once the Linux benchmarks were fixed, the block size values for the Linux and Mac/Intel versions of GeneferCUDA were adjusted for maximum speed.
This can be used with either PRPNet or BOINC (with the appropriate app_info, of course.)
____________
My lucky number is 75898524288+1
|
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,402,379,339
RAC: 2,512,564
                                   
|
|
I found just small and cosmetic issues
// VERSION History:
// 3.2.0-0 2/28/2012 Michael Goetz, Iain Bethune
I believe it is closer to 2.3.0 since numbering is now with line of original Genefer/80/FX
Output to stderr.txt says 2.3.0
-b3 output could be one character shorter per line (with 8M numbers) so it fit one single line.
Note that this version is compatible with 1.0.x version so no need to wait for finishing current test, one can upgrade to 2.3.0 version anytime.
2.3.0 resumed where 1.0.7 checkpointed, good one.
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
I found just small and cosmetic issues
// VERSION History:
// 3.2.0-0 2/28/2012 Michael Goetz, Iain Bethune
In the changelog, right? Thanks for pointing out the typo.
-b3 output could be one character shorter per line (with 8M numbers) so it fit one single line.
I guess that depends on how wide your console screen is. The line length is also going to vary from system to system: For me, all the lines from 75898^2097152 onward are the same length -- and about 10 characters shorter than the quasi-standard 132 column width.
Note that this version is compatible with 1.0.x version so no need to wait for finishing current test, one can upgrade to 2.3.0 version anytime.
2.3.0 resumed where 1.0.7 checkpointed, good one.
Oh, I should have mentioned that: it's definitely *** NOT *** compatible. Well, at least not compatible with the previous version of the code I was running. If you switch executables in the middle of a WU, don't be surprised if the WU dies.
If yours did work -- you were lucky. The identifier string inside the checkpoint file has changed several times during the development of 2.3.0, and if it worked for you, that just means that it got changed back to what it had been previously, quite by accident. If the files aren't exactly compatible, the WU will be trashed. That's probably not something you want to do with GFN-WR WUs that have a few days worth of crunching already done.
Changing executables in the middle of a WU is NEVER recommended.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,402,379,339
RAC: 2,512,564
|
That's probably not something you want to do with GFN-WR WUs that have a few days worth of crunching already done.
I was quite surprices that the WU finishind without trashing/complaining in stderr.txt
Sure I waited until WR WU got finished :-)
Ad. console screen. Windows default is set to 80 columns.
____________
My stats |
|
|
|
|
|
and how now to find out whether a number is prime or composite
if both validators are using 2.3 version?
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
and how now to find out whether a number is prime or composite
if both validators are using 2.3 version?
The same as with any other BOINC sub-project here -- you'll get an email from the server.
I'm hoping they'll add the "B^N+1 is composite|prime" line to the WU web page, the same as they have for the LLR projects. I agree it should be on there somewhere.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3246
ID: 50683
Credit: 152,646,050
RAC: 18,212
                    
|
|
If I may noticed / request: can you lower CPU usage?
I assume that quad core Phenom II have enough "power" even at 800 MHz to give data to Genefer Cuda. I look at CPU Z and show that processor goes from 800- 2300 ( jumping) .
This is also for "old " 1.06 and for "new" 2.3
Thanks...
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
If I may noticed / request: can you lower CPU usage?
I assume that quad core Phenom II have enough "power" even at 800 MHz to give data to Genefer Cuda. I look at CPU Z and show that processor goes from 800- 2300 ( jumping) .
This is also for "old " 1.06 and for "new" 2.3
Thanks...
Short answer: No, but you can.
Your computers are hidden, which makes it hard to help.
I think you're running on Windows, right? Generally, CPU usage on Windows seems to be pretty light. I have noticed, however, the CPU usage goes up when more of your CPU cores are in use. There's speculation that interaction with the CPU cache is responsible for this phenomena.
So, if you want to lower CPU usage by GeneferCUDA, either raise the SHIFT value (which, since you're already at the fastest SHIFT, will slow down the GPU), or leave one or more cores idle. That will reduce CPU usage -- but it also defeats the whole purpose of wanting the CPU usage to be lower!
As for your CPU clock changing -- is the rest of the computer idle while the GPU is running? If the CPU is crunching anything, the clock speed should never go down (unless you're on a laptop that's overheating.) If the CPU is idle, it may lower its clock speed to 800, but it can switch the speed instantly, so when it's running the GeneferCUDA program, it's running at high speed. It's probably just switching back and forth for you to see it.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3246
ID: 50683
Credit: 152,646,050
RAC: 18,212
|
|
Only two process are active is PRPNET ( genefercuda) and Avertv( cpu is in idle when watching Avertv)
Look at P.M: there is one link :)
Update: you are right
Regardless CPU freq, voltage stays as low as can...
I will try to experiment with Boinc and set in app_info lower max CPU usage ( in default BOINC uses 0.27 CPU, try to lower at 0.1 CPU)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
If I may noticed / request: can you lower CPU usage?
I'm not sure I understand what you're asking, because the CPU usage is already pretty low. I looked at the computer you linked, and there were two Genefer WUs. Both had elapsed times of about 12,000 seconds, and CPU times of about 400 and 600 seconds. That's about 3% and 5% CPU usage. You're not going to get a lot better than that.
Also, since the program doesn't use the CPU continuously, it's possible that the CPU isn't running at full speed. As an example, let's say that due to low utilization, the CPU is running at 800 MHz instead of 2300 Mhz, that would cause the CPU usage to appear to be three times as high as it actually is because the CPU is running at one third the speed it normally runs at. If that's happening, then you're really only seeing the equivalent of 1% to 2% CPU.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I ran this version successfully in Boinc and also prpnet. I was able to run 2 ea. GFN52488 wu's. Subsequent attempts have failed. I simply notice that the DOS instance has closed. I observed it close within a couple of minutes of launch today.
My GPU is a GTX570 running at a stock (mild) overclock. I had backed-off my high overclock before beginning any of the wu's.
I am running a 2600K overclocked to 4.5Ghz and 8 Gb RAM at 1600.
I am running Boinc simultaneously without any GPU wu's.
I am not running hyperthreading.
I was able to run prpnet GFN32768 wu's all day today on an earlier geneferCUDA version.
Any ideas? I'm perplexed as I was able to successfully complete the 52488's and nothing has changed.
The only thing I can think of is to further downclock the GPU. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
|
When trying to diagnose a problem, it's best to stick with one thing. When your're doing four or five different things, it's hard to identify that the problem is.
I was able to run prpnet GFN32768 wu's all day today on an earlier geneferCUDA version.
At least one thing in what you said has to be a mistake because you can't crunch on PRPNet at N=32768 with GeneferCUDA. The b value is too high for GeneferCUDA. If you were crunching GFN32768, you were using Genefer80, most likely. If you were using geneferCUDA, then you were crunching either GFN262144 or GFN 524288.
I ran this version successfully in Boinc and also prpnet. I was able to run 2 ea. GFN52488 wu's.
I'm not clear on what you meant here. You ran 2 524288 WUs on BOINC? 2 on PRPNet? 1 on each? Sequentially or simultaneously?
Subsequent attempts have failed. I simply notice that the DOS instance has closed.
If you want to diagnose what's happening to GeneferCUDA, you need to capture the screen output. If you're running under BOINC, that is visible when you view the result on the web. (But you MUST unhide your computers if you want help.) For PRPNet, I would recommend running prpclient manually so the DOS window stays open.
I observed it close within a couple of minutes of launch today.
...
My GPU is a GTX570 running at a stock (mild) overclock. I had backed-off my high overclock before beginning any of the wu's.
...
Any ideas? I'm perplexed as I was able to successfully complete the 52488's and nothing has changed.
The only thing I can think of is to further downclock the GPU.
Even a very slight increase in temperature can cause the GPU to fail if it's close to the edge of its operational envelope. That envelope is much smaller when running GeneferCUDA than it is with other programs.
Chances are it's the overclocking. Factory overclocked is still overclocked. But it's just a guess without being able to see what the output from the program is.
If you haven't done so already, read the "how to run GeneferCUDA successfully" thread I started earlier this evening. Perhaps there's something in there that might help.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
[quote
Even a very slight increase in temperature can cause the GPU to fail if it's close to the edge of its operational envelope. That envelope is much smaller when running GeneferCUDA than it is with other programs.
Chances are it's the overclocking. Factory overclocked is still overclocked. But it's just a guess without being able to see what the output from the program is.
If you haven't done so already, read the "how to run GeneferCUDA successfully" thread I started earlier this evening. Perhaps there's something in there that might help.[/quote]
Thanks. I downclocked the GPU a tad below reference and kept the temps below 50C. I just successfully completed a wu. Onward.... |
|
|
|
|
and how now to find out whether a number is prime or composite
if both validators are using 2.3 version?
The same as with any other BOINC sub-project here -- you'll get an email from the server.
I'm hoping they'll add the "B^N+1 is composite|prime" line to the WU web page, the same as they have for the LLR projects. I agree it should be on there somewhere.
So, it happened.
There are only 2 results in task and both clients are using genefercuda 2.3.0-0:
http://www.primegrid.com/workunit.php?wuid=256711152
158568^524288+1 is complete.
in both logs without any idea is the number a prime or a composite.
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
|
I agree.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,402,379,339
RAC: 2,512,564
|
|
Any ETA on when this version becomes stock app?
(I assume this is the plan).
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
Any ETA on when this version becomes stock app?
(I assume this is the plan).
Pretty soon.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
Any ETA on when this version becomes stock app?
(I assume this is the plan).
Pretty soon.
Yesterday's "pretty soon" is today's "now".
All the new apps are deployed.
The first post has been updated with up to date information on the release as a few enhancements were added since the beta was released. The thread title has also been changed to reflect that this is the new stock app.
If you're running with app_info, it is recommended that you upgrade to the new app. Read the 1.06 is deprecated thread for more info about app_info.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
http://www.primegrid.com/result.php?resultid=365360629
cuda_subs.cu(759) : cudaSafeCall() Runtime API error : unknown error.
http://www.primegrid.com/result.php?resultid=365418473
cuda_subs.cu(281) : cufftSafeCall() CUFFT error: 6.
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
http://www.primegrid.com/result.php?resultid=365360629
cuda_subs.cu(759) : cudaSafeCall() Runtime API error : unknown error.
http://www.primegrid.com/result.php?resultid=365418473
cuda_subs.cu(281) : cufftSafeCall() CUFFT error: 6.
That's very hard to diagnose, unfortunately. In both cases, the Nvidia libraries returned an error message indicating that something went wrong, but without any useful information about what the problem is.
The best I can do is speculate.
Guess #1 is that something external was affecting the GPU somehow, but I have no way of knowing what that might be.
Guess #2 is that it's related to your GPU being overclocked, but typically overclocking manifests itself with a different problem.
I actually don't have any good ideas. You could try lowering the GPU to stock clock speeds, but I don't think that's the problem.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
And again. Now with stock 1.07 version:
http://www.primegrid.com/result.php?resultid=364610470
maxErr exceeded for 213822^524288+1, 0.5000 > 0.4500
Strange. There were about 50 successful WUs at 1600MHz memory clock and now 3 failed WUs with 3 different errors in log.
I'll try to return Core clock to stock value and look what happens.
____________
|
|
|
|
|
|
Hi,
same error here after around 70h runtime
http://www.primegrid.com/result.php?resultid=371731984
GTX580 with stock clock
Boinc 7.0.25
appl version 1.07
cuda_subs.cu(281) : cufftSafeCall() CUFFT error: 6.
any advise how to prevent ?
rgds
Tabaluga |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14037
ID: 53948
Credit: 476,923,882
RAC: 275,501
|
any advise how to prevent ?
Unfortunately not.
That error is from Nvidia's FFT library, and it means "the FFT failed." That's not very useful.
It's a rare error, it's not reproducible, and there's about a zillion things that could cause it.
The only advice I can give is that if you happened to be doing anything on the computer at the time -- viewing a webpage with some sort of Flash or video, running a game, etc. -- that you normally don't run, it may have interfered with the CUDA operations. Sometimes it's easy to tell what caused the problem, but often there's no indication of what the cause was.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I have just solved the "cufftSafeCall() CUFFT error: 6." problem on my host. I found that the error always occurs when I use YouTube.
Solution: rightclick on adobe flash player window -> preferences and UNcheck "enable hardware acceleration". |
|
|
