GPU72 and BOINC a match made in ....
 

[QUOTE=chalsall;533771]But if anyone has any GPU compute available (perhaps Santa was kind???) we could *really* use some more TF'ing firepower.[/QUOTE]

Even though many parts of this forum doesn't like to hear it, I'm going to say it anyway: IT IS TIME TO GO BOINC.

There is litterally a whole forest of GPUs available for you to use for free and bring you years ahead of Ben Delo. I believe that some of you could easily make mfakt(0)(c) work on BOINC and setup a database to run BOINC.

I know at least one project here has benefit a LOT from allowing BOINC to support their project. It now seems that you are in no way in a position where you can actually keep up "on your own". So please put the appropriate people to work and maybe let the CPU trial factoring people start working on higher bits in stead of just working the same bit for the increasing n-range (that could also help a little).

Just my 2 cents, to help bring back som true lead and efficiency to the trial factors wich is currently fighting a "loosing" battle :smile:

Take care and happy new year everyone :smile:

[QUOTE=KEP;533774]Just my 2 cents, to help bring back som true lead and efficiency to the trial factors wich is currently fighting a "loosing" battle :smile:[/QUOTE]

I'm certainly not against the idea, although I wouldn't be able to do all the work myself. I'd be happy to work with anyone capable, to make the reservations available by way of an API (if what is currently available is insufficient).

But with regards to having CPUs doing the TF'ing... While there's nothing stopping anyone from doing this, it _really_ doesn't make sense. GPUs are just /so/ much faster at this work type.

I have started to setup GPU72 on SRBase (BOINC). There is still a lot of work to do and making some tests. If all is going as planned there will be a speedup in processing. I cant promise anything but Iam confident.

[QUOTE=rebirther;539751]I have started to setup GPU72 on SRBase (BOINC). There is still a lot of work to do and making some tests. If all is going as planned there will be a speedup in processing. I cant promise anything but Iam confident.[/QUOTE]

That might be very interesting for Mac users running the latest 64 bit OS

[QUOTE=rebirther;539751]I have started to setup GPU72 on SRBase (BOINC). There is still a lot of work to do and making some tests. If all is going as planned there will be a speedup in processing. I cant promise anything but Iam confident.[/QUOTE]

I am unable to creat an account, as new accounts are not been created, how does one start?
I have used BOINC in the past for many, many years

Sorry if this is off topic

[QUOTE=bayanne;539836]I am unable to creat an account, as new accounts are not been created, how does one start?
I have used BOINC in the past for many, many years

Sorry if this is off topic[/QUOTE]

It is not nescessarely off topic :smile:

Have you followed the steps on the main site: [url]http://srbase.my-firewall.org/sr5/index.php[/url]

and have you prompted the invitation code "pillepalle" (without "") when asked for?

Btw there is not yet loaded any new work for Mersenne/GPU72. I've shown Reb how to reserve a large chunk of work for testing purpose at mersenne.org but unfortunantly he has not been online after I sent him that private message. So hopefully in a few days Pre Alpha test work will be loaded and hopefully you will have an account at srbase :smile: ... in case of further problems, reach out in a PM and I'll try to trouble shoot what you may experience :smile:

Please note I'm not a programmer, just experienced helper :smile:

Thanks

[QUOTE=bayanne;539836]I am unable to creat an account, as new accounts are not been created, how does one start?
I have used BOINC in the past for many, many years

Sorry if this is off topic[/QUOTE]


Hi, you must create an account over the website then you can connect with BOINC to SRBase, because of SPAM protection Iam using an invitation code, thats the best protection.

[QUOTE=KEP;539843]Please note I'm not a programmer, just experienced helper :smile:[/QUOTE]

Just to put on the table... This "BOINC / GPU72" thing is not even alpha at the moment.

No testing has been done. Nor is there /any/ IPC between the two systems.

[QUOTE=chalsall;539962]Just to put on the table... This "BOINC / GPU72" thing is not even alpha at the moment.

No testing has been done. Nor is there /any/ IPC between the two systems.[/QUOTE]

Were that not what I actually wrote in that reply you are now quoting?

[QUOTE=KEP;540031]Were that not what I actually wrote in that reply you are now quoting?[/QUOTE]


Its a slow progress. The setup for win64 AMD / Nvidia apps are done. Linux and Mac will follow. I hope I can start testing on weekend after I have all server daemons and work scripts up.

[QUOTE=rebirther;540074]Its a slow progress. The setup for win64 AMD / Nvidia apps are done. Linux and Mac will follow. I hope I can start testing on weekend after I have all server daemons and work scripts up.[/QUOTE]

No worries, if succesful, this will in no doubt be worth the wait and then Ben Delo can't catch up on the trial factoring :smile: ... that might change in the future, when people starts to reach those batches they hunt for. I will still for testing purpose, suggest that you follow the small test from n>250M. Once they are complete and BOINC goes from testing to productivity mode, then go to GPU72 or reserve at mersenne.org the lowest possible candidates to factor :smile: Still very nice work. Stay safe!

[QUOTE=rebirther;540074]I hope I can start testing on weekend after I have all server daemons and work scripts up.[/QUOTE]

Yes... Testing would be a /really/ good idea, as I've said to you both privately many times.

There is a /tonne/ of details still to work out. Such as, how does the work get credited to the GPU72 / Primenet users? How does your system and GPU72 / Primenet communicate?

Frankly, I'm a little annoyed this has been announced so prematurely.

[QUOTE=chalsall;540096]Yes... Testing would be a /really/ good idea, as I've said to you both privately many times.

There is a /tonne/ of details still to work out. Such as, how does the work get credited to the GPU72 / Primenet users? How does your system and GPU72 / Primenet communicate?

Frankly, I'm a little annoyed this has been announced so prematurely.[/QUOTE]


I will create only one account for SRBase to report all the stuff there. Manual reservation and reporting.

[QUOTE=rebirther;540157]I will create only one account for SRBase to report all the stuff there. Manual reservation and reporting.[/QUOTE]

And how, exactly, is a Primenet / GPU72 user going to be getting the credit for the work done via their BOINC clients? Have you established an interface with the Primenet API? It's non-trivial work.

Could a supermod please move these BOINC messages into a separate thread under the "GPU to 72" subforum? Based on past interactions, there's going to be a great deal of noise which I don't want polluting the main status thread.

[QUOTE=chalsall;540158]Could a supermod please move these BOINC messages into a separate thread under the "GPU to 72" subforum? Based on past interactions, there's going to be a great deal of noise which I don't want polluting the main status thread.[/QUOTE]I also grabbed a couple from late 2019. I left those from much earlier.

[QUOTE=Uncwilly;540160]I also grabbed a couple from late 2019. I left those from much earlier.[/QUOTE]

Thank you.

I think a BOINC solution space would be a /really/ good idea. But there's a lot of details to work out, many of which haven't even been discussed yet.

[QUOTE=chalsall;540158]And how, exactly, is a Primenet / GPU72 user going to be getting the credit for the work done via their BOINC clients? Have you established an interface with the Primenet API? It's non-trivial work.

Could a supermod please move these BOINC messages into a separate thread under the "GPU to 72" subforum? Based on past interactions, there's going to be a great deal of noise which I don't want polluting the main status thread.[/QUOTE]


I have no Primenet interface and its not planned. All the credits should go to SRBase under one account, easier to manage. If you have a Primenet account do your own work.

[QUOTE=rebirther;540162]I have no Primenet interface and its not planned. All the credits should go to SRBase under one account, easier to manage. If you have a Primenet account do your own work.[/QUOTE]

This is antithetical to the GPU72 position that all work is credited to the individual user, both on GPU72 and Primenet.

Please remove the reference to GPU72 at srbase.my-firewall.org, since GPU72 clearly will not be involved.

[QUOTE=chalsall;540171]This is antithetical to the GPU72 position that all work is credited to the individual user, both on GPU72 and Primenet.

Please remove the reference to GPU72 at srbase.my-firewall.org, since GPU72 clearly will not be involved.[/QUOTE]

I sure hope that someone someday will teach you to control your inner R. D. Silverman. Just because of your lack of willingness to understand how BOINC works, you have wasted a lot of Rebirthers time, for no sense at all.

What you ask for Rebirther to do, requires not only a ton of work for Rebirther, it simply does not make sense in a BOINC way at all. Sorry that I suggested this initially, I just really thought that the "hate" and disregard towards BOINC like we have seen it in many projects that had almost come to a standstill - like sr5.

There comes a time where a clever solution like GPU72 is just no longer enough and at that time, no matter what used to be the culture or the ethics of a project, those ethics and morals has to align them self for what is being offered.

Time is not really there anymore, where GPU72 can call out guidance lines towards BOINC, BOINC could have been a major contribution towards the wavefront and GIMPs in general. It will no longer be, because of a lack of respect for other users time and work.

I feel sorry that Rebirther has wasted this load of time and that the progress he made is no longer going to be used to ALL users benefit :smile:

For the future, please stop your complaining about lack of ressources in public, since you obviously doesn't desire the much needed offer for help you actually gets.

Take care and stay safe.

[QUOTE=KEP;540228]I feel sorry that Rebirther has wasted this load of time and that the progress he made is no longer going to be used to ALL users benefit.[/QUOTE]

I feel it is /my/ time that has been wasted, answering the same questions over and over again via PM. Never did he tell me "I can't do what you envision" when I repeatedly asked about IPC between the systems.

His time isn't wasted, if he wants to continue. He can get blocks of assignments for BOINC clients to work directly from Primenet, just like GPU72 does. And I hope he does.

[QUOTE=KEP;540228]
I feel sorry that Rebirther has wasted this load of time and that the progress he made is no longer going to be used to ALL users benefit :smile:[/QUOTE]

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.

[QUOTE=Prime95;540248]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.[/QUOTE]


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.

[QUOTE=Prime95;540248]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.[/QUOTE]

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

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.

[QUOTE=KEP;540255]Thanks for being understanding in regards of the need to have BOINC reserve and report results as ONE user :smile:

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.[/QUOTE]

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.

[QUOTE=Prime95;540271]Basically, we define a "secret" web page for you to get TF assignments and another web page that lets you report TF results.[/QUOTE]

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 [URL="https://www.gpu72.com/charts/tf/fc/102/"]the 102M range[/URL] 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! :smile:

[QUOTE=Prime95;540271]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.[/QUOTE]

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 :smile:

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

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 :smile: 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 :smile:

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

[QUOTE=chalsall;540276]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 [URL="https://www.gpu72.com/charts/tf/fc/102/"]the 102M range[/URL] 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! :smile:[/QUOTE]

You may add to this discussion :smile:

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 :smile:

Stay safe and healthy :smile:

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 :razz: 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[SUP](TM)[/SUP], 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...

[QUOTE=LaurV;540457]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 :razz: 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[SUP](TM)[/SUP], 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...[/QUOTE]

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 :smile:

[QUOTE=KEP;540463]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.[/QUOTE]
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 [U]in the same range[/U] when you do Pm1 [U]with the same system[/U] and compared with how fast you can clear them with LL/PRP [U]with the same system[/U]. 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 :razz: (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).

[QUOTE=LaurV;540457]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...[/QUOTE]

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.

[QUOTE=axn;540476]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.[/QUOTE]

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 :smile:

You guys can ask Sergei Chernykh what happened when he started with [url]https://sech.me/boinc/Amicable/[/url] , client is GPU based and he is also a member of this forum. Last 24 hours almost 1,000 hosts connected.


Edit:

[url]https://www.mersenneforum.org/showthread.php?t=21960&highlight=Sergei[/url]

From what I can see from FreeDC-Stats his project has a total of 333 teams, 7,286 users and 10,391 hosts.

[QUOTE=pinhodecarlos;540487]You guys can ask Sergei Chernykh what happened when he started with [url]https://sech.me/boinc/Amicable/[/url] , client is GPU based and he is also a member of this forum. Last 24 hours almost 1,000 hosts connected.


Edit:

[url]https://www.mersenneforum.org/showthread.php?t=21960&highlight=Sergei[/url]

From what I can see from FreeDC-Stats his project has a total of 333 teams, 7,286 users and 10,391 hosts.[/QUOTE]

If we end up with 10,391 GPUs all searching for the highest badge, we will never ever have to worry about First time LL/PRP testing catches up to TF :smile: Plus it would also help clean out a lot of DC candidates (even though they are and should not be first priority by BOINC) :smile:

[QUOTE=KEP;540492]If we end up with 10,391 GPUs all searching for the highest badge, we will never ever have to worry about First time LL/PRP testing catches up to TF.[/QUOTE]

Realistically, how likely is that? It would be very cool, but I question if every BOINC participant is suddenly going to be throwing all their resources to MP candidate TF'ing.

I see rebirther has reserved 1,000 candidates in 102M. I look forward to seeing those taken up to 77. :tu:

Here [url]https://stats.free-dc.org/proj/ami#select[/url] you can find the unhidden hosts connected to amicable project. Click on left side where it says hosts.


BTW, active users for GPU72 on BOINC: [url]https://stats.free-dc.org/subproj/srb/GPU72[/url]

[QUOTE=chalsall;540493]Realistically, how likely is that? It would be very cool, but I question if every BOINC participant is suddenly going to be throwing all their resources to MP candidate TF'ing.[/QUOTE]
You really don't know anything about BOINC community, do you?

[QUOTE=axn;540496]You really don't know anything about BOINC community, do you?[/QUOTE]

Not a thing. Please educate me.

[QUOTE=chalsall;540493]Realistically, how likely is that? It would be very cool, but I question if every BOINC participant is suddenly going to be throwing all their resources to MP candidate TF'ing.

I see rebirther has reserved 1,000 candidates in 102M. I look forward to seeing those taken up to 77. :tu:[/QUOTE]

It may not be so far fetch as one could think. Realistical, maybe and maybe not, but we all have to note that in the beginning there is a lot of people chasing badges and fast cobblestones and credit that comes immediately. Many of those will find TF interesting and contribute for quite some time before reaching their personal goals :smile:

So Reb has created an account at GPU72? If not, how can you see who has reserved what?

It appears from my look at GPU72.com*, that GPU72.com has everything reserved* up to n=108M. I hope that Reb, will eventually take these to 78 bits. For testing purpose, it will be good enough to just test to 77 bit, to see if everything is ready for production phase. Once we get to production phase, that range should be TF to 78 bit :smile:

* Source: [url]https://www.gpu72.com/reports/current_level/[/url]

[QUOTE=KEP;540498]So Reb has created an account at GPU72? If not, how can you see who has reserved what?[/QUOTE]

Nope. Despite my repeatedly asking him to (via PM, CCed you), he never created an account at GPU72.

I can see what he's reserved by querying Primenet (just like everyone else).

[QUOTE=KEP;540498]It appears from my look at GPU72.com, that GPU72.com has everything reserved up to n=108M.[/QUOTE]

Nope. 102M, 104M, and 105M are currently not "owned" by GPU72. Once this system had proven itself, I'll release additional ranges for BOINC to work.

[QUOTE=chalsall;540500]Nope. 102M, 104M, and 105M are currently not "owned" by GPU72. Once this system had proven itself, I'll release additional ranges for BOINC to work.[/QUOTE]

You are correct, I simply mixed up your page showing Current Trial Factoring Depth as GPU72s reservations :smile:

Let's see what is needed, once we gets flying :smile:

Take care and stay safe :smile:

[QUOTE=KEP;540504]Let's see what is needed, once we gets flying :smile:[/QUOTE]

So, how's this going? I was hoping to see a mind-blowing amount of TF'ing happening in 102M, but so far nothing.

Anything I can do to help? (Sincerely.)

[QUOTE=chalsall;540643]So, how's this going? I was hoping to see a mind-blowing amount of TF'ing happening in 102M, but so far nothing.

Anything I can do to help? (Sincerely.)[/QUOTE]

As far as I understood the message from reb as of 1407 (forum time) or 18 minutes ago. Reb is setting up the 1000 test for 72 to 73 bit. There were a few questions about wether he was loading a doublecheck or not and now he is figuring out the credit per test and after that I expect him to load the 1000 tests :smile:

I hope that Reb will coordinate with you on reservation ranges and where to most optimal attack with what ever ressources BOINC have. If you can help him out on that, then that would be the best help at the moment. Reb has as far as I understand everything both mfaktc and mfakto running on BOINC under windows. :smile:

Thanks for your offer of help :smile:

EDIT: And there is work loaded :smile:

[QUOTE=KEP;540648]Thanks for your offer of help :smile: EDIT: And there is work loaded :smile:[/QUOTE]

I have always been more than willing to help. And I see that 1,000 WUs are now loaded (with 17 in progress).

Perhaps it was a language barrier issue, but the PM exchanges (often CC'ed with you) were very frustrating. He never seemed to parse my answers, but instead simply asked the same questions again (and again, and again...).

Three quick points:

1. Rather than running from 72 to 73, why not simply run straight up to 77 bits?

2. With regards to credit, GIMPS uses GHzD done, and GHzD saved (when a factor is found). Does this map in any way to BOINC?

3. If Reb created an account at GPU72 (as I suggested ***multiple*** times), he could reserve work to then hand out to his clients. This would eliminate the need for GPU72 un-reserving candidates only for Reb to then reserve (with the risk of a LL'er being assigned the candidate during that window).

Very, very cool to see this progress! :tu:

[QUOTE=chalsall;540651]I have always been more than willing to help. And I see that 1,000 WUs are now loaded (with 17 in progress).

Perhaps it was a language barrier issue, but the PM exchanges (often CC'ed with you) were very frustrating. He never seemed to parse my answers, but instead simply asked the same questions again (and again, and again...).

Three quick points:

1. Rather than running from 72 to 73, why not simply run straight up to 77 bits?

2. With regards to credit, GIMPS uses GHzD done, and GHzD saved (when a factor is found). Does this map in any way to BOINC?

3. If Reb created an account at GPU72 (as I suggested ***multiple*** times), he could reserve work to then hand out to his clients. This would eliminate the need for GPU72 un-reserving candidates only for Reb to then reserve (with the risk of a LL'er being assigned the candidate during that window).

Very, very cool to see this progress! :tu:[/QUOTE]



1. Rather than running from 72 to 73, why not simply run straight up to 77 bits?
-yes we can do that later.

2. With regards to credit, GIMPS uses GHzD done, and GHzD saved (when a factor is found). Does this map in any way to BOINC?
-there are fixed credits for an amount of time. If a factor was found, the credits are the same so a bonus.

3. If Reb created an account at GPU72 (as I suggested ***multiple*** times), he could reserve work to then hand out to his clients. This would eliminate the need for GPU72 un-reserving candidates only for Reb to then reserve (with the risk of a LL'er being assigned the candidate during that window).
-created an account at mersenne.org named SRBase

[QUOTE=rebirther;540654]-created an account at mersenne.org named SRBase[/QUOTE]

[B][I][U]***Please***[/U][/I][/B] create an account at [URL="https://www.gpu72.com/signup/"]GPU72[/URL].

There's a reason I've asked you to do this. Multiple times.

[QUOTE=chalsall;540651]I have always been more than willing to help. And I see that 1,000 WUs are now loaded (with 17 in progress).

Perhaps it was a language barrier issue, but the PM exchanges (often CC'ed with you) were very frustrating. He never seemed to parse my answers, but instead simply asked the same questions again (and again, and again...).

Three quick points:

1. Rather than running from 72 to 73, why not simply run straight up to 77 bits?

2. With regards to credit, GIMPS uses GHzD done, and GHzD saved (when a factor is found). Does this map in any way to BOINC?

3. If Reb created an account at GPU72 (as I suggested ***multiple*** times), he could reserve work to then hand out to his clients. This would eliminate the need for GPU72 un-reserving candidates only for Reb to then reserve (with the risk of a LL'er being assigned the candidate during that window).

Very, very cool to see this progress! :tu:[/QUOTE]

It most likely were a language barrier and maybe I should have intervened and maybe I should have been the middle man. English is not the majority of peoples first language. Reb is german and in germany they are not as exposed to the english language as we are in Denmark, not because they don't watch foreign movies, but because the movies are dubbed in german :smile: I must also appologize, I was a too hard on you the other day, you frankly did not deserve that harsh a reply. Sorry :smile:

In regards to 1, I suggested that to Reb. It is possible to do, but the problem really comes when a user finds a factor, then the user will get a lot of free credit. It is (at least to my knowledge) not possible to make a creditsolution in BOINC that takes into account if a workunit is complete after just 50% or less, because a factor is found. It may though end up being such, that we go from 72 to 77 bit, once we get a feeling of the speed we can accumulate. That decision is ultimately Rebs, however we can try to affect his stand :wink:

In regards to 2, I don't really think it does. There is a fixed credit for the workunit, wether it saves 1 or 2 tests. The credit is also the same for a full aswell a partial run. Did I understand your question right?

In regards to 3, that sounds doable, as long as everyone is saved the trouble :smile: Does he has to report the work at GPU72 or is it okay to just report at mersenne.org?

It appears we have already 11 results complete and maybe as much as 60 users running GPU72 :smile:

[QUOTE=KEP;540658]I must also appologize, I was a too hard on you the other day, you frankly did not deserve that harsh a reply. Sorry :smile:[/QUOTE]

Thank you for that. We're cool.

To share, I have a lot of trouble even speaking English to other humans, but it's the only human language I know... :wink:

[QUOTE=KEP;540658]In regards to 3, that sounds doable, as long as everyone is saved the trouble :smile: Does he has to report the work at GPU72 or is it okay to just report at mersenne.org?[/QUOTE]

Just report the results back to Primenet. GPU72 will "observe" the submissions, and update the "situational awareness".

Despite the initial tensions, this is ***really*** cool to see!!! :smile:

[QUOTE=chalsall;540659]Thank you for that. We're cool.

To share, I have a lot of trouble even speaking English to other humans, but it's the only human language I know... :wink:



Just report the results back to Primenet. GPU72 will "observe" the submissions, and update the "situational awareness".

Despite the initial tensions, this is ***really*** cool to see!!! :smile:[/QUOTE]

Phew glad to hear that :smile:

Just a question from Reb, is reservationmethod the same at GPU72 as on this page: [url]https://www.mersenne.org/manual_gpu_assignment/[/url] ?

[QUOTE=KEP;540661]Just a question from Reb, is reservationmethod the same at GPU72 as on this page: [url]https://www.mersenne.org/manual_gpu_assignment/[/url] ?[/QUOTE]

Very similar. It's just code; both George and I can adapt to whatever's needed.

Quick question back: is Reb running Windows or Linux for his back-end? Please see [URL="https://www.gpu72.com/spider/"]this link[/URL] for historical IPC work done. Further customization is always an option.

[QUOTE=chalsall;540659]Despite the initial tensions, this is ***really*** cool to see!!! :smile:[/QUOTE]Thus the ellipses in the thread title.

[QUOTE=chalsall;540663]Very similar. It's just code; both George and I can adapt to whatever's needed.

Quick question back: is Reb running Windows or Linux for his back-end? Please see [URL="https://www.gpu72.com/spider/"]this link[/URL] for historical IPC work done. Further customization is always an option.[/QUOTE]

My memory makes me believe it very well could be a virtual machine running Linux. I don't know BOINC enough to see if that is usefull on the backend. It sure does look interesting though.

[QUOTE=chalsall;540656][B][I][U]***Please***[/U][/I][/B] create an account at [URL="https://www.gpu72.com/signup/"]GPU72[/URL].[/QUOTE]

Excellent.

I see your account creation, and I have raised your "trust" level. You can now reserve up to 1,000 assignments at a time through the [URL="https://www.gpu72.com/account/getassignments/lltf/"]assignment form[/URL].

[QUOTE=chalsall;540666]Excellent.

I see your account creation, and I have raised your "trust" level. You can now reserve up to 1,000 assignments at a time through the [URL="https://www.gpu72.com/account/getassignments/lltf/"]assignment form[/URL].[/QUOTE]

Great :smile:

[QUOTE=KEP;540658]It is possible to do, but the problem really comes when a user finds a factor, then the user will get a lot of free credit. It is (at least to my knowledge) not possible to make a creditsolution in BOINC that takes into account if a workunit is complete after just 50% or less, because a factor is found.[/QUOTE]

OK. So, what might make sense is if the BOINC server hands out work units only taking a candidate up a single bit level at a time. When a worker finds a factor they get a bit of "free" credit. Not the end of the world.

[QUOTE=KEP;540658]It appears we have already 11 results complete and maybe as much as 60 users running GPU72 :smile:[/QUOTE]

I see at [URL="http://srbase.my-firewall.org/sr5/server_status.php"]this page[/URL] 24 users have worked approximately 200 of 1,000 WUs. Once fully completed, appoximately 10 factors should have been found.

Boinc users don't care if a factor is found or not, they want credits.

[QUOTE=chalsall;540674]OK. So, what might make sense is if the BOINC server hands out work units only taking a candidate up a single bit level at a time. When a worker finds a factor they get a bit of "free" credit. Not the end of the world.



I see at [URL="http://srbase.my-firewall.org/sr5/server_status.php"]this page[/URL] 24 users have worked approximately 200 of 1,000 WUs. Once fully completed, appoximately 10 factors should have been found.[/QUOTE]

No, it is not the end of the world. Let's see what Reb finds best once we really gets flying. Is the limit 1000 per user or is it per reservation? :smile:

It appears we currently have 25 users, some wich would be able to complete a test from 72 to 77 bit in little under 5 hours, so it might make sence to go all the way in one test, once Reb get familiar with what the worktodo lines should look like and how much fast equipment we actually have available through BOINC :smile:

[QUOTE=pinhodecarlos;540678]Boinc users don't care if a factor is found or not, they want credits.[/QUOTE]

I'm beginning to sense that perhaps there's a bit of a false economy going on here?

Look! Shiny!

Quick question, how do you guys will avoid cheating?


Results are open even when you don't have an account on the BOINC project, example of an open result:



[URL]http://srbase.my-firewall.org/sr5/result.php?resultid=387733930[/URL]


Can you hide line ''no factor for M105256187 from 2^72 to 2^73 [mfaktc 0.21 barrett76_mul32_gs]''?

[QUOTE=pinhodecarlos;540678]Boinc users don't care if a factor is found or not, they want credits.[/QUOTE]

I'm hoping you're just joking a bit. While it might be true for a certain amount of people, there are plenty of users willing to help certain causes (just like this forum), or like the ease of running the boinc-software. I also prefer the boinc method over scripts and/or manual assignment, purely because it's set-and-forget.

[QUOTE=Stef42;540696]I'm hoping you're just joking a bit. While it might be true for a certain amount of people, there are plenty of users willing to help certain causes (just like this forum), or like the ease of running the boinc-software. I also prefer the boinc method over scripts and/or manual assignment, purely because it's set-and-forget.[/QUOTE]

Not joking...I’m serious. 90% will connect for the badges, credits. Nevertheless, keep feeding the BOINC beast with TF. Soon I’ll start spreading the news so expect the server to be hit more harder than now.

[QUOTE=pinhodecarlos;540678]Boinc users don't care if a factor is found or not, they want credits.[/QUOTE]
Whatever makes their wheels turn, but finding the "right" amount of factors is an indicator that the system is "sane" and that there is no "cheating" going on. If you do TF to 73 or 77, we would still expect a factor in 70..100 trials. If not, then something is fishy. This is not intended to accuse anybody, there were situations in the past when, after tweaking with the code, even PrimeNet used to lose/miss factors. So, watch carefully for a while.

Where to look for the results
 

Will I be able to see the BOINC TF results somewhere on the Prime95 site?

[QUOTE=Chuck;540723]Will I be able to see the BOINC TF results somewhere on the Prime95 site?[/QUOTE]
The user name was given above (SRBase). You can watch it advancing (in both PrimeNet and GPU72 tops) and finding factors.

(edit: or maybe not... I can't find it in GPU72 list. Not updated yet, or different user name? Or is the anon user with ~100 assignments at the end of the top?)
(edit2: ok, there is no user in GPU72 list that was created no long than a week ago and advanced fast, I guess we must wait for the list to update from PrimeNet)

[QUOTE=LaurV;540724]The user name was given above (SRBase). You can watch it advancing (in both PrimeNet and GPU72 tops) and finding factors. (edit: or maybe not... I can't find it in GPU72 list. Not updated yet, or different user name? Or is the anon user with ~100 assignments at the end of the top?)[/QUOTE]

No assignments have yet been fetched by SRBase, so that's why you're not seeing it in any of the lists. Hopefully soon...

[QUOTE=chalsall;540743]No assignments have yet been fetched by SRBase, so that's why you're not seeing it in any of the lists. Hopefully soon...[/QUOTE]

How are these BOINC results being reported to Primenet? Under one userid? SRBase? I can't find any results on GPU72 or Primenet.

[QUOTE=Chuck;540860]How are these BOINC results being reported to Primenet? Under one userid? SRBase? I can't find any results on GPU72 or Primenet.[/QUOTE]

They are coming, as soon as all 1000 results has been completed and is going to be under 1 username. The BOINC user gets the credit for completing the assignment and the project gets the credit at primenet.

We are in a testing phase still, so Reb wants to have all work currently in progress returned, so he can check if something is not right (It appears that for windows everything works flawlessly).

Once we go into full production phase, I hope that the suggestion of returning results for partial completed ranges and reserving and loading new worklines before the last few slow results is submitted - is going to be effectuated. That should thereby make us "never" run out of work and a more regular increase in the credit will be seen.

[QUOTE=KEP;540862]Once we go into full production phase, I hope that the suggestion of returning results for partial completed ranges and reserving and loading new worklines before the last few slow results is submitted - is going to be effectuated.[/QUOTE]

Yes... That is going to be important, particularly considering Reb has asked for (and I have provided) the ability to reserve 10,000 assignments at a time.

It doesn't make sense to have to wait for every last assignment to complete in such large assignment blocks before submitting the results to Primenet. His initial test batch of 1,000 assignments (from Primenet, in 102M) has been held up for days because of (currently) 73 outstanding work-units.

[QUOTE=chalsall;540869]It doesn't make sense to have to wait for every last assignment to complete in such large assignment blocks before submitting the results to Primenet. His initial test batch of 1,000 assignments (from Primenet, in 102M) has been held up for days because of (currently) 73 outstanding work-units.[/QUOTE]

I can't give you the explanation, but it was also what we did back when we worked on setting CRUS up at srbase. Those last stragglers can take their time. But hopefully in 48 hours, we will be ready for production phase. That will hopefully attract some users that only runs SRbase with their GPUs and thereby speed up the processing.

If I did understand Reb correctly (and I'm sure I did) and if Reb understood my reply correctly (I'm sure he did), then because the server removes the completed worklines from an active reservation and leave those with no results remaining, turning in results from partially tested ranges and load new work before we reach 0 and more importantly load more work before we have cleared everything - should be possible :smile: To be honest I can't really see why it shouldn't happen that way, especially with your new coding. I'm like Reb glad that your new code hands out tests with the same bit, this reduces the preprocessing, since credit is almost or entirely the same for each test :smile:

Now we all have to show a little more patience, and then hopefully in the weekend, the last tests with Linux is done and we are good to go with production mode. Anyway how it ends up looking, we will see a huge production increase once we go live :smile:

[QUOTE=KEP;540870]I'm like Reb glad that your new code hands out tests with the same bit, this reduces the preprocessing, since credit is almost or entirely the same for each test :smile:[/QUOTE]

As usual, it's more complicated than that. Credit on Primenet (and GPU72) is a function of both the Exponent as well as the factor depth(s) done.

Here is some Perl code I use to calculate credit (this was adapted from some PHP code James provided to me several years ago):

[CODE]
sub CalculateGHzDaysTF {
my ($Exp, $From, $To) = @_;
my ($GHzDays, $Cnt);

$GHzDays = 0;

for ($Cnt = $From + 1; $Cnt <= $To; $Cnt++) {
$GHzDays += (0.00707 * 2.4) * (2 ** ($Cnt - 48)) * 1680 / $Exp;
}

return $GHzDays;
}[/CODE]

I don't know if Reb can use this for BOINC credit issued to his workers, but there it is.

Does the BOINC server send out each assignment twice (once for double-checking)? If so, can the server be configured to not do that?

[QUOTE=Prime95;540883]Does the BOINC server send out each assignment twice (once for double-checking)? If so, can the server be configured to not do that?[/QUOTE]

Quorum is set to one, no double-check.

The issue might be on the wu deadline, might be too long.

Trying to find those outstanding wus on the project side to confirm wus deadline.

Final edit: deadline is set to 4 days.

[QUOTE=chalsall;540873]As usual, it's more complicated than that. Credit on Primenet (and GPU72) is a function of both the Exponent as well as the factor depth(s) done.[/QUOTE]

I know it is more complicated than that. But for now we know that there is for an exponent n~=105330000 1500 in BOINC credit. From that Reb can calculate backwards and forward using this calculation:

If N is lower than 105330000 then:

(105330000 div average n of testrange)*1500 = credit for each test

If N is higher than 105300000 then:

(105330000 div average n of testrange)*1500 = credit for each test

This should in the first case for n=98000000 to n=99000000 give this calculation:

(105330000 / 98500000)*1500 = 1604 credit per test from 72 to 73 bit

This should in the second case for n=109000000 to 110000000 give this calculation:

(105330000 / 109500000)*1500 = 1443 credit per test from 72 to 73 bit

It all corresponds to the results in the calculation for credit for TF: [url]https://www.mersenne.ca/credit.php[/url] and matches the less effort it takes to calculate 1 bit as n increases (Half the effort every doubleing of n) :smile:

The calculation is the same as above, if we calculate from 73 to 74 bit, then Reb has to multiply by 2. This means that in case 1, 3208 credit is given per test in BOINC and in case 2, 2886 credit is given per test in BOINC :smile:

I've plans to send Reb a more accurate calculation up to n=1,000,000,000 and maybe all the way up to 92 bit - wich I understood long ago is the limit of mfakt(o)(c). Maybe I'll just sent him a calculator or maybe both things, or something else that can make accurate credit for each n possible. I'll discuss that with Reb as we get everything flying. For now, it will be almost accurate credit and most users will end up having the exact same average one way or another, because they stay along for the entire range :smile:

[B]@George:[/B] No the quorum is 1, it will stay like that :smile:

Here a short update:
- the deadline was set to 3d but have forgot the grace_periode +1 option, in this case this means if you are over the deadline there will be no send a new task to another host as long as the first host is sending the result back in time if it was over the deadline
- the quorum is 1
- for these bits (credits) I can easily test it how much time is needed for a range

[QUOTE=rebirther;540944]Here a short update: ... for these bits (credits) I can easily test it how much time is needed for a range[/QUOTE]

Thanks for the update. Can't wait to see production! :tu:

For my own edification (I truly don't know a thing about BOINC)... Why are you doing empirical for the temporal domain? The time it takes for each run will approximately double for each bit level, while decreasing the higher the candidate. As in, a 95M will take more time than a 102M to the same bit level (on, of course, the same GPU). This is what is codified in the Perl I gave you.

There is considerable difference in run times between different GPUs on the same work. Does BOINC consider "wall-clock-time" the "value" (regardless of throughput), unlike GIMPS which awards credit as a function of the work done?

Consider me a (somewhat strange) stranger in a strange land...

[QUOTE=chalsall;540952]Thanks for the update. Can't wait to see production! :tu:

For my own edification (I truly don't know a thing about BOINC)... Why are you doing empirical for the temporal domain? The time it takes for each run will approximately double for each bit level, while decreasing the higher the candidate. As in, a 95M will take more time than a 102M to the same bit level (on, of course, the same GPU). This is what is codified in the Perl I gave you.

There is considerable difference in run times between different GPUs on the same work. Does BOINC consider "wall-clock-time" the "value" (regardless of throughput), unlike GIMPS which awards credit as a function of the work done?

Consider me a (somewhat strange) stranger in a strange land...[/QUOTE]

I need to calculate the range on my reference card. Any cards which are faster can earn more credits than slower cards. Fixed credits are needed against cheating.

[QUOTE=rebirther;540953]I need to calculate the range on my reference card. Any cards which are faster can earn more credits than slower cards. Fixed credits are needed against cheating.[/QUOTE]

Yes, protection against cheating is good. However, I think we hit a language barrier again.

Please Reb, there is no need to calculate on referencecard. You know now, that n~=105,000,000 for 72 to 73 bit is equal to 1500 BOINC credits. This means that for bit 73 to 74 it takes 3000 BOINC credits, for 74 to 75 it takes 6000 BOINC credits, for 75 to 76 it takes 12000 BOINC credit, for 76 to 77 it takes 24000 BOINC credit and for 77 to 78 it takes 48000 BOINC credit.

On a GTX 1070 card it takes ~1000 seconds to test 72 to 73 bit, ~2000 seconds to test 73 to 74 bit, ~4000 seconds to test 74 to 75 bit, ~8000 seconds to test 75 to 76 bit, ~16000 seconds to test 76 to 77 bit and ~32000 seconds to test 77 to 78 bit for n~=105,000,000

At n~=210,000,000 testing time and credit is for the same level of bit 50% of what it was at n~=105,000,000
At n~=420,000,000 testing time and credit is for the same level of bit 25% of what it was at n~=105,000,000
At n~=840,000,000 testing time and credit is for the same level of bit 12.5% of what it was at n~=105,000,000

So as you can see, there really is not that big a need for testing on a reference card :smile:

[QUOTE=KEP;540959]Please Reb, there is no need to calculate on referencecard. You know now, that n~=105,000,000 for 72 to 73 bit is equal to 1500 BOINC credits. This means that for bit 73 to 74 it takes 3000 BOINC credits, for 74 to 75 it takes 6000 BOINC credits, for 75 to 76 it takes 12000 BOINC credit, for 76 to 77 it takes 24000 BOINC credit and for 77 to 78 it takes 48000 BOINC credit.

On a GTX 1070 card it takes ~1000 seconds to test 72 to 73 bit, ~2000 seconds to test 73 to 74 bit, ~4000 seconds to test 74 to 75 bit, ~8000 seconds to test 75 to 76 bit, ~16000 seconds to test 76 to 77 bit and ~32000 seconds to test 77 to 78 bit for n~=105,000,00[/QUOTE]

Be careful here. At different bit levels, the program may use different kernels, and as a result, at higher bit levels it might take more time than the simple doubling you used. To complicate matters, AMD card (mfakto) has different points at which the kernel change happens compared to Nvidia (mfaktc)

If the objective is to ensure that a given GPU earns the same credit/hour regardless of bit level, you absolutely must benchmark every bit level on reference cards. Not only that, you might find that AMD card earns different credit that Nvidia card for the same WU.

Mainly, Chris and Kep say the same thing with different words.

A testing on any card should not be needed. The "credit" should only depend on the output, regardless of what hardware one has.

Both methods of calculating, from Kep and Chris, are satisfactory. Nobody would care about one or two credits more or less.

Does BOINC clients report the hardware they have? If so, a test on a "reference" card could be done to be able to check if the reported results are in the reasonable "ballpark", but that is not mandatory, and not much relevant. A cheater could still use his card for other things half of the time ans still cheat, if he wants. That's why I said that the number of factors reported should be watched.

Reb's English looks quite good to me (non-native too).


Let's see the production. :flex:

[QUOTE=LaurV;541017]Does BOINC clients report the hardware they have? If so, a test on a "reference" card could be done to be able to check if the reported results are in the reasonable "ballpark", but that is not mandatory, and not much relevant. A cheater could still use his card for other things half of the time ans still cheat, if he wants. That's why I said that the number of factors reported should be watched.[/QUOTE]

No, they do not directly report that. You can however see on the computerspecs what GPU each computer has, but it may not be nescessary, because over all what means a few credit more or less :smile:

Yes Rebs english is well enough, sometimes just like you mentioned with credit, we explain ourself with different words, but do in fact say almost or exactly the same as the other :smile: ... that's one of the oddities of human language :smile:

[QUOTE=axn;541014]Be careful here. At different bit levels, the program may use different kernels, and as a result, at higher bit levels it might take more time than the simple doubling you used. To complicate matters, AMD card (mfakto) has different points at which the kernel change happens compared to Nvidia (mfaktc)

If the objective is to ensure that a given GPU earns the same credit/hour regardless of bit level, you absolutely must benchmark every bit level on reference cards. Not only that, you might find that AMD card earns different credit that Nvidia card for the same WU.[/QUOTE]

Okay, but will it be more than 10% slowdown at higher bit levels?

My ancient (6-8 year old ASUS gpu, now retired), only showed 10% slowdown at 75+ bit.

Maybe it is a good idea, that Reb benchmark all bit levels at n=105M and then we use the credit at each bit level for n=105M, as reference to calculate the credit for future test n. Will that be more accurate?

Does higher n also need to be benchmarked or is the ((105M/test_n)*credit_at_current_bit_level_for_n=105M) still accurate enough for n=999M?

[QUOTE=KEP;541024]Does higher n also need to be benchmarked or is the ((105M/test_n)*credit_at_current_bit_level_for_n=105M) still accurate enough for n=999M?[/QUOTE]

No need for different n. As you said, it is just simple scaling. But bit levels, yes. And for Nvidia and AMD differently.

However, I am not sure the exact difference in performance -- probably on the order of 10-15%.

[QUOTE=axn;541030]No need for different n. As you said, it is just simple scaling. But bit levels, yes. And for Nvidia and AMD differently.

However, I am not sure the exact difference in performance -- probably on the order of 10-15%.[/QUOTE]

But will that difference not just mean that the Nvidia cards make more than the AMD cards and therefor also should and will earn more credit a day than an AMD card does? I don't really think that it will be possible to make differentiated (? spelling) credit for Nvidia versus AMD cards.

[QUOTE=KEP;541032]I don't really think that it will be possible to make differentiated (? spelling) credit for Nvidia versus AMD cards.[/QUOTE]
Hmmm... This could be an issue. I guess, once you have benchmark data, then the extent of the issue can be quantified.

[QUOTE=axn;541034]Hmmm... This could be an issue. I guess, once you have benchmark data, then the extent of the issue can be quantified.[/QUOTE]

Yeah let's wait and see. I just assume without having anything to base it upon, that if the Nvidia cards are faster, they just make more work and hence get more credit.

Am I missing something or are the amount of calculations for the exact same n, not the same for an AMD and Nvidia card? ... if yes, then credit should scale to both cards, since the Nvidia will compute more per day and then get more credit compared to the AMD that will compute less :smile:

[QUOTE=KEP;541038]Am I missing something or are the amount of calculations for the exact same n, not the same for an AMD and Nvidia card?[/QUOTE]

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.

[QUOTE=chalsall;541042]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.[/QUOTE]

Phew, glad that my logical understanding of the need for calculations was correct.

Good that the credit was not reduced for GPUs, it would be the same as saying, just because 1 person is running 10 times faster compared to another person, the faster person would only be counted for 1 marathon each time that individual completes 10 marathons. A debate is always good, since it gets all perspectives and opinions out in the open, but fortunantly here, the debate failed to punish the GPUs for doing a lot more work than my i5-4670 would do. Actually some of the most productive GPUs is currently 60 times faster than my i5-4670 and 40 times faster than my no longer working GPU. So out of fairness they should also be given 60 times the credit each day, compared to my i5 :smile:

New work added, bit 72-73, I think I got all in this range which was available.

[QUOTE=rebirther;541056]New work added, bit 72-73, I think I got all in this range which was available.[/QUOTE]

Cool. Nice to see. And, yes... You took all 9,535 candidates available. Glad to see my code actually worked the first time you tried it! :wink:

Hopefully next time you'll take some to go to 77... :smile:

[QUOTE=rebirther;541056]New work added, bit 72-73, I think I got all in this range which was available.[/QUOTE]

Great work Reb. Nice to see how you have progressed in the past weeks. Now I really am looking forward to see how much work BOINC can actually do :smile:

EDIT: I just noticed that you are have stop after factor is found on some of your results, but not all results, is the .ini file for mfakto different from the .ini file for mfactc?

[QUOTE=KEP;541061]Great work Reb. Nice to see how you have progressed in the past weeks. Now I really am looking forward to see how much work BOINC can actually do :smile:

EDIT: I just noticed that you are have stop after factor is found on some of your results, but not all results, is the .ini file for mfakto different from the .ini file for mfactc?[/QUOTE]


yes it was set: StopAfterFactor=1

[QUOTE=rebirther;541062]yes it was set: StopAfterFactor=1[/QUOTE]

The ini file, for mfact(o)(c) needs to be:

StopAfterFactor=2

Its not much of a deal, but it will speed up processing a little more, since we achieved the goal of finding a factor and eliminating a composite test.

Nice work, with a whopping 103 hosts currently connected :smile:

[QUOTE=KEP;541066]Nice work, with a whopping 103 hosts currently connected :smile:[/QUOTE]

Where can we see that? Is it available on a public facing page?

[QUOTE=chalsall;541067]Where can we see that? Is it available on a public facing page?[/QUOTE]

It is an assumption based on the fact that each host is limited to 3 task per host for GPU72. So there may be more, but at least 120 hosts in current moment and still growing :smile:

You can follow the sent workunits here: [url]http://srbase.my-firewall.org/sr5/server_status.php[/url]

There may be a place on the various statistical sites for BOINC projects, but to be frank I don't know if we can see the exact amount of host currently processing work for GPU72 at BOINC.

[QUOTE=KEP;541069]You can follow the sent workunits here: [url]http://srbase.my-firewall.org/sr5/server_status.php[/url][/QUOTE]

That's where I'm looking. I see 14 users in the last 24 hours. Do the current users really have ~8.5 computers each?