GPU72 and BOINC a match made in ....

[chalsall]

Originally Posted by KEP

...but untill there is adequate room between the wavefront of TF and the various FC and P-1 wavefronts, I would sure appreciate if we wavered that part of TF for the next time being.

Please trust me on this. I understand resource management in the temporal domain. It's what network engineers do...

[axn]

Originally Posted by chalsall

Further, the opposite argument to yours can be made. If we have TF'ing resources that aren't going to be redirected to FC'ing, should they optimally TF the ranges years ahead of the wavefronts? Or should they instead TF past the optional only a few months ahead?

I would argue the latter, where people are willing.

I am retroactively in agreement with you , to wit

Originally Posted by axn

Unless the BOINC project hands out LL tests as well, there is no point in calculating optimum bit level using traditional metric.
<snip>

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)

However, we should also be mindful of BOINC WU runtimes. Actually, on that front, I was thinking that maybe we should slice up a large bitrange by fractional bit depths / k range rather than by residue classes. Like 77-77.5, 77.5-78, etc. I think it would be easier to implement.

[Prime95]

The primenet database supports fractional bit levels. Manual results processing and perhaps some other PHP routines, probably not. I think prime95 worktodo lines recognize fractional bit levels. Not sure about gpuowl, mlucas, others.

[axn]

Originally Posted by Prime95

The primenet database supports fractional bit levels.

That is actually good news.

But, to be clear, I'm not suggesting that we start doing fractional bit TFs from PrimeNet's perspective. The idea is still to do full bit levels, but break them up into fractional WU in BOINC world. Then report the final whole bit result to PrimeNet. This would need (hopefully) minor modifications to mfakc/o, and minor-to-medium changes in the SRBase backend.

EDIT:- The halfway mark between 77 and 78 bits is 77.585 bits.

[pinhodecarlos]

Originally Posted by axn

That is actually good news.

But, to be clear, I'm not suggesting that we start doing fractional bit TFs from PrimeNet's perspective. The idea is still to do full bit levels, but break them up into fractional WU in BOINC world. Then report the final whole bit result to PrimeNet. This would need (hopefully) minor modifications to mfakc/o, and minor-to-medium changes in the SRBase backend.

EDIT:- The halfway mark between 77 and 78 bits is 77.585 bits.

Love this idea. Short, medium and long tasks. I would put my low GPU to the lower bits.

[lalera]

hi,
i do not like the idea of fractional bitlevels
fractional bitlevels do not bring better performance
every time a wu is starting the program starts
for mfaktc long running tasks (several hours - not several days) are better for the gpu

mmff for double mersenne (based on mfaktc) can do fractional bitlevels
it makes sense because a bitlevel could take weeks or longer to complete

[chalsall]

Originally Posted by pinhodecarlos

Love this idea. Short, medium and long tasks. I would put my low GPU to the lower bits.

Yeah, I think it's a really good idea. I hope Reb can do it.

Over on SRBase there are already different classes of work available for their S/R projects. The Long is averaging ~41 hours at the moment.

GPU72 (currently going to 78 bits) is averaging 5 hours, so breaking the higher bit levels down probably won't actually be needed. Going to 81 bits would take a similar ~40 hours.

[rebirther]

Originally Posted by chalsall

Yeah, I think it's a really good idea. I hope Reb can do it.

Over on SRBase there are already different classes of work available for their S/R projects. The Long is averaging ~41 hours at the moment.

GPU72 (currently going to 78 bits) is averaging 5 hours, so breaking the higher bit levels down probably won't actually be needed. Going to 81 bits would take a similar ~40 hours.

Sorry, no more subapps, I have to manage 60+ with SRBase, if there is a new app you need to create all apps again and for new projects or every sub app I must create new server daemons. After this 77-78 run I will go back to 73-74 and rushing step by step though the bit levels.

[chalsall]

Originally Posted by rebirther

After this 77-78 run I will go back to 73-74 and rushing step by step though the bit levels.

Well, it's a good thing GPU72 has quite a bit of firepower of its own, willing to do what's actually immediately needed rather than just what's easy.

Edit: Actually, could you please change the name of your sub-project over on SRBase? You're using my Service Mark without permission. Perhaps GIMFS would be more appropriate.

[kracker]

Originally Posted by chalsall

Well, it's a good thing GPU72 has quite a bit of firepower of its own, willing to do what's actually immediately needed rather than just what's easy.

Edit: Actually, could you please change the name of your sub-project over on SRBase? You're using my Service Mark without permission. Perhaps GIMFS would be more appropriate.

Suggestions and recommendations are nice to consider and follow, but you should be happy and appreciative of firepower - wherever it is put to use by other people for whatever reason they may have.

[chalsall]

Originally Posted by kracker

Suggestions and recommendations are nice to consider and follow, but you should be happy and appreciative of firepower - wherever it is put to use by other people for whatever reason they may have.

Sure. But like I said above, GPU72 is about helping GIMPS. It is ***not*** GIMFS.

I feel I have wasted several days of time, being misled about what SRBase was actually going to deliver. Now I need to figure out where the needed "heavy-lifting" firepower is going to come from...