[QUOTE=Dubslow;306828]I seriously disapprove of this. Poaching a double check is quite a bit worse than poaching an LL; you'd be rendering the original assignee's work useless, as LaurV points out.[/QUOTE]
Except in the case where the LL test poached turns out to be a prime.

[QUOTE=petrw1;307273][URL]http://www.mersenne.org/assignments/[/URL][/QUOTE]

This is an interesting range (23-24M):
[url]http://www.mersenne.org/assignments/?exp_lo=23000000&exp_hi=24000000&execm=1&B1=Get+Assignments[/url]

All are Manual. All regularly update. All are over 900 days old. All are assigned to "Captain Entropy". None show progress. Perhaps "Captain Inertia" or "Captain Friction" would be a better handle.

[QUOTE=kladner;307275]This is an interesting range (23-24M):
[url]http://www.mersenne.org/assignments/?exp_lo=23000000&exp_hi=24000000&execm=1&B1=Get+Assignments[/url]

All are Manual. All regularly update. All are over 900 days old. All are assigned to "Captain Entropy". None show progress. Perhaps "Captain Inertia" or "Captain Friction" would be a better handle.[/QUOTE]

Indeed.

[QUOTE=Dubslow;307302]Indeed.[/QUOTE]

And, perhaps worth noting, all "poached"....

CaptainEntropy does seem to send in results, he's still in the top500 LL-D
442 CaptainEntropy 431.276 14 12

[QUOTE=sonjohan;307214]I get it that poaching is not supposed to happen, but how can we advance the milestones faster?[/QUOTE]
Perhaps it's a bit like saying that we know there's a speed limit on the road, but how can we get from A to B faster? I would say that we probably can't advance the milestones faster than we are doing in any legitimate way. Also, I would question whether it would be of any serious psychological benefit to us if we did manage to. Okay, the milestones would be attained more quickly, but only to be replaced by other milestones. We might possibly find M48 faster (not necessarily though, it depends where M48 is hiding!), but then the search for M49 would bug us just as much as M48 is doing now.

[QUOTE=Brian-E;307330]I would say that we probably can't advance the milestones faster than we are doing in any legitimate way.[/QUOTE]

Well I think we could come to terms with this problem (for the future) with small changes in the assignment policy. Lets say we had 3 different kinds of LL assignments: Fast-LL, Medium-LL and Slow-LL.

Fast-LL: The LL or D should be completed within two months, otherwise there will be an obligatory, automatic, reassignment, for 53M and smaller.

Medium-LL: The LL or D should be completed within 6 months, otherwise there will be an obligatory, automatic, reassignment, for 53M - 58M.

Slow-LL: The LL or D assignment can be prolonged as long as there are regular updates and progress. If not completed within 3 years there will be an obligatory, automatic, reassignment, for 59M and onwards.

You can aquire a Fast-LL or a Medium-LL or a Slow-LL depending on your specific computer. And you need to update all assignments in the same way as now.

And as the wave progresses there will be changes of fields for the three different types.

What I am saying is not that it need to be in exactly this way, but I am just pointing out that we can invent a way of distributing assignments which would make the wave more narrow and the progress towards milestones faster. Well, all those persons hoarding small assignments will oppose I suppose.

[QUOTE=aketilander;307339]What I am saying is not that it need to be in exactly this way, but I am just pointing out that we can invent a way of distributing assignments which would make the wave more narrow and the progress towards milestones faster. Well, all those persons hoarding small assignments will oppose I suppose.[/QUOTE]
It's a good idea. If I understand correctly, it's already being done in the sense that "preferred" exponents are not given to slow machines or users who have not already shown themselves to be reliable contributors (am I right? anyone?).

But there will always be outliers. Jobs which on paper should have been finished quickly but are not. Users who used to turn in quick results but have had life changes or what have you. Forcibly reassigning these will lead to a lot of lost work. In a project with many thousands of participants, there will always be serious stragglers behind the wave front no matter what the assignment policy is.

[QUOTE=Brian-E;307341]It's a good idea. If I understand correctly, it's already being done in the sense that "preferred" exponents are not given to slow machines or users who have not already shown themselves to be reliable contributors (am I right? anyone?).

But there will always be outliers. Jobs which on paper should have been finished quickly but are not. Users who used to turn in quick results but have had life changes or what have you. Forcibly reassigning these will lead to a lot of lost work. In a project with many thousands of participants, there will always be serious stragglers behind the wave front no matter what the assignment policy is.[/QUOTE]

Well the assignment rules haven't been updated in a while! At least a year.

Preferred exponents are below:
LL: 45,000,000 only 161 remaining
CD: 26,000,000 only 84 remaining

They used to be kept at 1k-2k. What good are those threshold if they are never updated? Same with the assignment rules which are never enforced?

[QUOTE=diamonddave;307345]What good are those threshold if they are never updated? Same with the assignment rules which are never enforced?[/QUOTE]

Completely agree.

I personally find it very frustrating when I see low candidates processed by the GPU72 system be released back to Primenet, only to be claimed by "Anonymous". Considering that only approximately 20% of all LL/DC assignments are ever completed it's going to take a long time before all the low candidates are actually finished with the cut-offs as they are.

I would advocate the new "Preferred" cut-offs should be 50M for LL, and 29M for DC.

I would rather you kept the region in front of the LL wave tidy, and left the tail to look after itself.
Poach those lingering TF assignments, and tell George to get Primenet to get its act together.

D