mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet > GPU to 72

Closed Thread
 
Thread Tools
Old 2020-04-04, 14:32   #155
KEP
Quasi Admin Thing
 
KEP's Avatar
 
May 2005

32×101 Posts
Default

Quote:
Originally Posted by chalsall View Post
Lastly... If the run-time is really such an issue for BOINC, why not take LaurV up on his offer to provide a version of mfaktc which breaks the bigger jobs down into sub-jobs?
Let's see if that changes. At least now credit will improve, so maybe the oppinion from the few complaining about credit, will change their state of mind. If people still end up complaining about the runtimes, then of course, if it does not mess up the functioning setup that BOINC has now, it could be time to bring LaurV into action with a new version of mfakt(c)(o)

Now, please understand, that GPU72, is a new subproject on a complete different project website. We have already benefit greatly from the credithunters, but it will be a while, before we see that BOINC users only coming to do GPU72 they settle for srbase. Once that settle happens, we will propably see that the users accept crunching for hours and eventually days. But let's wait and see what the future holds.

Personally I feel that BOINC should also be able to pick the low hanging fruits in stead of just doing the heavy lifting. Of course as the situation is now, BOINC ressources is best used to go to 78 bit (eventually higher) and prepare for P-1, but in the long run, we could actually attract more users, especially those with ~100 GHzdays/day hardware (my old GPU).

Those persons with 100 GHzdays/day hardware are having a hard time with these high bit levels and it is not productive in any way - wether being a BOINC project or not - to exclude certain part of users from participating. So whoknows, maybe in the future, we could do much better, by having a lowhanging fruit for the slow hardware and a heavy lifting subproject for GPU72 at BOINC.

That decision still lies in the future, but it could sure meet the demands of both hardwaregroups, if that demand does not become obsolete because we attract hundreds or thousands of TF users, being their from interest in GIMPs more than from a credit perspective

Thanks for your reply, and I do still believe that we should shoot for n<=120M to 78 bit, the ressources are there to accomplish that task
KEP is offline  
Old 2020-04-04, 15:49   #156
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

6,841 Posts
Default

A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?
Prime95 is offline  
Old 2020-04-04, 16:01   #157
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

6,841 Posts
Default

Quote:
Originally Posted by KEP View Post
To be honest I don't get it, why most projects don't use BOINC at all. It really shouldn't be hard to set up BOINC and make things working, if you have already made all the initial programming of independent software.
When I looked at BOINC many, many years ago there were several obstacles. 1) It would be a lot of work for me (and Scott). 2) The really long work units were unheard of in the BOINC universe. 3) There were some differences in the workflow (I don't remember what they were) that might cause some current GIMPS users to grumble.

But I think the big reason was this: There was a general feeling among users that it would be appalling for the discoverer of a new Mersenne prime to have no appreciation for what he has discovered.
Prime95 is offline  
Old 2020-04-04, 16:15   #158
RichD
 
RichD's Avatar
 
Sep 2008
Kansas

2×3×491 Posts
Default

Quote:
Originally Posted by KEP View Post
So whoknows, maybe in the future, we could do much better, by having a lowhanging fruit for the slow hardware and a heavy lifting subproject for GPU72 at BOINC.
I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters. Guessing GPU cards will only get bigger and better.
RichD is offline  
Old 2020-04-04, 16:28   #159
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

214428 Posts
Default

Quote:
Originally Posted by RichD View Post
I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters.
Excellent suggestion.

Over on SRBase there are already different classes of work available for the Sierpinski / Riesel WUs. Short, Long and Average.

The Long class has an average run-time of ~60 hours. This seems it would map well to the GIMPS TF'ing problem space. Reb could reserve blocks as appropriate for each class.

Quote:
Originally Posted by RichD View Post
Guessing GPU cards will only get bigger and better.
Already empirically demonstrated!
chalsall is offline  
Old 2020-04-04, 17:02   #160
pinhodecarlos
 
pinhodecarlos's Avatar
 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK

107318 Posts
Default

Quote:
Originally Posted by Prime95 View Post
A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?

Nothing prevents them to increase, problem is the boycott from other teams and users, which at the end it can damage the project reputation. Found the link to a boinc stats page which shows the credit comparison between all projects.


https://www.boincstats.com/stats/-1/cpcs
pinhodecarlos is online now  
Old 2020-04-04, 17:13   #161
pinhodecarlos
 
pinhodecarlos's Avatar
 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK

3×1,523 Posts
Default

Quote:
Originally Posted by chalsall View Post
That is correct. In fact, the equation I gave above was originally designed for calculating the credit for CPU TF'ing. There was a bit if a lengthly debate years ago about whether there should be scaling applied to give GPUs less credit, because they are ***soooo*** much faster at the work.

On Boinc world it is fair to say that you can credit the GPU app as many times higher than GPU is faster than the CPU app for the common unit of measurement.
pinhodecarlos is online now  
Old 2020-04-04, 17:41   #162
petrw1
1976 Toyota Corona years forever!
 
petrw1's Avatar
 
"Wayne"
Nov 2006
Saskatchewan, Canada

103008 Posts
Default User count dropped for SRBase....

For much of the last week it was 80-100 users.
For the last few hours it has been under 70.

Could it be time of day?
Could it be waning interest?
Could it be people scared off by longer run times of TF78?

I really have no idea; just throwing it out there.
petrw1 is offline  
Old 2020-04-04, 17:58   #163
KEP
Quasi Admin Thing
 
KEP's Avatar
 
May 2005

32×101 Posts
Default

Quote:
Originally Posted by Prime95 View Post
A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?
To be honest I don't know, but as far as I know, the credit is valued in cobblestones and the cobblestone (at least as it is initially thought to work) should be a possible measurement of the actual computation completed per workunit. I really think that some projects has had "credit inflation" and to the extend that it does not really undermine the whole idea of the cobblestones, it could be okay. As far as I remember, a computer that does 1 GFLOPs produces 200 cobblestones credit a day. Could this in anyway be transformed into GHz days, with that knowledge in hand?

Quote:
Originally Posted by Prime95 View Post
When I looked at BOINC many, many years ago there were several obstacles. 1) It would be a lot of work for me (and Scott). 2) The really long work units were unheard of in the BOINC universe. 3) There were some differences in the workflow (I don't remember what they were) that might cause some current GIMPS users to grumble.

But I think the big reason was this: There was a general feeling among users that it would be appalling for the discoverer of a new Mersenne prime to have no appreciation for what he has discovered.
Well, in BOINC each and every user has their own account, just like in GIMPs and when a user completes a workunit, he/she has a record under his/hers username describing that this and this user found a prime. So credit would still be possible to award to a single user. BOINC really isn't that much different from Primenet, only there is currently 914914 active hosts spread on 145229 active users. Some users not being active might "reactivate" once they see a new BOINC project. As such srbase is not a new project, but GIMPs would deffinently have caught a lot of attention as being a new project. So the big reason is not at all justified. And back then, climateprediction asked users to use 4-6 weeks of their computers to compute weathermodels, no need to say GIMPs dwarf that

Quote:
Originally Posted by RichD View Post
I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters. Guessing GPU cards will only get bigger and better.
Yes, that should be possible, but if I remember correctly, there is a limit how many subprojects that Reb can set up and if there is no free slots for further subprojects, it might not be possible. I however, if it is possible would also like such a feature, at least to give the users with a slow and old GPU a fair chance to not have to work for days to complete imideate work. It will also as mentioned previously keep users at our hand, users that does not prefer the long running workunits and in general give the user some flexibility to flex back and forward between short and fast workunits and long running workunits.
KEP is offline  
Old 2020-04-05, 05:38   #164
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

854310 Posts
Default

Quote:
Originally Posted by chalsall View Post
To put on the table, perhaps going to 78 is a bit too far (literally).
What I am "arguing" for years now, is doing P-1 before the last bit. I can "prove" this saves time. The idea is not mine, George used to incorporate it in the very first versions of P95, long before GPUs entered the arena.

In our case, going to 77 would be fine for the MOST of the cards (see James tables), then wait till at least a 3-5% P-1 is done, and only then, do the last bit (78) for the remaining candidates.

So, 77, P-1, 78.

For the "good" cards, i.e. those with good FP64 speed, which can run P-1/LL/PRP reasonable fast, the process (at 100M+ exponents) should be even "worse": 76, P-1, 77.

I would kinda "waste" my 2080Ti and 1080Ti running the last bits for candidates with no P-1. I can run about 40 P-1 assignments to 3% in the same time I could run 76 or 77 TF to 77 bits, so you see I could find 1.2 factors by P-1 in the same time I can find only 1.0 factors by TF, at this bitlevel.

Last fiddled with by LaurV on 2020-04-05 at 05:45
LaurV is offline  
Old 2020-04-05, 09:15   #165
KEP
Quasi Admin Thing
 
KEP's Avatar
 
May 2005

32·101 Posts
Default

Quote:
Originally Posted by LaurV View Post
What I am "arguing" for years now, is doing P-1 before the last bit. I can "prove" this saves time. The idea is not mine, George used to incorporate it in the very first versions of P95, long before GPUs entered the arena.

In our case, going to 77 would be fine for the MOST of the cards (see James tables), then wait till at least a 3-5% P-1 is done, and only then, do the last bit (78) for the remaining candidates.

So, 77, P-1, 78.

For the "good" cards, i.e. those with good FP64 speed, which can run P-1/LL/PRP reasonable fast, the process (at 100M+ exponents) should be even "worse": 76, P-1, 77.

I would kinda "waste" my 2080Ti and 1080Ti running the last bits for candidates with no P-1. I can run about 40 P-1 assignments to 3% in the same time I could run 76 or 77 TF to 77 bits, so you see I could find 1.2 factors by P-1 in the same time I can find only 1.0 factors by TF, at this bitlevel.
Interesting

Now let me see if I understand it correctly. As I read you, we should prioritiez 76-77 then 75-77, then 74-77 and if any remain 73-77 bit, before doing 78 bit on candidates already P-1 tested.

I'm not sure how you have investigated this, but as soon as we go above n=120M, optimum bit will be 79 bit and around 153M it will increase to 80 bit. Is it your interpretation, that the rule of thumb, is for most if not all n as follows:

TF(Optimum bit)-1,P-1 factoring,TF(Optimum bit)?

Does anyone know what the daily need to keep the P-1 factorers satisfied is? In other words, how many tests does the P-1 users complete tests each day?
KEP is offline  
Closed Thread

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Chess World Championship Match -- 2013, 2014, 2016 Raman Chess 34 2016-12-01 01:59
mprime ETA and primenet "days to go" do not match blip Software 1 2015-11-20 16:43
less v4 reservations being made tha PrimeNet 8 2008-08-14 08:26
LL test doesn't match benchmark drew Hardware 12 2008-07-26 03:50
WE MADE IT!!!!!!!!!!!!!!!!!!!!!! eric_v Twin Prime Search 89 2007-01-23 15:33

All times are UTC. The time now is 21:04.

Tue Jun 2 21:04:23 UTC 2020 up 69 days, 18:37, 2 users, load averages: 2.38, 2.34, 2.09

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.