GPU72 / MISFIT use for 100M digit range?

[LaurV]

Originally Posted by Uncwilly

Feedback? Ideas?

Agree with the ranges, bit numbers, written in that post (like, 74, 78, etc), in fact you put a lot of effort into coordinating that range and you know what you are talking about. Totally makes sense for me.

Small observation: P-1 should be done somehow before we go the last bits (like 81?? 82?? 84??) according with what George said long ago, related to the CPU factoring. Using the GPU raises the bitlevels but does not change the concept: doing bit n still takes double of time comparing with doing bit n-1.

[axn]

Originally Posted by LaurV

Small observation: P-1 should be done somehow before we go the last bits (like 81?? 82?? 84??) according with what George said long ago, related to the CPU factoring. Using the GPU raises the bitlevels but does not change the concept: doing bit n still takes double of time comparing with doing bit n-1.

That analysis might not hold anymore. The higher bit levels achieved by GPU means that the optimal P-1 bounds will be smaller, and hence P-1 probability of success will be smaller. It would be better from organization perspective to just do the whole TF on GPU and then the P-1.

Need moar data!!!!

[chalsall]

Originally Posted by Uncwilly

Sure, let GPUto72 work in the range. The help from some GPU's will be great.

OK, I have started bringing in candidates. At the moment I'm only bringing in candidates at 73 or below. This is to leave some for CPUs to grab from Primenet -- for either TFing, P-1ing or LLing.

I've added a new table to the "Available" report, which I'll expand to show a larger range to TF levels.

These are available immediately from the LLTF form. I'll expand the from to have "bit-wise" or "depth-wise" options, but right now everyone has access to the candidates by simply changing the low to "332000000" and the high to (say) "1000000000".

Any MISFIT / fetcher users can also start immediately. Again, just set the bit level (default of 73 is fine; 82 if you want to go depth), and the low and high as above, and you'll be issued the work.

Originally Posted by Uncwilly

At least until further notice, the bit-wise testing should stay in the 332 range, until the minimum bit level above 332192831 reaches at least 74.

Copy that.

Originally Posted by Uncwilly

The depth-wise commitment should be at least 78 (at first while demand is high for exponents to LL), ideally 80 or 81 (later). If there is anyone that wants to do P-1's, that would be great too.

I use PrimeNet, as noted here: http://mersenneforum.org/showthread.php?t=11308

I will probably continue to use that method on at least 2 of my machines. If I can get to of my borged machines to use an automated system to fetch work, I would love to.

OK. I'll extend the proxy to hand out these assignments to Prime95/mprime clients which ask for LMH work. For these (because CPUs really shouldn't be doing much of this TFing) it will be bit-wise, one additional bit, lowest TF level.

Originally Posted by Uncwilly

Feedback? Ideas?

Thanks for your guidance on this. I know many people have been wanting to do this type of work in a coordinated and automated way.

And LaurV, while Spidy will detect any "unreserved" work you do and update the bit levels, it would be good if you stopped any work you're doing currently and start reserving and working these. Wouldn't want any sore toes...

If anyone sees any SPEs or other issues, please let me know.

[chalsall]

Originally Posted by chalsall

I'll expand the from to have "bit-wise" or "depth-wise" options...

OK, this has now been done. Note that after choosing "bit-wise" or "depth-wise", the Low and Pledge fields are updated. "depth" is currently 78, but can be manually raised if desired. (Note that I mis-read Uncwilly above -- according to James the highest level these should be taken is 81, not 82.)

Also please note that after choosing one of these two new options, the option pull-down is reset back to "WMS". This is so people can then additionally refine their request for, for example, "Lowest TF", "Highest TF", etc. Choosing "Let GPU72 decide" will reset the ranges back to nominal (read: Low=0; Pledge=73).

Lastly Scott, I don't think there's any need for any code changes for MISFIT / fetcher users. Simply adjusting the ranges will suffice (assuming the "High" field can go past 100,000,000).

[swl551]

Once the assignments come back from the fetcher is there a need to merge them into P95's workTodo.add? (which cpu gets which assignments ETC).

[chalsall]

Originally Posted by swl551

Once the assignments come back from the fetcher is there a need to merge them into P95's workTodo.add? (which cpu gets which assignments ETC).

For P95 usage, if worktodo.add exists, the fetcher shouldn't fetch. There's a race-condition... You can't tell when P95 is going to import the file.

I'm also going to modify the existing Proxy to allow Prime95/mprime clients to (in-)directly request these candidates using the existing LMH option.

[swl551]

Originally Posted by chalsall

For P95 usage, if worktodo.add exists, the fetcher shouldn't fetch. There's a race-condition... You can't tell when P95 is going to import the file.

I'm also going to modify the existing Proxy to allow Prime95/mprime clients to (in-)directly request these candidates using the existing LMH option.

Does worktodo.add require the assignments to be organized in a certain way. (sections, headers, groupings etc)

[chalsall]

Originally Posted by swl551

Does worktodo.add require the assignments to be organized in a certain way. (sections, headers, groupings etc)

The format is exactly like worktodo.txt. The "headers" are "[Worker #n]", where n is the worker which should be given the work. If there are no "[Worker #n]" headers, all work will be given to Worker #1.

[swl551]

Originally Posted by chalsall

The format is exactly like worktodo.txt. The "headers" are "[Worker #n]", where n is the worker which should be given the work. If there are no "[Worker #n]" headers, all work will be given to Worker #1.

in the fetcher's config file set

ReloadWhenBelow:0

File.NOTExist is treated as 0 for this setting.

and let it roll.


I'll wait to hear back from the users.

[chalsall]

Originally Posted by chalsall

At the moment I'm only bringing in candidates at 73 or below. This is to leave some for CPUs to grab from Primenet -- for either TFing, P-1ing or LLing.

Actually, having now fully "trained" "Spidy" for this range and let it work for a while, I have discovered there aren't any candidates above 73 which are not already assigned.

I've now told it to not keep candidates above 72 below 332,350,000. This gives Primenet 884 candidates at 73 bits to assign for LLing while we work above.

[Chuck]

OK I took one of these just for fun...I have not factored above 73 before.

Factor=N/A,332350xxx,73,78

Edit by chalsall: Cool. Thanks. But please never reveal your assignments.