| Author |
Message |
|---|
|
|
|
I see we now have a option for long or short tasks on genfer..When can we expect to see be able to get work from the long task? I just switched over and it said there was no work available...Just curious |
|
|
 Crun-chi Volunteer tester
Send message
Joined: 25 Nov 09
Posts: 3250
ID: 50683
Credit: 152,646,050
RAC: 10,054
                         
|
|
Current status 24.2 12:55 GMT+1
Available: Generalized Fermat Prime Search 1996
____________
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! |
|
|
|
|
Current status 24.2 12:55 GMT+1
Available: Generalized Fermat Prime Search 1996
That could be all short ones right?
____________
 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3250
ID: 50683
Credit: 152,646,050
RAC: 10,054
|
|
Look at yours http://www.primegrid.com/prefs.php?subset=project
At the bottom, where Genefer is located you can select would you use short ones or long tasks... So choice is yours...
____________
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! |
|
|
|
|
So choice is yours...
not yet it isn't. As the OP pointed out there are no long ones available. |
|
|
|
|
|
It's in there now..
but my result is:
<core_client_version>6.12.34</core_client_version>
<![CDATA[
<message>
Die Umgebung stimmt nicht. (0xa) - exit code 10 (0xa)
</message>
<stderr_txt>
GeneferCUDA-boinc 1.06 (CUDA3.2) based on GeneferCUDA 1.049 and Genefer 2.2.1
Copyright (C) 2001-2003, Yves Gallot (v1.3)
Copyright (C) 2009-2011, Mark Rodenkirch, David Underbakke (v2.2.1)
Copyright (C) 2010-2012, Shoichiro Yamada (CUDA)
Portions of this software written by Michael Goetz 2011-2012 (BOINC)
A program for finding large probable generalized Fermat primes.
Command line: projects/www.primegrid.com/primegrid_genefer_1.06_windows_intelx86__cuda32_13.exe -boinc -q hidden --device 0
Priority change succeeded.
GPU=GeForce GTX 560
Global memory=1073741824 Shared memory/block=49152 Registers/block=32768 Warp size=32
Max threads/block=1024
Max thread dim=1024 1024 64
Max grid=65535 65535 65535
CC=2.1
Clock=2073 MHz
# of MP=7
No project preference specified; using SHIFT=8
maxErr exceeded during initialization at 65536, 0.5000 > 0.4500
14:46:32 (2984): called boinc_finish
</stderr_txt>
]]>
this another one:
<core_client_version>6.12.34</core_client_version>
<![CDATA[
<message>
- exit code 1038 (0x40e)
</message>
<stderr_txt>
GeneferCUDA-boinc 1.06 (CUDA3.2) based on GeneferCUDA 1.049 and Genefer 2.2.1
Copyright (C) 2001-2003, Yves Gallot (v1.3)
Copyright (C) 2009-2011, Mark Rodenkirch, David Underbakke (v2.2.1)
Copyright (C) 2010-2012, Shoichiro Yamada (CUDA)
Portions of this software written by Michael Goetz 2011-2012 (BOINC)
A program for finding large probable generalized Fermat primes.
Command line: projects/www.primegrid.com/primegrid_genefer_1.06_windows_intelx86__cuda32_13.exe -boinc -q hidden --device 0
Priority change succeeded.
GeneferCUDA-boinc.cu(107) : cudaSafeCall() Runtime API error : no CUDA-capable device is detected.
11:09:55 (4092): called boinc_finish
</stderr_txt>
]]>
any idea ??
Tks .. parabol
____________
I'm a prime millionaire !
9*2^3497442+1 |
|
|
|
|
GeneferCUDA-boinc.cu(107) : cudaSafeCall() Runtime API error : no CUDA-capable device is detected.
But this looks like my vault with the newest nvidia drivers and monitor sleeping issue.
Regards Odi
____________
 |
|
|
|
|
|
Rolled back to previous driver for the Graphic-Card.
Monitor sleep is not engaged.
Could run GFN WU some day's ago successfully..
Also PPS-Sieve , CW-Sieve working fine with my present settings..
Looking foreward
tks .. parabol
____________
I'm a prime millionaire !
9*2^3497442+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
                          
|
GeneferCUDA-boinc.cu(107) : cudaSafeCall() Runtime API error : no CUDA-capable device is detected.
That's either the driver/sleep problem, or some other user-controllable situation such as using Windows Remote Desktop.
Priority change succeeded.
GPU=GeForce GTX 560
Global memory=1073741824 Shared memory/block=49152 Registers/block=32768 Warp size=32
Max threads/block=1024
Max thread dim=1024 1024 64
Max grid=65535 65535 65535
CC=2.1
Clock=2073 MHz
# of MP=7
No project preference specified; using SHIFT=8
maxErr exceeded during initialization at 65536, 0.5000 > 0.4500
That could be a couple of things. You're running above 2 GHz, so of course the first thing I'm going to suggest is that you lower the clock rates to reference stock speeds and see if the problem goes away.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
                                   
|
|
Curious to check WR task but uff...what should I add to app_info.xml?
25/02/2012 16:08:14 | PrimeGrid | Message from server: Your app_info.xml file doesn't have a usable version of Genefer (World Record).
25/02/2012 16:08:14 | PrimeGrid | Message from server: No work available for the applications you have selected. Please check your project preferences on the web site.
I would like to continue using app_info.xml because of AVX LLR x64 for CPU.
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Curious to check WR task but uff...what should I add to app_info.xml?
Add this to your app_info file:
<app>
<name>genefer_wr</name>
<user_friendly_name>Genefer (World Record)</user_friendly_name>
</app>
<app_version>
<app_name>genefer_wr</app_name>
<version_num>107</version_num>
<api_version>6.11.7</api_version>
<file_ref> <file_name>geneferCUDA-boinc-windows.exe</file_name> <main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_32_16.dll</file_name>
<open_name>cudart32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<file_ref>
<file_name>cufft32_32_16.dll</file_name>
<open_name>cufft32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<platform>windows_intelx86</platform>
<plan_class>cuda32_13</plan_class>
<avg_ncpus>0.286562</avg_ncpus>
<max_ncpus>0.286562</max_ncpus>
<flops>427599790948.961853</flops>
<coproc>
<type>CUDA</type>
<count>1.000000</count>
</coproc>
<gpu_ram>536870912.000000</gpu_ram>
</app_version>
Change the executable filename to whatever you're using for the regular GFN WUs.
You'll also need appropriate <file_info> sections in app_info, but if you already are running the regular GFN you should already have that.
That works for Windows. Linux would be slightly different.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
Add this to your app_info file:
<name>genefer_wr</name>
<user_friendly_name>Genefer (World Record)</user_friendly_name>
Thanks, that's what I was looking for.
Will see if it works...
____________
My stats |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
|
Genefer_WR up and running (498^4194304+1)
BOINC Estimated time 312 hours, ~13 days.
My estimated time is half of that, let's see in a week.
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Genefer_WR up and running (498^4194304+1)
BOINC Estimated time 312 hours, ~13 days.
My estimated time is half of that, let's see in a week.
Your current WU would take 172 hours (about 7 days) on a stock GTX 460.
BTW, if anyone wants to know how to accurately predict the run times, use the following method.
First, get the speed of your GPU. (This won't work under Linux, sorry -- the benchmarks are still borked in the land of the penguin.)
In the description below, replace GeneferCUDA.exe with the name of your GeneferCUDA executable.
First, shut down BOINC and any other CUDA programs you might be running.
Now, run the following from a DOS window after changing the current working directory to ...\BOINC\projects\www.primegrid.com\
GeneferCUDA.exe -b
After it's done, find the line listing the benchmark speed at N=4194304. For my 460, the speed is 16.5 ms.
Convert that number into seconds: to convert milliseconds to seconds, divide by 1000. So my speed is 0.0165. Call this speed X.
Now plug that speed into this formula
T = X * ((N * LOG(B) / LOG(2)) + 1)
N and B are the numbers from the GFN (B^N+1), so N will be 4194304 and in Honza's example B is 498. The result, T, is the estimated time in seconds. This formula should be very accurate as long as nothing else on the computer is slowing down the GPU. In my experience, this formula generally predicts the actual run time to within about 1/2 of one percent.
Those of you who have followed this so far and went to try this probably have realized that you don't know what B is for your WU. Go to your BOINC directory and open up the sched_reply_www.primegrid.com.xml file in a text editor. Look for the section describing the GFN-WR workunit (there's one or more sections called <workunit>) and within that section there's a line marked <command_line>. You'll see the B value there. There are likely to be multiple <workunit> sections in that file; one for each WU that PrimeGrid has sent to your computer.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I have one running on a I7 970 with GTX570 Win7
30hr 18 min = 45%
Lennart
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
I have one running on a I7 970 with GTX570 Win7
30hr 18 min = 45%
Lennart
The b value is a pretty low, right? At b=12, run time on my machine is only about 72 hours, but it climbs rapidly as b goes up in the beginning. By the time b is in the 300 range the duration's already up to 160 hours. By b=1250, it's about 190 hours.
____________
My lucky number is 75898524288+1 |
|
|
|
|
I have one running on a I7 970 with GTX570 Win7
30hr 18 min = 45%
Lennart
The b value is a pretty low, right? At b=12, run time on my machine is only about 72 hours, but it climbs rapidly as b goes up in the beginning. By the time b is in the 300 range the duration's already up to 160 hours. By b=1250, it's about 190 hours.
Yes it is low but higher then 12 :)
164^4194304 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Yes it is low but higher then 12 :)
164^4194304
141 hours on my machine vs. about 65 on yours. I'm jealous!
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
GTX 580, 2.6% done in 1h31min, so around 58 hours to complete. |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
T = X * ((N * LOG(B) / LOG(2)) + 1)
It gives ~72 hours.
So far 24.5% after 17 hours, which is pretty accurate.
From my WU, other 4 tasks errored out, one was "Aborted by user" (GTX 570) and 7th instance is my wingman with GTX 460. Host of my wingman is pretty stable so hopefully result will be validated in reasonable timeframe.
Lennart has similar, Michael too. We would need 5-10 instances just to properly start Genefer_WR on two host.
Pretty much what I expected.
Anybody would like to guess when first WU gets validated?
[and what credit it gets :-) ]
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
T = X * ((N * LOG(B) / LOG(2)) + 1)
It gives ~72 hours.
So far 24.5% after 17 hours, which is pretty accurate.
I found that with the 262s it was usually accurate to within a few seconds of the actual time. Never got one that was perfect to the second, however. I tracked about 100 WUs.
(By "262" I mean=18 or N=262144. I like calling them 262s, so thanks to whomever thought of that first! All these 6 and 7 digit numbers are beginning to get tiresome.)
Lennart has similar, Michael too. We would need 5-10 instances just to properly start Genefer_WR on two host.
Pretty much what I expected.
With the 295 driver fiasco, that's going to be very common among all BOINC CUDA projects.
Anybody would like to guess when first WU gets validated?
[and what credit it gets :-) ]
I've also been wondering about the same two questions. In theory, you might start seeing the first completed WUs already. If the WUs with the lowest 'b' values went to GTX 580 hosts, those could of completed as quickly as a day and a half. But for that to happen so quickly, all the stars have to align just right:
1) The b value needs to be very low (one of the first 10 or so WUs).
2) It needs to go to a fast GPU, either a 570 or 580, or similar.
3) The computer needs to not be affected by the 295 driver bug.
4) The computer's cache needs to be small enough so the WU started running promptly.
5) The GPU's overclocking didn't cause an error.
6) The wingman doesn't go MIA causing a 2-week deadline timeout.
Probably in the next 2 or 3 days the first ones will be returned and validated. Whether we'll find out about it on the forums is anybody's guess.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Would have loved to test some long units, unfortunately my computer is still RMA...
But my time will come before we are out of units ;)
____________
|
|
|
|
|
|
164^4194304+1 is composite. (RES=906c784d49736983) (9289729 digits) (err = 0.0000) (time = 67:20:25)
My first one.
I7970 3.2Ghz 12MB ram GTX570
Lennart |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
164^4194304+1 is composite. (RES=906c784d49736983) (9289729 digits) (err = 0.0000) (time = 67:20:25)
My first one.
I7970 3.2Ghz 12MB ram GTX570
Lennart
I wonder if that's the first one returned so far?
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
http://www.primegrid.com/workunit.php?wuid=253512586
It is not mine, but has two successful reports. Is it the first?
____________
676754^262144+1 is prime |
|
|
|
|
It is not mine, but has two successful reports.
so what is it waiting for? |
|
|
|
|
It is not mine, but has two successful reports.
so what is it waiting for?
nothing now: 125,600.69 credits. Wow
____________
676754^262144+1 is prime |
|
|
|
|
It is not mine, but has two successful reports.
so what is it waiting for?
nothing now: 125,600.69 credits. Wow
Just making sure, the 125,600.69 is credit for a world record wu and took you how long to run? |
|
|
|
|
It is not mine, but has two successful reports.
so what is it waiting for?
nothing now: 125,600.69 credits. Wow
Just making sure, the 125,600.69 is credit for a world record wu and took you how long to run?
It is not mine, as said before (I have no card to run that fast). Both crunchers took a little over 150000 seconds, on a GTX 570
http://www.primegrid.com/workunit.php?wuid=253512586
It was one of the smaller b's available (24). I expect the next ones to take longer to finish.
(edit) apparently, there's no autonomous badge for world record gfn (yet?) |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
Just making sure, the 125,600.69 is credit for a world record wu and took you how long to run?
Around 150k secs on GTX 570.
(262s are about 3000s and 524s are 9500s)
In general, it's in line with 524s WUs...but note extremely low b value.
____________
My stats |
|
|
JohnHonorary cruncher
Send message
Joined: 21 Feb 06
Posts: 2875
ID: 2449
Credit: 2,681,934
RAC: 0
                
|
|
REMINDER: World Record territory does not start until b>=1248.
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Just making sure, the 125,600.69 is credit for a world record wu and took you how long to run?
Around 150k secs on GTX 570.
(262s are about 3000s and 524s are 9500s)
In general, it's in line with 524s WUs...but note extremely low b value.
Note that such a low B value significantly reduces the complexity of that calculation.
Using my computer (GTX 460) as a benchmark, you get these numbers:
262s with b around 700K @3600 credits = 2400 cr/hr
524s with b around 110K @8000 credits = 1655 cr/hr
24^4194304+1 @ 125,600.69 credit = 1425 cr/hr
I'm not making any comment on whether the numbers are too high or too low, but I wanted to give you normalized numbers so you're comparing apples to apples.
The GTX 570 GPUs that did this particular WU are slightly better than twice as fast as miine, so their credit per hour numbers would be twice as high as the numbers listed above.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
REMINDER: World Record territory does not start until b>=1248.
1248 is composite, unless my GPU spit out the wrong result. Actually, 1248 was also sieved out, so it's definitely composite.
Here's some fun stats for you...
b=12 would place 9th in the all time list.
b=18 is over 5 million digits long
b=28 is over 6 million digits long
b=34 is good for 8th place
b=52 is over 7 million digits long
b=60 is good for 7th place
b=74 is good for 6th place
b=88 is over 8 million digits long
b=140 is over 9 million digits long
b=160 is good for 5th place
b=220 is good for 4th place
b=244 is over 10 million digits long
b=424 is over 11 million digits long
b=470 is good for 3rd place
b=730 is over 12 million digits long
b=1152 is good for 2nd place
b=1258 is over 13 million digits long
I'm pretty sure WUs in at least the 400s have been sent out already, so any primes we find at the leading edge are going to be really close to the top of the list.
It's possible some of the shorter WUs could finish in time to definitively grab the green jersey. :)
____________
My lucky number is 75898524288+1 |
|
|
JohnHonorary cruncher
Send message
Joined: 21 Feb 06
Posts: 2875
ID: 2449
Credit: 2,681,934
RAC: 0
|
It's possible some of the shorter WUs could finish in time to definitively grab the green jersey. :)
Even a prime at 524k would take the green jersey. ;)
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
It's possible some of the shorter WUs could finish in time to definitively grab the green jersey. :)
Even a prime at 524k would take the green jersey. ;)
Indeed, and if it doesn't a prime at 262K will, unless we also find an SoB prime, or something equally humongous.
Looks like my crystal ball is working just fine:
There is a reason to stay at n=18, however: with all the GPU power available on the Boinc side, there's a possibility for finding some nice primes during the Tour de Primes. The winner of the green jersey this year, in my opinion, will probably be someone using a GPU crunching GFN at n=18.
____________
My lucky number is 75898524288+1 |
|
|
|
|
GTX 580, 2.6% done in 1h31min, so around 58 hours to complete.
ended up taking 61 hours to determine 384^4194304+1 is composite.
|
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
Genefer_WR up and running (498^4194304+1)
This one was finished in 70 hours on GTX 580.
____________
My stats |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
|
As b is going up, mid-range GPUs are having trouble finishing task in deadline.
For example GTX 275 - http://www.primegrid.com/result.php?resultid=355341213
Deadline is only 5 days.
I think we need to extend deadline...better GPUs may have troubles finishing in time even in high-priority mode.
It might be good to suggest some minimal requirements for participating in GFN WR effort - CUDA capable is not enough.
____________
My stats |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
As b is going up, mid-range GPUs are having trouble finishing task in deadline.
For example GTX 275 - http://www.primegrid.com/result.php?resultid=355341213
Deadline is only 5 days.
I think we need to extend deadline...better GPUs may have troubles finishing in time even in high-priority mode.
It might be good to suggest some minimal requirements for participating in GFN WR effort - CUDA capable is not enough.
The deadline for WR should be 14 days. (This is the first WR WU I've seen with a 5 day deadline.) That's clearly a mistake. Nothing short of a 570 makes that kind of a deadline unless the card is glowing red hot from the overclocking!
I'll make sure they know about it. Thanks for pointing it out!
____________
My lucky number is 75898524288+1 |
|
|
|
|
The deadline for WR should be 14 days. (This is the first WR WU I've seen with a 5 day deadline.) That's clearly a mistake. Nothing short of a 570 makes that kind of a deadline unless the card is glowing red hot from the overclocking!
I'll make sure they know about it. Thanks for pointing it out!
Just a simple question: with llr tasks, reporting after the deadline will not prevent the server from accepting the WU (an granting it credit), if it is valid. The only side effect would be the release of the same WU to another user after time-out.
However, I think I read somewhere that boinc (or Genefercuda) would abort a task if it was running for longer than some pre-defined period of time.
If I'm not mistaken, what is that period of time in GFN tasks (both WR and n=19)? |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3250
ID: 50683
Credit: 152,646,050
RAC: 10,054
|
|
Yes, I would ask same question: for genefercuda 262144, on PRPNet, what is deadline ( 1-2-3 days)?
____________
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! |
|
|
|
|
Yes, I would ask same question: for genefercuda 262144, on PRPNet, what is deadline ( 1-2-3 days)?
I know the answer to that :)
you can see how long you have to report your tasks here:
http://prpnet.mine.nu:11002/pending_tests.html
Total time there are 168 hours (7 days). |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
However, I think I read somewhere that boinc (or Genefercuda) would abort a task if it was running for longer than some pre-defined period of time.
If I'm not mistaken, what is that period of time in GFN tasks (both WR and n=19)?
That's got nothing to do with Genefer or LLR. And your description is a little bit inaccurate: There is a limit, but the limit specifies the number of GLFOPS in the calculations, not a specific amount of time.
That's a BOINC feature, and its purpose is to prevent an infinite loop in a program from causing a WU to run forever and never complete.
Each BOINC WU has a setting that says "This is the length of the WU" and another setting that says "This is the absolute maximum amount that the WU is allowed to run."
That second setting is there to prevent a WU from running forever, and should be set very high.
Both numbers are set in GLFOPs, so their operation is dependant on (for CPUs) the BOINC benchmarks working more or less accurately. On GPUs I'm not 100% sure how those work.
This setting has nothing to do with deadlines. Unless either 1) There's a bug in the Genefer software that causes it to go into an infinite loop and never finish, or 2) The WUs are set up incorrectly (that's what appears to have happened with PPS Sieve), nobody should ever run into this problem. It doesn't matter how fast or slow your computer is.
A slow computer still has to worry about the result deadline, but the WU GFLOP limit should never be a concern.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Thanks Michael,
I'm glad I was mistaken. I will try to run WR WU's on a 550. The risk of errors is high (specially on that card) and I've noticed than runtimes are getting higher as b goes up. I only wanted to be sure that gpu work would no be lost due to running times being too long (I'm expecting almost a week per WU).
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Thanks Michael,
I'm glad I was mistaken. I will try to run WR WU's on a 550. The risk of errors is high (specially on that card) and I've noticed than runtimes are getting higher as b goes up. I only wanted to be sure that gpu work would no be lost due to running times being too long (I'm expecting almost a week per WU).
A week sounds about right.
That PPS Sieve error is unusual. I wouldn't worry about it too much. Besides, you can check that it's set up correctly if you want to do a little digging. If you look in the client_state.xml file, you'll see the settings. The maximum limit is set to about 15 times what the estimate is -- and the estimate should be based on my formula, so it should be very close to the actual number. So to exceed that limit, you would need to be crunching for about 3 or 4 months. I think you will manually abort the WU long before the BOINC client does!
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I'm running with app_info.xml and have been running the smaller (524288) units successfully. Can someone tell me what I need to change if I add an additional entry to the app_info.xml for the "world record" tasks? I took a stab at it several days ago and wound up with a few units that "timed out - no response" in a ridiculously short time (under a minute after being issued) so I bailed back to the shorter units, which continued to run fine. If it matters, this is on a 570 which normally runs the shorter units in about 3h20m. I'm running Linux.
If this has already been answered elsewhere, a pointer to that thread would be appreciated. Thanks!
--Gary
____________
"I am he as you are he as you are me and we are all together"
87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit) |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
I'm running with app_info.xml and have been running the smaller (524288) units successfully. Can someone tell me what I need to change if I add an additional entry to the app_info.xml for the "world record" tasks? I took a stab at it several days ago and wound up with a few units that "timed out - no response" in a ridiculously short time (under a minute after being issued) so I bailed back to the shorter units, which continued to run fine. If it matters, this is on a 570 which normally runs the shorter units in about 3h20m. I'm running Linux.
If this has already been answered elsewhere, a pointer to that thread would be appreciated. Thanks!
--Gary
I've seen some of those crazy timeouts looking at wingmen. I don't think it was a problem on your side -- I'm guessing it was a bad WU configuration on the server. I don't think there's any way to cause that problem with app_info.
So it's probably safe to try the long WUs. Just be aware that they are, indeed, long. I asked the admins to up the timeout to 3 weeks instead of 2 because for some of the slower GPUs 2 weeks would be cutting it very close. I'm not even talking about the really slow GPUs. Just the low-midrange GPUs. The entry level GPUs can't play in this sandbox at all.
Anyway, here's what I've got in my app_info for the two GFN projects. This is under Windows, and includes only the info for these two projects:
<app_info>
<app>
<name>genefer</name>
<user_friendly_name>Genefer</user_friendly_name>
</app>
<app>
<name>genefer_wr</name>
<user_friendly_name>Genefer (World Record)</user_friendly_name>
</app>
<file_info>
<name>geneferCUDA-boinc-windows.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart32_32_16.dll</name>
<file_signature>
6f6c6846e06f08954c5d3744c8b3e206901e7d6cada0f98bc4736d89b82ebcf3
46a34061b44aafecc7daf6b21245da1a0b9116084f154409acd86db5b746aa51
cea02569028b1e61ef85602c7ed27cb7676cdc0db7685626209e6a40e78dbccf
a8a40f78cec19d9904ffd2d2b3581ab5931f06fd2d4c734bfc5a9fa271f6149a
.
</file_signature>
<nbytes>384616.000000</nbytes>
</file_info>
<file_info>
<name>cufft32_32_16.dll</name>
<file_signature>
0f510cac435e4772ff757cc92ebc1453cf1721a933164ee79eae3428c4a736bb
30fb39da86a8973e8064619dff31e0f4ef3245501b75fab4659de8e8cef58653
8c4bad39e15399b2d6a5bd2d92495590a9836ec614828c7413b1771ee54763b7
e8a71396a813c783280b6e34872202877c788b110bcd24b19720144195c97a69
.
</file_signature>
<nbytes>28551272.000000</nbytes>
</file_info>
<app_version>
<app_name>genefer</app_name>
<version_num>107</version_num>
<api_version>6.11.7</api_version>
<file_ref>
<file_name>geneferCUDA-boinc-windows.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_32_16.dll</file_name>
<open_name>cudart32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<file_ref>
<file_name>cufft32_32_16.dll</file_name>
<open_name>cufft32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<platform>windows_intelx86</platform>
<plan_class>cuda32_13</plan_class>
<avg_ncpus>0.215427</avg_ncpus>
<max_ncpus>0.215427</max_ncpus>
<flops>470235051047.497681</flops>
<coproc>
<type>CUDA</type>
<count>1.000000</count>
</coproc>
<gpu_ram>536870912.000000</gpu_ram>
</app_version>
<app_version>
<app_name>genefer_wr</app_name>
<version_num>107</version_num>
<api_version>6.11.7</api_version>
<file_ref>
<file_name>geneferCUDA-boinc-windows.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_32_16.dll</file_name>
<open_name>cudart32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<file_ref>
<file_name>cufft32_32_16.dll</file_name>
<open_name>cufft32_32_16.dll</open_name>
<copy_file/>
</file_ref>
<platform>windows_intelx86</platform>
<plan_class>cuda32_13</plan_class>
<avg_ncpus>0.286562</avg_ncpus>
<max_ncpus>0.286562</max_ncpus>
<flops>427599790948.961853</flops>
<coproc>
<type>CUDA</type>
<count>1.000000</count>
</coproc>
<gpu_ram>536870912.000000</gpu_ram>
</app_version>
</app_info>
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Thanks MG. It looks like you were right, my app_info seems correct (based on your content) so the WUs from a week ago must have been no good. I'm off and running now with a WU which looks like it will take about 86 hours to complete.
--Gary |
|
|
|
|
|
I too have one that won't make the deadline albeit my GPU is crunching like hell:
click
Sad thing... :( |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
I too have one that won't make the deadline albeit my GPU is crunching like hell:
click
Sad thing... :(
They have changed ALL older world record WUs to have 15 day deadlines, but this only affects resends. So yours is still going to miss the deadline.
However, you'll probably still be the first one to return a result.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I don't know, i am only at 69.x % by now, need two more days i do think. |
|
|
|
|
|
Pretty tight a 15 day deadline.
I have a GTX275 crunching a WR unit now and it will take 10.5 days.
So that means I have a 4 day margin.
Since this card is about the weakest you can have for these task I can understand the deadline is 15 days, although people with a GTX260 will have a hard time returning it before the deadline.
Edit: by the way I see now that the deadline has been increased to 21 days?
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Pretty tight a 15 day deadline.
I have a GTX275 crunching a WR unit now and it will take 10.5 days.
So that means I have a 4 day margin.
Since this card is about the weakest you can have for these task I can understand the deadline is 15 days, although people with a GTX260 will have a hard time returning it before the deadline.
Edit: by the way I see now that the deadline has been increased to 21 days?
WU size is increasing. New WUs have a deadline of 21 days. The deadlines on the older WUs were increased from 5 days to 15 days.
I estimate that a GTX 260 could do current WUs in about 16 days. Except for some really dismal entry level 400 series GPUs, the 260 is the slowest double precision GPU, so for now 21 days should be fine.
WU size will eventually double, but it's going to be increasing at a slower rate now. Sometime in the next 3 to 12 months we'll probably need to increase the deadline again.
At this point, I wouldn't worry too much about missing a deadline. As long as the WU has been started, the BOINC client shouldn't automatically kill it, and as long as you return it with the correct result before the WU is purged from the DB you'll get credit. With the high error rates (295 driver bug, overclocking, etc.) it's unlikely you'll have two valid results returned before you get yours back to the server, let alone also having the WU age enough to get purged. Being a few days late shouldn't matter.
____________
My lucky number is 75898524288+1 |
|
|
|
|
At this point, I wouldn't worry too much about missing a deadline. As long as the WU has been started, the BOINC client shouldn't automatically kill it, and as long as you return it with the correct result before the WU is purged from the DB you'll get credit...
So deadlines are only useful for hosts that haven't started processing WUs. Like hosts with enormous caches or are using older technologies?
My main host can't calculate the run time of WUs with any degree of accuracy anyway. BOINC Manager thinks it will take a PPSSieveCUDA 5hours51mins to complete and it will actually take c. 20mins. For Woodall LLRs it's guess is over 124hours and will actually take it c. 24-25hours (thanks to AVXLLR).
I've been processing these types of WUs for sometime, you would have thought the estimates would get better :(
My other host is crunching genefer (small), it's currently has one in progress - 1hour10mins in and completed 44%, BOINC Manager says it has another 5hours40 to go, very insightful!
Peter
____________
35 x 2^3587843+1 is prime! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
So deadlines are only useful for hosts that haven't started processing WUs.
Yes, if by "useful" you mean that BOINC will abort the task. BOINC won't abort a WU you've already started crunching. That wouldn't be good for either volunteers or for projects.
However, it's not a good idea to intentionally miss deadlines if you can avoid it. There's two undesirable consequences to missing a deadline:
1) The server sends out a replacement task to another computer. Missing the deadline therefore causes extra resources to be consumed, thus slowing down the overall project.
2) If you end up missing the deadline by a substantial amount, the WU may get purged from the database and you won't get any credit.
____________
My lucky number is 75898524288+1 |
|
|
|
|
I don't know, i am only at 69.x % by now, need two more days i do think.
82.16 % by now, flaged as "time exceeded"... |
|
|
|
|
So deadlines are only useful for hosts that haven't started processing WUs.
Yes, if by "useful" you mean that BOINC will abort the task. BOINC won't abort a WU you've already started crunching. That wouldn't be good for either volunteers or for projects.
However, it's not a good idea to intentionally miss deadlines if you can avoid it. There's two undesirable consequences to missing a deadline:
1) The server sends out a replacement task to another computer. Missing the deadline therefore causes extra resources to be consumed, thus slowing down the overall project.
2) If you end up missing the deadline by a substantial amount, the WU may get purged from the database and you won't get any credit.
Out of interest, what happens in scenario 1 when the result is returned after the deadline but before the extra host starts crunching? Can BOINC send an abort signal in such a case or will the extra unit still be crunched?
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
1) The server sends out a replacement task to another computer. Missing the deadline therefore causes extra resources to be consumed, thus slowing down the overall project.
Out of interest, what happens in scenario 1 when the result is returned after the deadline but before the extra host starts crunching? Can BOINC send an abort signal in such a case or will the extra unit still be crunched?
Unfortunately, no. One reason is the BOINC server can't ever send anything unsolicited to the client. The server can only give information to the client when the client contacts the server. In order for your suggestion to work, the client would need to contact the server again before it started crunching that WU.
But even if it does, I don't *think* the BOINC server is smart enough to ever do that, although I'm not 100% certain of that. I don't see any reason why it couldn't do that, however. At least in theory.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1963
ID: 352
Credit: 6,420,431,564
RAC: 2,590,392
|
But even if it does, I don't *think* the BOINC server is smart enough to ever do that, although I'm not 100% certain of that. I don't see any reason why it couldn't do that, however. At least in theory.
We were using this on CPDN couple years back - a killer trickle.
(CPDN task are long so there is a communication with server during task computation, some data are send from client to server and a killer trickle can be send down toward client to kill ill-behaved climate model...or wrong generated WU for example).
____________
My stats |
|
|
|
|
|
The challenge grabbed my attention. I assigned my nvidia rigs to world record wus and it seems a GTX 580 Lightning at stock clocks (832Mhz) and with no other project running will complete the wu around 70 hours. Probably, the electricity will go down just because i said this:)
Just to inform future participants.
BTW, amd gpus have theoretically higher double precision. It was 1/5 ratio of single in 58xx series where it's 1/8 in fermi (1/2 in tesla fermi). Is there any development or any intention to port it into amd gpus? All I know about coding is that amd sdk is.... let's say more challenging:) |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Probably, the electricity will go down just because i said this:)
I live in an area with overhead power lines. Every time a squirrel gets too curious or there's enough snow and wind, the power goes out for a second or two. That's inevitably enough to cause computers and other things to reboot.
I've got 6 different UPSs in the house to keep all the computers and other electronics running through those momentary glitches. They're inexpensive and let you relax and not worry about the power going out after your crunching gets to 99.5% complete. :)
If the loss of power is longer than a few minutes, the computers shut themselves down cleanly while on battery power from the UPS. That preserves the work in progress.
EDIT: And in a REALLY long blackout, those UPSs can be used to keep your cell phones charged for a long, long time.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Last time i looked into ATI it sucked, the approach of Nvidia to develop apps is way better.
And only AMD 79xx seem to have superior DP-power, a AMD 7770 has 80 GFLOPS DP, a Nvidia 560 has around 90 GFLOPS DP. (1/12th of 1089 GFLOPS SP). |
|
|
|
|
|
So, new Tesla cards should rock in GFN? I saw some tesla gpu card ( don't know what model it was ) but the computation time wasn't impressive. Maybe it was some older model. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
So, new Tesla cards should rock in GFN? I saw some tesla gpu card ( don't know what model it was ) but the computation time wasn't impressive. Maybe it was some older model.
If you're thinking of the same results I saw, that was the newest, biggest, baddest model and the results were mediocre, at best.
Unfortunately, I don't have any information on if there were extenuating circumstances that made the performance so poor.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I think Intel should release Knights Corner for the end-user. ;) |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
The challenge grabbed my attention. I assigned my nvidia rigs to world record wus and it seems a GTX 580 Lightning at stock clocks (832Mhz) and with no other project running will complete the wu around 70 hours. Probably, the electricity will go down just because i said this:)
No electricity outage, but your card is overclocked (probably factory overclocked, but that's still overclocked). Stock graphics clock speed is 772 MHz on a 580. That WU failed in a little under a day with an error that is typical for overclocked GPUs.
GeneferCUDA is very sensitive to overclocking.
____________
My lucky number is 75898524288+1 |
|
|
|
|
The challenge grabbed my attention. I assigned my nvidia rigs to world record wus and it seems a GTX 580 Lightning at stock clocks (832Mhz) and with no other project running will complete the wu around 70 hours. Probably, the electricity will go down just because i said this:)
No electricity outage, but your card is overclocked (probably factory overclocked, but that's still overclocked). Stock graphics clock speed is 772 MHz on a 580. That WU failed in a little under a day with an error that is typical for overclocked GPUs.
GeneferCUDA is very sensitive to overclocking.
That error was due to my fault of increasing the core to 900 Mhz last night to see the change in speed (stable oc in folding). After checking, all my errors appeared at 1800 shader clock and no error while running 832. Can't believe i realize this now:) I reverted to default. |
|
|
|
|
|
Yeah i did it! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Yeah i did it!
Nobody but you can see that link.
I assume you mean this WU.
I told you that you would probably be the first. :)
Okay, one down, 110,348 to go. ;)
____________
My lucky number is 75898524288+1 |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3257
ID: 130544
Credit: 2,460,866,079
RAC: 4,328,950
                  
|
|
FYI I have a bundle of these long tasks - estimating 30% after a day so. GTX580s & no overclocking. 295.51 driver but no monitor sleep. We'll have to see how it goes. |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3257
ID: 130544
Credit: 2,460,866,079
RAC: 4,328,950
|
|
I have just checked my stderr.txts for the _16s & they both contain "testing n^4193304+1" & "terminating because BOINC client said we should quit". Jobs too big for the card therefore? When this occurred BOINC jumped onto 2 other Genefer long tasks (1 WR). |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
I have just checked my stderr.txts for the _16s & they both contain "testing n^4193304+1" & "terminating because BOINC client said we should quit". Jobs too big for the card therefore? When this occurred BOINC jumped onto 2 other Genefer long tasks (1 WR).
That means exactly what it sounds like -- for some reason the BOINC client commanded GeneferCUDA to stop.
Maybe there's something in the BOINC log that explains why the client did that.
____________
My lucky number is 75898524288+1 |
|
|
|
|
When this occurred BOINC jumped onto 2 other Genefer long tasks (1 WR).
If you have more cuda tasks than cards then most likely boinc decided that you couldn't finish one of them in time and switched it to high priority mode. |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3257
ID: 130544
Credit: 2,460,866,079
RAC: 4,328,950
|
|
Update / further info: stderr states:
"maxErr during b^N initialisation 0.0000
Testing b^4194304+1...
Terminating because BOINC requested that it should do so".
Then it stopped after 24 hours 30%. Same for the other_16 unit. Will they continue?
There is a WR & non-Wr in progress now & both appear without error so far at >50% through. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Update / further info: stderr states:
"maxErr during b^N initialisation 0.0000
Testing b^4194304+1...
Terminating because BOINC requested that it should do so".
Then it stopped after 24 hours 30%. Same for the other_16 unit. Will they continue?
There is a WR & non-Wr in progress now & both appear without error so far at >50% through.
You'll need to look into the BOINC client log on your computer (not the output from Genefer) in order to find out why BOINC is telling Genefer to quit. This is the log you can see by hitting SHIFT-CTRL-E in the BOINC client.
Providing links to the Results in question and a copy of the relevant portions of your BOINC log (the part surrounding where BOINC stopped Genefer) would be helpful.
____________
My lucky number is 75898524288+1 |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3257
ID: 130544
Credit: 2,460,866,079
RAC: 4,328,950
|
|
Well here's one but it's still just in progress:
http://www.primegrid.com/result.php?resultid=356635014
Client log just says it restarted another unit. Case of "nothing to see here" (yet). Probably just automatic scheduling. |
|
|
|
|
|
Got this one ready
http://www.primegrid.com/result.php?resultid=355628230
A bit low credit for four days of crunching. :P |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Got this one ready
http://www.primegrid.com/result.php?resultid=355628230
A bit low credit for four days of crunching. :P
The amount of credit that was granted for that WU was the "correct" amount, meaning that it's not an error.
That's the rate at which credit is being handed out. If you think the rate is too low, Rytis (and maybe Lennart) are the people who set that rate, so I suggest presenting them with a valid rationale for why it's too low. Facts with numbers describing how other projects are giving out more credit is probably the strategy most likely to be successful.
It's a safe bet they *want* people to be crunching here and they want people to be happy. They need to keep credit in line with other projects, otherwise a senseless and utterly meaningless credit war will occur. So if you can demonstrate that we need to be handing out more credit based on what other projects are doing, you may be able to convince them.
Unfortunately, the argument "But that other PG project hands out more credit" is just as likely to get the credit on the other project lowered as it is to get Genefer credit raised. The better comparison is between PrimeGrid and other BOINC projects.
Personally, I spent a week or two trying to come up with a "correct" amount of credit. I was successful. Multiple times, in fact, with wildly different answers that varied by at least fourfold. In the end, I came to the conclusion that the official definitions of what credit should be are almost useless, and adjusting credit to best achieve the goal of being "project neutral" -- meaning all other things being equal, you get the same amount of credit no matter which project you crunch -- was the best approach to setting credit.
That's just my opinion and I have no idea if anyone else on Earth agrees.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Seems to me that most folks tend to compare the 2 gpu sieve credit output to this. Just my opinion but it looks like it's a time/credit effort that most people wonder about.
Lets say I run just gcw sieves for 4 days. The accumulated credit for those 4 days would be somewhere around 1.3m on the 570. If as was mentioned I run a genefer for 4 days and get 120k+ credit then it "appears" that credit is very out of whack. I haven't run an SOB in a long time but, those took my 7+ days and I got 10k of credit. Not sure I've ever seen anyone complain on those. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Seems to me that most folks tend to compare the 2 gpu sieve credit output to this. Just my opinion but it looks like it's a time/credit effort that most people wonder about.
Lets say I run just gcw sieves for 4 days. The accumulated credit for those 4 days would be somewhere around 1.3m on the 570. If as was mentioned I run a genefer for 4 days and get 120k+ credit then it "appears" that credit is very out of whack. I haven't run an SOB in a long time but, those took my 7+ days and I got 10k of credit. Not sure I've ever seen anyone complain on those.
That's exactly the comparison you don't want to be making for the reason I stated. If the sieves give more credit than Genefer, and Genefer is producing the right amount of credit, then what should happen?
____________
My lucky number is 75898524288+1 |
|
|
|
|
If the sieves give more credit than Genefer, and Genefer is producing the right amount of credit, then what should happen?
but imagine the backlish given the amount of whinging when PPS credit was lowered to its current level. |
|
|
|
|
|
LLR vs SIEVE is about 1:2 on cpu.
Why not make some similarly in gpu? My 570 give ~300k in PPSs, so minimum point should be 150k for gfn. |
|
|
|
|
That's exactly the comparison you don't want to be making for the reason I stated. If the sieves give more credit than Genefer, and Genefer is producing the right amount of credit, then what should happen?
I'M not making the comparison. Just stating that it seems to me that's what most folks seem to be doing. It's just human nature to say "ok i'm getting this for this amount of time on this project so any other project I do should get equal or near equal output".
But I was just saying that what I was reading.
I would say that if genefer had started out as a cpu only project and then moved to gpu after an extended period of time I don't believe there would be a "credit" issue. |
|
|
|
|
|
Words to the effect of "geneferCUDA pushes the GPU really hard" were posted elsewhere. I can confirm this in a thermal sense. The automatic fan control on my GTX 570 (Ubuntu 10.10) does not keep the card cool enough for my liking in my warm ambient environment, so I typically bump fan speeds up manually. I find fans at 65% or so will keep the card in the low 60's C when sieving. When running GeneferWR earlier this week, I had to go to 75%. No, they weren't hot days (though today was; glad I finished that WU Tuesday). This effect seemed more pronounced with the WR units than with the 524288 units though I might be imagining that.
I can't easily adjust the clock speeds from the mild factory o/c. There's no tool like "MSI Afterburner" on Linux so far as I am aware; flashing the card is an option but the idea gives me the willies. The nvidia control panel allows fan speed control if you enable it via an arcane setting, so at least I have that option.
--Gary
____________
"I am he as you are he as you are me and we are all together"
87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit) |
|
|
|
|
|
My first, big GFN Workunit is finished, but now I hope there is no problem with validating these results. Otherwise a week of crunching would be wasted. http://www.primegrid.com/workunit.php?wuid=253623372 I am wondering why this result doesn't get validated |
|
|
|
|
My first, big GFN Workunit is finished, but now I hope there is no problem with validating these results. Otherwise a week of crunching would be wasted. http://www.primegrid.com/workunit.php?wuid=253623372 I am wondering why this result doesn't get validated 3 inconclusive result... 3 different residues...
____________
35 x 2^3587843+1 is prime! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
My first, big GFN Workunit is finished, but now I hope there is no problem with validating these results. Otherwise a week of crunching would be wasted. http://www.primegrid.com/workunit.php?wuid=253623372 I am wondering why this result doesn't get validated
It looks like yours should have validated; it does match one of the other residues. You'll get credit for it as soon as they give the validator a kick in the posterior.
____________
My lucky number is 75898524288+1 |
|
|
|
|
My first, big GFN Workunit is finished, but now I hope there is no problem with validating these results. Otherwise a week of crunching would be wasted. http://www.primegrid.com/workunit.php?wuid=253623372 I am wondering why this result doesn't get validated 3 inconclusive result... 3 different residues...
355253530: RES=80990b445d181161
352999886: RES=80990b445d181161
355432799: RES=a06e74969b089d4f
____________
|
|
|
|
|
...Genefer is producing the right amount of credit,...
Who determined that without 'all the data'. As you say, presenting data from other projects may get it adjusted. I'm doing that myself, crunching some WUs from each project with GPU apps. And what about the credit to run time difference between ATI & nVidia and the utilization of the different apps when trying to compare? I guess that could be determined by GFLOPS/IOPS processed with the GPUs for comparison I would think. As you even say, GeneferCUDA is harder on GPUs than most apps (if not all apps from all projects). THAT ALONE should garner a bonus credit percentage addon for putting our GPUs through much more torture. Then there's the higher per second/minute/hour rate by some project for the 'long WUs'. There's other factors too. What makes it 'right'? It is what it is relative to all else.
The sieve to LLR 1:2 ratio is in the badges so that's in line. Common sense is that Prime finding on a GPU should be 1/2 that of the sieves if that logic is used.
And I haven't seen a credit war even with a few projects having a lot high credit, in fact most even adjusted down slightly after running a few days or weeks after starting out. So no raising of credit by 1 project then raising by another to out do the first and so on and so on. 'That' would be a credit war but has never happened, even with the ones giving 2-3 times the average. I'll leave it at that for now until I get all the data I can and present it.
NM*
____________
Largest Primes to Date:
As Double Checker: SR5 109208*5^1816285+1 Dgts-1,269,534
As Initial Finder: SR5 243944*5^1258576-1 Dgts-879,713
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
...Genefer is producing the right amount of credit,...
Who determined that without 'all the data'.
That would be the people who administer PrimeGrid. I don't believe I said we had no data. But it's also true that they probably don't have "All the data", since that's probably an infinite data set. What I said is if you could present enough data comparing Genefer to other non-PrimeGrid projects that are offering more credit from their stock apps, you'll have a much better argument as to why Genefer should get more credit.
And just so we're clear (I thought I was, but you never know...), "Right" in this case means that the credit being awarded is the amount of credit that the admins intended to be awarded. I.e., it's not a bug.
It could be worse. At least Genefer has consistent run times, which allows us to allocate credit fairly. That is a far better situation than you have with LLR, where run times are not as predictable and credit is all over the place and is dependent on accurate benchmarks occurring on every client computer. With Genefer, if WU X takes twice as long to process on your computer as WU Y, then you WILL get twice as much credit for X as for Y. Also, it doesn't matter who (or what) crunches those WUs; everyone will get the same credit. Doesn't matter if you have a fast GPU, a slow GPU, or a CPU, or if you're running Windows, Linux, or Mac OS. You can't say that will happen with LLR projects (and many, many other projects out there as well.)
Beyond this, there's little more I can say on this subject as I'm not the person who decides on the credit. If it was up to me, I'd just add three zeroes to all the credit numbers for GFN.
____________
My lucky number is 75898524288+1 |
|
|
|
|
I just got a Genefer World Record Task here after attaching to PrimeGrid after installing Windows on yet another partition (I have a 1 TB disc at my disposal - the third out of four partitions today since I am using such ones).
The monitor card is making quite a noise from the fan again while the task is running, but by means of surfing and otherwise not running much other programs, I do not notice to much delay or lagging in what I am doing here.
Typing in this text works quite well. Comparing with the CW sieves (CUDA-option active), this type of task sometimes brings my display almost to a halt after some time of running.
I had to temporarily shut down BOINC Manager shortly after the task started up because of Windows complaining once again. But for now I let the task run again once more.
But these tasks are definitely having very long running times, even by means of CUDA.
I guess the number in question must be very big, having many digits.
Is it possible to get the number being computed showing up in advance, in order for me not to have to wait until the task has become finished? For these types of tasks I have not yet been able to locate the number being used for the computation.
I only am able to tell it is computing b^4194304 + 1 without letting me get to know b.
You're most likely in world record territory, i.e. over 13.000.000 digits so yes this going to take a while. I'd say somewhere in the region of 8 days 24/7 crunching.
Smaller tasks are available for GFN, but these would obviously not be WR. Those tasks only take several hours to complete, rather than days.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Is it possible to get the number being computed showing up in advance, in order for me not to have to wait until the task has become finished? For these types of tasks I have not yet been able to locate the number being used for the computation.
I only am able to tell it is computing b^4194304 + 1 without letting me get to know b.
The next release of the software will tell you what "b" is from the beginning. I don't have an exact schedule for its release, but it should be very soon. "Soon" means days, not weeks.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
What is needed in order to verify such a number completely? Do you still need to rely on the LLR-mechanism, possibly excluding the option of running it by means of CUDA? What is the alternate way of running such a task in order to verify its possible primality if there should exist such an alternate way at all of carrying out such a task?
Should we find a Probable Prime (PRP), it will need to be verified with another program in order to prove its primality. (The odds of a PRP *not* actually being prime are astronomically small, but we have to verify it anyway.)
There are a variety of programs that can be used to prove primality once the PRP is found. PFGW, LLR, and Proth can all do the calculation. Compared to Genefer, however, they are very slow. The verification will certainly take several months, at least.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Is the remaining time for a task purely down to boinc?
At around the 9h mark my tasks were at 10% and 800 hours remaining which I thought rather odd.
Now around an hour later they have done another 1% or so but are showing over 1000 hours remaining. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14045
ID: 53948
Credit: 482,737,361
RAC: 581,467
|
Is the remaining time for a task purely down to boinc?
At around the 9h mark my tasks were at 10% and 800 hours remaining which I thought rather odd.
Now around an hour later they have done another 1% or so but are showing over 1000 hours remaining.
BOINC's estimates are notoriously unreliable.
Genefer's estimates, however, are exceptionally accurate. The total run time that you'll find in the stderr.txt should be accurate to within 1%, as long as you're not doing lots of stuff on the GPU such as watching HD video a significant portion of the time.
The internal estimate, combined with the BOINC display of the percentage complete and a calculator will give you an accurate estimate of the time remaining.
____________
My lucky number is 75898524288+1 |
|
|
