GPU to 72 status...

[davieddy]

Originally Posted by Dubslow

Since when is any of this new? chalsall currently assigns P-1 after 72 bits is complete, as he just said above me.

All Good!

[petrw1]

Originally Posted by chalsall

But... I have changed the P-1 assignment strategy slightly such that if there are no candidates TFed to 72 which need P-1 work done, those TFed to 71 will be assigned.

I'm a little confused. When I was doing P-1 here the current TF bit level did NOT influence me or regulate me in any way. When I needed P-1 I simply took what interested me (and was freely allowed to do so) whether that was the highest TF'd assignments available (even if that meant 70 bits); or whether it was any P-1 available in the 45M range (even as low as 69 bits).

Was I unknowingly violating some principle?

[davieddy]

Originally Posted by petrw1

Was I unknowingly violating some principle?

You know perfectly well.
We all do it round here.

Archimedes Screw

[chalsall]

Originally Posted by petrw1

Was I unknowingly violating some principle?

Not at all. At least, not as far as I'm concerned.

I believe that people donating their cycles to GIMPS should be allowed and encouraged to do whatever work they enjoy doing so long as it doesn't harm others (read: "poaching").

My adjustment to the assignment strategy is simply that rather than reporting back to the requester that assignments aren't available, the system will now assign work which has not been TFed to 72 is such work is not available.

As always, requesters can adjust the bounds to get work in certain regions, and can always unassign work if they don't want to do what they've been assigned.

[flashjh]

Originally Posted by chalsall

Not at all. At least, not as far as I'm concerned.

I believe that people donating their cycles to GIMPS should be allowed and encouraged to do whatever work they enjoy doing so long as it doesn't harm others (read: "poaching").

My adjustment to the assignment strategy is simply that rather than reporting back to the requester that assignments aren't available, the system will now assign work which has not been TFed to 72 is such work is not available.

As always, requesters can adjust the bounds to get work in certain regions, and can always unassign work if they don't want to do what they've been assigned.

I noticed the 'notice' about "P-1 to less than 72 meant more work (unless a factor is found)" was gone and the system now defaults to the range that is available. I've seen it default to 70 and 71 lately.

[chalsall]

Originally Posted by flashjh

I noticed the 'notice' about "P-1 to less than 72 meant more work (unless a factor is found)" was gone and the system now defaults to the range that is available. I've seen it default to 70 and 71 lately.

Yes. The "Minimum TF level" on the form is now 70, but the system has enough P-1 candidates now that it always hands out work TFed to at least 71 unless the "Optional Range" fields are changed to a region which don't have candidates available at the higher TF levels.

The "feature" of only assigning P-1 work TFed to 72 was put in place from the beginning of the G72 project at the request of "Mr. P-1" who used to coordinate all this TF and P-1 work manually. (I can't imagine -- it's hard enough keeping Spidy well behaved!!!)

But I've found that this assignment strategy is actually causing more confusion than it's worth since we've found ourselves with so much P-1 fire power. And a P-1 requester can still change the minimum back up to 72 if they so desire.

So, that's why the assignment strategy has been adjusted for P-1.

(BTW, just in case not everyone has noticed, the Monthly Overall System Progress Graphs now includes P-1 statistics, and a graph of factors found per day for each work type.)

[flashjh]

I know it's already on your to-do list, but when you're able to update the view assignments page to export assignments, is there any way to add a 'worktodo balancer' like on James' site so that we can split similar assignments into several workers with the oldest assignment split across the top of each worker? James' works for breaking into workers quite well but it has no way of sorting by oldest assignment, which would come in handy (at least for me) .

Thanks,

Jerry

[ckdo]

We have just finished DCTF on exponents below 26M (for the time being).

[Mini-Geek]

Originally Posted by flashjh

I know it's already on your to-do list, but when you're able to update the view assignments page to export assignments, is there any way to add a 'worktodo balancer' like on James' site so that we can split similar assignments into several workers with the oldest assignment split across the top of each worker? James' works for breaking into workers quite well but it has no way of sorting by oldest assignment, which would come in handy (at least for me) .

Thanks,

Jerry

I'd like to second this request. I've been manually moving the oldest ones to the top of the worktodo so they won't expire.

[petrw1]

GPU-to-72 team is now 5th TF for the last 365 days and 10th lifetime.

[kladner]

Originally Posted by petrw1

GPU-to-72 team is now 5th TF for the last 365 days and 10th lifetime.

WOOHOO!

And 9th for P-1 (last 365)!