GPU72 and BOINC a match made in ....

[rebirther]

Originally Posted by Prime95

It is not hard for me to modify the get GPU TF assignments web page to accomodate a BOINC server. From PrimeNet's perspective it is much easier with all BOINC results reported as one user.

yeah, BOINC and Primenet are both different pair of shoes. The app is in a zip with the ini file. I cant define a userid there. The reserving is one file and will be split into different files. One task for one user. All final results will be sticking to one bigfile and reported back under one user.

[KEP]

Originally Posted by Prime95

It is not hard for me to modify the get GPU TF assignments web page to accomodate a BOINC server. From PrimeNet's perspective it is much easier with all BOINC results reported as one user.

Thanks for being understanding in regards of the need to have BOINC reserve and report results as ONE user

What kind of modifications would be nescessary?

I have just sent Reb a list of the bit levels, to trial factor to, when shooting for a +2 bit level above optimal CPU trial factoring.

[Prime95]

Originally Posted by KEP

Thanks for being understanding in regards of the need to have BOINC reserve and report results as ONE user

What kind of modifications would be necessary?

I have just sent Reb a list of the bit levels, to trial factor to, when shooting for a +2 bit level above optimal CPU trial factoring.

Basically, we define a "secret" web page for you to get TF assignments and another web page that lets you report TF results. A special web page is nice in that primenet's response can strip out all that HTML crap to make it easy to parse.

As to bit levels, there are (at least) three ways to approach the problem.
1) Give the BOINC client knowledge of optimal bit levels for different exponents.
2) Let the secret web page worry about optimal levels, we just assign the exponent along with starting and desired ending bit levels
3) Don't worry about optimal bit levels. Simply assign exponents that are likely to be PRP'ed over the next 180 days or year and have the client take the TF on the exponent up one bit level. This may do more or less than optimal based on available resources.

[chalsall]

Originally Posted by Prime95

Basically, we define a "secret" web page for you to get TF assignments and another web page that lets you report TF results.

And if I may please add to this discussion...

Another important component of this whole schema is the timeliness of completion.

I don't know how the BOINC server <--> client operations work, but the BOINC server should take responsibility for re-starting and/or recycling work units given to the clients.

As an example, if BOINC took "ownership" of the 102M range to take up to 75 or 76, it should be finished by the time the Cat 1 wavefront reaches there.

To be clear, I would /really/ like to see this work. But it will be working beside GPU72, since the two systems are so very different. Heck, one day it might very well eclipse GPU72!

[KEP]

Originally Posted by Prime95

Basically, we define a "secret" web page for you to get TF assignments and another web page that lets you report TF results. A special web page is nice in that primenet's response can strip out all that HTML crap to make it easy to parse.

As to bit levels, there are (at least) three ways to approach the problem.
1) Give the BOINC client knowledge of optimal bit levels for different exponents.
2) Let the secret web page worry about optimal levels, we just assign the exponent along with starting and desired ending bit levels
3) Don't worry about optimal bit levels. Simply assign exponents that are likely to be PRP'ed over the next 180 days or year and have the client take the TF on the exponent up one bit level. This may do more or less than optimal based on available resources.

at 1: That would be nice, since Reb would then not have to change anything, before splitting the range into workunits for BOINC. As long as optimal bit level is actually +2 bits above the yellow marker on the mersenne.ca webpage

at 2: Really nice idea, wich would also align with no. 1

at 3: Don't really like that, because part of going to BOINC is to get to optimal sievedepth and to try to clean up the "mess" of different ranges having different trial factoring doing on different exponents.

Really like the "secret" webpage, made just for BOINC. What might be wort designing such a "secret" webpage for, would be to allow for resultfiles greater than 2MB and to make sure when Reb (or maybe me) reserves work, BOINC actually get's the smallest n available and also that the reservation limit of 1000 candidates is removed on the "secret" webpage Other than that, thanks for your positive attitude and willingness and now let's hope that the initial testing is in fact succesful as hoped

Fingers crossed, but hopefully in a couple of weeks the world of GIMPs will have changed drastically to the better on the TF level

[KEP]

Originally Posted by chalsall

And if I may please add to this discussion...

Another important component of this whole schema is the timeliness of completion.

I don't know how the BOINC server <--> client operations work, but the BOINC server should take responsibility for re-starting and/or recycling work units given to the clients.

As an example, if BOINC took "ownership" of the 102M range to take up to 75 or 76, it should be finished by the time the Cat 1 wavefront reaches there.

To be clear, I would /really/ like to see this work. But it will be working beside GPU72, since the two systems are so very different. Heck, one day it might very well eclipse GPU72!

You may add to this discussion

When BOINC assign work to a client, the server sets a deadline, this one can in the short term, where we really need to have the work returned in order to keep up with the work Ben Delo among others are doing, be a short deadline. The deadline is defined by the project and not the server, so in theory we can set a deadline of 1 day (if that makes sense).

We may not in the beginning be able to keep up with the various categories, but if enough momentum is gained (wich I think it will) by BOINC, then in very short time (especially as long as people are hunting for badges) optimal TF (+2 bit) for even category 3/4(? not sure 4 excist) will be optimally TF and far far far ahead of any wavefront of any category.

No doubt you like to see it work. And with the optimism expressed by Rebirther, I'm most confident that it will work. To get most out of our ressources we do in fact need to work together to ensure that BOINC does not step the toes of GPU72 and vice versa and I hope that we all, despite recent postings can find that common ground

Stay safe and healthy

[LaurV]

About point 1, optimum bitlevel depends on the hardware you have (according with James' tables, for example). When I get assignments from PrimeNet or Gpu72, I know what hardware I run and I can specify the range and bitlevel to work, to ensure optimum efficiency from the whole project view (i.e. clear the most exponents for time unit, by doing either TL, P-1, or LL/PRP). Well, assuming I know what I am doing, and assuming I am well intentioned. If I am still well intentioned, but don't know what I am doing, I can "let gpu72 decide" for me, what work is more important, but yet, this is decreasing the "efficiency" on long term: doing what they serve me may decrease the number of exponents I can clear per the unit of time, with my hardware. Anyhow, I see what ranges are worked, etc. (won't go into details here).

How is this handled with the Boink-boink alternative? Can the user opt what type of "units" he gets to deflea? If you keep no information about user's hardware or preferences, then one user may get units which are not optimum for his rig, and in the long term, slow the project down instead of speeding it up. Of course, this will bring the army of BOINC users into the Gimps project, but yet, there are many things to clarify, including what type of work should be shared with, like can they do PRP/LL, or only factoring (TF/Pm1), and if they do LL/PRP, what happens when they find a prime?

I believe that Chris is right here, and his "method" (of letting the users report to base by themselves) is sane^(TM), but on the other hand, I agree that BOINC addition to Gimps would be nice... Of course, I don't fully know what BOINC can really do, and how it works, so skip the moral please, if I said something stupid, but I know they have a huge base of users and many would like to get their hands on that base of users...

[KEP]

Originally Posted by LaurV

About point 1, optimum bitlevel depends on the hardware you have (according with James' tables, for example). When I get assignments from PrimeNet or Gpu72, I know what hardware I run and I can specify the range and bitlevel to work, to ensure optimum efficiency from the whole project view (i.e. clear the most exponents for time unit, by doing either TL, P-1, or LL/PRP). Well, assuming I know what I am doing, and assuming I am well intentioned. If I am still well intentioned, but don't know what I am doing, I can "let gpu72 decide" for me, what work is more important, but yet, this is decreasing the "efficiency" on long term: doing what they serve me may decrease the number of exponents I can clear per the unit of time, with my hardware. Anyhow, I see what ranges are worked, etc. (won't go into details here).

How is this handled with the Boink-boink alternative? Can the user opt what type of "units" he gets to deflea? If you keep no information about user's hardware or preferences, then one user may get units which are not optimum for his rig, and in the long term, slow the project down instead of speeding it up. Of course, this will bring the army of BOINC users into the Gimps project, but yet, there are many things to clarify, including what type of work should be shared with, like can they do PRP/LL, or only factoring (TF/Pm1), and if they do LL/PRP, what happens when they find a prime?

I believe that Chris is right here, and his "method" (of letting the users report to base by themselves) is sane^(TM), but on the other hand, I agree that BOINC addition to Gimps would be nice... Of course, I don't fully know what BOINC can really do, and how it works, so skip the moral please, if I said something stupid, but I know they have a huge base of users and many would like to get their hands on that base of users...

BOINC is only for TF, since that was where the lack of workers were emminent when BOINC was suggested in the first place.

There has not yet been taken any decision on how to handle work in production mode. Of course there is different ways to handle this, but to be honest, when my OLD GPU did TF it was on ALL candidates 100% efficient for <=75 bit. The bits above that it went down to 90% efficiency in accordence to Ghz/day.

I think that it should be up to Reb how to handle the work the users get. I can see both cons and pros by going from current bitlevel to bitlevel +2 above optimal bitlevel, in one testrange per workunit, but lets see what we end up doing. Most important is to attract new users and support to the TF effort

[LaurV]

Originally Posted by KEP

my OLD GPU did TF it was on ALL candidates 100% efficient for <=75 bit. The bits above that it went down to 90% efficiency in accordence to Ghz/day.

Thanks for the prompt reply.

Related to the efficiency, many people get this wrong. It is not about how fast is your GPU TFing at 75 bits compared with how fast it is TFing at 77 bits. That comparison is of no value. It is about how fast you can clear exponents doing TF with that system (CPU+GPU) compared with how fast you can clear the exponents in the same range when you do Pm1 with the same system and compared with how fast you can clear them with LL/PRP with the same system. For me, it takes me about 6 minutes to TF to 76 bit in 100Mbit range (actual front). A bit faster if I find factors, but in average, if I find a factor every ~76 runs (theoretical value, but if you look to the gpu72 tables, I am on the "lucky" side, finding about 1 factor every 72 runs or so), then I can clear one exponent every ~ 8 hours. With the same system, I could run a LL test (in average) every 6-7 hours. Therefore to clean an exponent by LL+DC would take 12-14 hours. So, for my system, is more efficient to do TF at 76 bits than to do LL, at front 100Mbit range.

However, if I switch to 77 bits, the TF time would double, for about the same rate of finding factors (like 1 in 77 runs, theoretic value) and I would need 14-16 hours to clean one exponent by TF, therefore I would be less efficient with TF, because LL would still need 12-14 hours to clean that exponent. Therefore, I frown any time Chris is serving me assignment to 77 bits (well, in fact, these numbers were rounded, to easy the example; at 77 bits TF, I am "on the edge", taking about the same time to find a factor as it would take to run a LL and a DC, in average).

That is why we have these limits for bitlevels, depending on the hardware you run. My cards for example are quite good at DP calculus (used for LL/PRP) but other (gaming) cards are more suitable for TF, and you could go much higher with the bitlevel, because they are not so good for LL/PRP (or completely futile).

[axn]

Originally Posted by LaurV

About point 1, optimum bitlevel depends on the hardware you have
<snip>
but I know they have a huge base of users and many would like to get their hands on that base of users...

Unless the BOINC project hands out LL tests as well, there is no point in calculating optimum bit level using traditional metric. BOINC is about tapping into the huge user base who primarily care about earning cobblestones (BOINC credit unit). As long as the project hands out a decent amount of cobblestones for their hardware time, they're happy.

The optimum bit level is the maximum bit level which can still prepare enough exponents for the LL testers. If that means normal + 10 bits, so be it. Obviously we shouldn't be "abusing" it -- we should be good DC citizens and not do grossly inefficient calculations, so we should go with current max bit level for the best hardware (assuming BOINC can keep up with LL demand).

All this concerns about different hardware and relative efficiencies are unneeded complications. It is good to worry about all these /once/ the project gets off the ground and has a stable user base. But doing it now is just a recipe for analysis paralysis.

[KEP]

Originally Posted by axn

All this concerns about different hardware and relative efficiencies are unneeded complications. It is good to worry about all these /once/ the project gets off the ground and has a stable user base. But doing it now is just a recipe for analysis paralysis.

Thank you, couldn't have said it better myself.

I'm sure, at least untill many users start to max out on the badges, that a sustainable and stable user base will be the case. Lets see. Hope is that production phase starts next week. My stand will still be to go from current bit level up till +2 bit - simply because it will be no problem for the average GPU user and be the best case scenario for the highend GPU user.

Now everyone, let's get BOINC off its feet and see how much ressources we can attract, before starting to care about a bit or 2 of extra trial factoring