Possible extention to the "GPU to 72 Tool" project?

[davieddy]

Originally Posted by diamonddave

Software change and get better... Why wouldn't CUDALucas get so much better that doing any LL on GPU wouldn't be wasteful.

[chalsall]

Originally Posted by diamonddave

Software change and get better... Why wouldn't CUDALucas get so much better that doing any LL on GPU wouldn't be wasteful.

When (if?) that happens, the metrics once again change and a re-evaluation will happen.

At this point in time, it is far more efficient to have GPUs do TF, and CPUs do LL / DC (or P-1).

Also, please note, to the best of my knowledge, no low candidates were ever LLed by any program other than Prime95 or mprime.

But, as always, I'm happy to be corrected.

[chalsall]

Originally Posted by davieddy

Smile back...

Live's What you Make It

[lycorn]

Originally Posted by diamonddave

If I like to TF number or do LL, DC or god forbid do OBD or further TF on already DCed exponent. I think, those who pay for the hardware and electricity should have the right to do as they please?

Sure "they" (we all) have, and have always had.

Originally Posted by diamonddave

Coming here and asking for a legitimate feature, given the problem encountered by the user. But being rebuked with a, "why don't you do something else" is not very helpful.

What you mean "rebuked"? I was only suggesting a way of overcoming the issue raised by LaurV himself, not by me...

Originally Posted by diamonddave

Software change and get better... Why wouldn't CUDALucas get so much better that doing any LL on GPU wouldn't be wasteful.

CUDALucas is already good at LL testing. That´s not the point. That´s why I suggested doing LLs on a GPU. But being first timers avoids the problem of determining the origin of the first result, once there isn´t any.

Originally Posted by diamonddave

Please let him or them determine what is too much trouble

As you can see from chalsall´s response, the request would require an exaggerated amount of work for what it is worth. And in his post, LaurV was already admitting that managing that manually would be a large task for himself. So...
Keep cool man, we both are around here for enough time so that you should already know me well enough to hint that I was dismissing or "pushing" someone to do this or that. That´s not my style, and I think it was apparent from my post that the idea was just being helpful to a "fellow cruncher".

[Uncwilly]

Originally Posted by diamonddave

If I like to TF number or do LL, DC or god forbid do OBD or further TF on already DCed exponent. I think, those who pay for the hardware and electricity should have the right to do as they please?

Or even work on the 100M digit range.

[lycorn]

Originally Posted by lycorn

(...) so that you should already know me well enough to not hint that I was dismissing or "pushing" someone to do this or that.

Typo corrected...

[LaurV]

Originally Posted by Uncwilly

Or even work on the 100M digit range.

It can't. CudaLucas is limited to about half of that size for the exponent :P

[James Heinrich]

Originally Posted by LaurV

It can't. CudaLucas is limited to about half of that size for the exponent :P

But Uncwilly can, he has no such limitations.

[LaurV]

Just produced the 4th factor overnight. If it continues like that, I will break even, and then I will not be in the position to argue anymore
I just saw on the overall report a new drop, from 197 to 192 Gd/factor on DC front. It just pops under my hair that in fact, my "error" in the beginning, when I was (stupidly) factoring DC front to 72 bits (see above in this thread) is heavily weighting on that number. There were 11 exponents, with an additional ~35Gd for each (additional unwanted work done from 69 to 72), that is about 385Gd, which means about 18Gd for each of the 21 factors found to date. So, the "real profitability" of DC-front factoring should be about 174Gd/factor, or about 1.7 days. We are coming close to breakeven.

[petrw1]

Originally Posted by chalsall

BTW, the Low Double Check work type is now available as well.

I noticed in today's LL availability report there is one 49M candidate without P-1 and only(?) at 69 bits. Wasn't the intent to TF a lot deeper (hence the projects name) before releasing to LL?

Also the DC availability shows 100 in the 25M range but the Active Assignments report in GIMPS show you only have 35. Is my problem just timing; i.e. did someone grab 65 in the last hour?

[chalsall]

Originally Posted by petrw1

I noticed in today's LL availability report there is one 49M candidate without P-1 and only(?) at 69 bits. Wasn't the intent to TF a lot deeper (hence the projects name) before releasing to LL?

Yes. This is the opposite result of the "race condition" which I described to davieddy in post # 181 above. My "anonymous" spider grabbed an "interesting" candidate which my "GPU Factoring" spider had not only a couple of seconds earlier.

These will scroll off (and hopefully be picked up again by "Spidy") as additional lower candidates are completed by GPU / P-1 workers.

Originally Posted by petrw1

Also the DC availability shows 100 in the 25M range but the Active Assignments report in GIMPS show you only have 35. Is my problem just timing; i.e. did someone grab 65 in the last hour?

I'm note entirely sure what report you are looking at. http://www.mersenne.org/primenet/ shows ~3200 DCs assigned at the moment.