[QUOTE=cheesehead;221797] Note again, as I said before, that GIMPS specifically and officially pledges to try to preserve that exclusivity, although it must also inform the user that it cannot completely prevent that exclusivity from being violated.

Anyone who argues that poaching should be acceptable in some circumstance or other is directly contradicting a clause of the license by which GIMPS granted them permission to use GIMPS software.

Any user of prime95 or mprime who advocates poaching in any circumstance is advocating a violation of their license to use that software!

Any advocate of poaching should cease using prime95, mprime, or any other GIMPS software to which the license applies.[/QUOTE]

Where does it say/imply any of this?

[QUOTE=cheesehead;221797]Show it, then. Tell us you respect the GIMPS software license and its promise to prevent poaching as far as possible.[/QUOTE]

Please calm down cheesehead...

I have been a GIMPS participant for ten years. I am currently ranked 10th top contributor overall, and 1st for factoring, over the last year.

I respect the "unofficial" rules of conduct which GIMPS participants try to follow. Please do note [B][I][U]unoffical[/U][/I][/B].

But to speak to your straw man, let me please quote directly from the mprime license.txt file:

[I]Every effort has been made to ensure that you will be assigned an exponent that no one else has tested or is testing. We are not responsible for lost prize money, fame, credit, etc. should someone accidentally or maliciously test the number you are working on and find it to be prime. We are not responsible should the program determine a number composite even though it is prime - the program's heavy use of memory and FPU could trigger an error that goes undetected.[/I]

Clearly and empirically, George et al don't take poaching as seriously as you do....

[quote=chalsall;221801][I]Every effort has been made to ensure that you will be assigned an exponent that no one else has tested or is testing.[/I][/quote]No straw at all, axn and chalsall -- it's right there in the first sentence:

"Every effort has been made to ensure that you will be assigned an exponent that no one else has tested or is testing."

Didn't you notice that that pledges to prevent poaching (insofar as possible, of course -- but that's farther than many of you have granted)?

It's even official rather than unofficial!

The wording could be improved (such as using more active, and less passive), but I don't think it's beyond the abilities of folks discussing poaching to see how that sentence applies.

[QUOTE=cheesehead;221805]"Every effort has been made to ensure that you will be assigned an exponent that no one else has tested or is testing."

Didn't you notice that that pledges to prevent poaching (insofar as possible, of course -- but that's farther than many of you have granted)?[/QUOTE]

That's just a CYA disclaimer written in legalese. It should be interpreted along with the following sentences.
It is not in the best interest of GIMPS to promise any such thing, lest it open itself up to legal troubles (unless of course, there is a foolproof way to prevent poaching). Now, George may unofficially want to promise such thing, but officially, I don't think so.

Secondly, a typical EULA will have a section for "ACCEPTABLE USE". I would think that it would be a simple matter to add this section, explicitly prohibiting "poaching". Of course, for such a thing to happen, GIMPS must consider itself the owner of all these exponents. Otherwise, on what moral authority could such a condition be made?

EDIT:- Lastly, considering that it is a volunteer effort, I don't think it is in the best interesting of project to be overly "legislating".

[quote=axn;221809]That's just a CYA disclaimer written in legalese. It should be interpreted along with the following sentences.[/quote]So what?

One can't make "every effort" while condoning poaching.

[quote]It is not in the best interest of GIMPS to promise[/quote]I used "pledge".

[quote]any such thing, lest it open itself up to legal troubles[/quote]A strictly legal argument would be dodging the ethical issues, I think. I've made no statement about legality, because I'm concerned with the ethics.

[quote](unless of course, there is a foolproof way to prevent poaching).[/quote]No, "foolproof" is not required.

[quote]Now, George may unofficially want to promise such thing, but officially, I don't think so.[/quote]Are you using "officially" to mean "legally" there?

Surely license.txt is "official" as far as GIMPS is concerned outside of legal considerations.

[quote]Secondly, a typical EULA will have a section for "ACCEPTABLE USE". I would think that it would be a simple matter to add this section, explicitly prohibiting "poaching". Of course, for such a thing to happen, GIMPS must consider itself the owner of all these exponents.[/quote]No -- owner of the assignments, not the exponents.

Poaching is a violation of exclusive assignment.

Anyone operating outside GIMPS/PrimeNet (and thus NOT using any GIMPS-licensed software such as prime95 or mprime) is free to test whatever exponent they wish. Those of us using GIMPS-licensed software are bound by ethical considerations not to poach, I contend.

[quote]EDIT:- Lastly, considering that it is a volunteer effort, I don't think it is in the best interesting of project to be overly "legislating".[/quote]One more reason I've been arguing from ethics, not law. I haven't advocated any legislation, just an ethical interpretation of the principles and statements.

Portraying my arguments as being of legal nature would be false.

- - -

I think I'm finished with my editing. :-)

Once again, a debate about poaching has come up on this forum, and it predictably involves around none other than Cheesehead. It's like gravity or something.

Here's a possible solution: have a maximum limit of 500 days per exponent for doublechecks and 1000 days per exponent for first time tests. Before that, the server should reject any results by poachers, and the milestones page should be left unchanged. After that, anybody is allowed to poach the exponent if it still hasn't been completed, and the poacher gets both the credit for it and the prize money if it happens to be prime. The milestones page will be updated, but if the original tester later finishes the exponent, he/she will still get credit for it.

[QUOTE=cheesehead;221810]So what?
<snip>
[/QUOTE]

I could fisk your post, but it is too distracting. Let me summarize.

It is you contention that GIMPS has some kind of official commitment (promise/pledge/whatever) to protect users from poaching. I say that no such commitment exists officially.

Exhibit A - License.txt (Note:- There is no exhibit B).

"Every effort has been made to ensure that you will be assigned an exponent that no one else has tested or is testing"

Definitely a promise (or pledge or whatever). But, of what? Plain reading suggests a promise to be free from system SNAFUs. The sentence covers exponents "no one else has tested or is testing". But says nothing about "once you start testing, no one else will take it" -- which is the operational definition of poaching.

The rest of that section reveals its CYA nature, not a "solemn promise" for anything.

Coupled with the fact that it is straightforward to add a "No Poaching" clause (I mean, if you have a Rights section, you should also have a Responsibilities section, no?), I submit to you that you're overreaching with the "No-Poaching-official-pledge" intrepretation of license.txt.

Defense rests.

PS:- Pledge -> A solemn promise.
PPS:- License.txt has legal purposes. Ignoring that undermines your analysis.

Let's deal with the last two first:

[quote=axn;221813]PPS:- License.txt has legal purposes. Ignoring that undermines your analysis.[/quote]But I didn't ignore that! I have specifically mentioned on multiple occasions that it has legal purposes!

For instance, do you see that I've ever [I]denied[/I] a legal purpose for license.txt? (Answer: no.)

I am simply refraining from using legality in my current anti-poaching arguments, not ignoring it. If I were ignoring it, I wouldn't have made any mention of legality at all -- but I [I]have[/I] mentioned legality!

You undermine [U]your[/U] analysis by including false statements such as that one.

[quote]PS:- Pledge -> A solemn promise.
[/quote]Yes, GIMPS has promised, and done so solemnly.

Now, back to the beginning:

[quote]The sentence covers exponents "no one else has tested or is testing". But says nothing about "once you start testing, no one else will take it" -- which is the operational definition of poaching. [/quote]Poaching means (deliberately and knowingly) testing an exponent while it [B]is[/B] assigned to someone else.

An assignment is referred-to as both a single event (when PrimeNet "makes", i.e., creates, the assignment) and an ongoing event with a duration. The assignment remains in existence after its creation, until its dissolution; if it were not so, then there would be no way to associate a result report with the user to whom the credit should be given. Poaching occurs during the latter phase of an assignment.

[quote]The rest of that section reveals its CYA nature, not a "solemn promise" for anything.[/quote]It's not a promise? It's not solemn?

You don't show how either of those holds.

[quote]Coupled with the fact that it is straightforward to add a "No Poaching" clause (I mean, if you have a Rights section, you should also have a Responsibilities section, no?), I submit to you that you're overreaching with the "No-Poaching-official-pledge" intrepretation of license.txt.[/quote]I understand that's your opinion. I also understand that it's partly erroneous.

[quote]Defense rests.[/quote]... having failed to prove its case.

[QUOTE=cheesehead;221819]Let's deal with the last two first:

But I didn't ignore that! I have specifically mentioned on multiple occasions that it has legal purposes!

For instance, do you see that I've ever [I]denied[/I] a legal purpose for license.txt? (Answer: no.)

I am simply refraining from using legality in my current anti-poaching arguments, not ignoring it. If I were ignoring it, I wouldn't have made any mention of legality at all -- but I [I]have[/I] mentioned legality!

You undermine [U]your[/U] analysis by including false statements such as that one.[/quote]
Fine. Let me rephrase that. License.txt has _only_ legal purposes. You pretending otherwise doesn't make it so. It is nothing but CYA stuff. Not a single word in it is "solemn" or "promise".


[QUOTE=cheesehead;221819]Poaching means (deliberately and knowingly) testing an exponent while it [B]is[/B] assigned to someone else.

An assignment is referred-to as both a single event (when PrimeNet "makes", i.e., creates, the assignment) and an ongoing event with a duration. The assignment remains in existence after its creation, until its dissolution; if it were not so, then there would be no way to associate a result report with the user to whom the credit should be given. Poaching occurs during the latter phase of an assignment.[/quote]
This is not an "obviously wrong" interpretation. However, I contend that GIMPS would've fulfilled any (legal) obligation under the terms of license, if it takes necessary steps to make sure that nobody is working on the exponent at the time of assignment (i.e. when the server initially allocates the exponent to you). Interpreting it more expansively just adds undue burden on GIMPS.

[QUOTE=cheesehead;221819]It's not a promise? It's not solemn?

You don't show how either of those holds.[/quote]
No. It's neither. It's CYA BS. If it was a solemn promise, it wouldn't have been immediately followed by "we're not responsible" language.

[quote=axn;221830]License.txt has _only_ legal purposes.[/quote]Then why isn't it written in better legal language? As it is, it's an amateur (I don't think George is an attorney) statement of promise, intent, and limitations.

- - -

George,

Was every purpose for which you wrote license.txt a legal one? Did you have no purposes other than legal ones?

(Actually, I should first ask: Did you have [I]any[/I] legal purpose for writing license.txt?)

- - -

[quote]Not a single word in it is "solemn" or "promise".[/quote]Ethically, it is a promise to the GIMPS community.

[quote]However, I contend that GIMPS would've fulfilled any (legal) obligation under the terms of license, if it takes necessary steps to make sure that nobody is working on the exponent at the time of assignment (i.e. when the server initially allocates the exponent to you).[/quote]IANAL, but I don't think you even have that legally correct!

GIMPS [U]cannot[/U] "make sure that nobody is working on the exponent at the time of assignment" outside of the GIMPS cooperative community! GIMPS [U]cannot[/U] possibly know in any way whether someone is running a test on an exponent without having registered it as an assignment. There is no way GIMPS can take "necessary steps" to know that! (E.g., "necessary steps" would include have to include things like mind-reading or remote viewing.) All GIMPS can know is the state of PrimeNet assignments, and its communications to its community, which include ethical appeals.

What the text says is that "Every effort has been made ...", not "Every necessary step has been taken ...". The only efforts GIMPS [U]can[/U] make concern the assignments and testing within the purview of GIMPS, not any hypothetical testing outside the GIMPS assignment system. GIMPS is unable to make any effort (other than useless efforts such as blind spam e-mailings) to discover whether someone outside the GIMPS community is testing an exponent.

[quote]Interpreting it more expansively just adds undue burden on GIMPS.[/quote][U]You're[/U] the one who's made an expansive interpretation about doing things that GIMPS cannot do.

[quote]If it was[/quote] [I]your[/I] (legalistic) [quote]solemn promise, it wouldn't have been immediately followed by "we're not responsible" language.[/quote]... but George has worded it his own way.

[QUOTE=cheesehead;221842]IANAL...[/QUOTE]

Clearly.

[QUOTE=chalsall;221844][QUOTE=cheesehead;221842]
IANAL[/QUOTE]

Clearly.[/QUOTE]

... and I thought the gloves were already off.

This thread is quickly descending into a boorish row. No amount of jurisprudence or policy bending (individual [mis]interpretation) can defy or deny that poaching or reallocation of assignments inhibits progress or the spirit of fairness to an individual's contribution to the project. This project is, supposedly, a turtles all the way up scenario (until otherwise proven that there are finite Mersenne primes - unlikely). There have been many an example of splitting hairs (or more likely straws, it seems).

I've been switching my slower or less active borgs now to this project (as projects like Seventeen or Bust are reaching exponent sizes where my computers are taking too long to crunch (from min. two weeks for my most active/fastest computers to about eight years extrapolated for the slowest/least active) and thus potentially holding up a given [i]n[/i]). In projects such as that, poaching is appropriate at a given point and preferable as well as theoretically optimal (although the probability of a hold up is quite low it is, supposedly, infinitely larger than that of projects such as GIMPS). In the SoB project, a milestone affects the outcome of the project in that it allows for the reallocation of resources from a completed milestone to one that has yet to be achieved. This is NOT the case with GIMPS. It's like two taxis vying for the same customer when one is already in one of the cars.

I think cheesehead is implicitly instigational in tone, but like it or not, he's right for the most part (and I think he gets off of this, you're feeding the Golem).

milestones
 

I have a question for those advocating poaching when a milestone is nearly reached : should everybody jump on the straggling exponents and see who finishes first ? Or should GIMPS organise a special poachers reservation system ? And then what should happen when somebody poaches within that system ?

GIMPS is an organised and cooperative search. Poaching goes against the organisation and the cooperation.

That GIMPS could be improved regarding straggling work-units is sure. For instance strict implementation of the one year rule for all exponents under 100 000 000. Then re-assignation of the lowest exponents of each work-type to reliable machines only. Note that even such policy would not prevent an exponent going astray for one more year if the newly assigned and confident* machine suddenly gets turned off for the whole week except for a few hours on Sunday for instance.

It is fun to watch Milestones being approached and reached. If this would happen with a metronomic regularity all the fun would disappear. Just exercise some patience

Jacob

* confidence as defined by GIMPS on the CPU page (something like a number of good results returned.)

Minor question... Was Primenet supposed to add the line "Double-checking proves M(20996011) is the 40th Mersenne prime" to the milestone list, and remove a line from the countdown list, automatically when the last DC finished?

[quote=jinydu;221875]Minor question... Was Primenet supposed to add the line "Double-checking proves M(20996011) is the 40th Mersenne prime" to the milestone list, and remove a line from the countdown list, automatically when the last DC finished?[/quote]
AFAIK that is a manual operation.

[quote=henryzz;221877]AFAIK that is a manual operation.[/quote]
As the actress said to the bishop.

[quote=imwithid;221862]... and I thought the gloves were already off.[/quote]Some folks will go to great lengths to justify poaching. I'm willing to match them to expose the flaws in their arguments.

[quote]This is NOT the case with GIMPS. It's like two taxis vying for the same customer when one is already in one of the cars.[/quote]A new simile IIRC.

[quote]I think cheesehead is implicitly instigational in tone[/quote]I vigorously oppose the open advocacy of trust-violating and project-slowing poachery to which your term is more appropriate. I'm not the one who started it.

[quote]but like it or not, he's right for the most part[/quote]Thank you.

[QUOTE=imwithid;221862]... and I thought the gloves were already off.

This thread is quickly descending into a boorish row.[/QUOTE]

Sorry to anyone offended by my above. My last post ("Clearly.") was meant to be funny. (Not everyone gets or appreciates my humour. Sorry; I'm Canadian -- I was raised on Monty Python, Kids in the Hall, Rick Mercer and This Hour has 22 Minutes...)

[QUOTE=imwithid;221862]No amount of jurisprudence or policy bending (individual [mis]interpretation) can defy or deny that poaching or reallocation of assignments inhibits progress or the spirit of fairness to an individual's contribution to the project.[/QUOTE]

I, personally (although I do my best not to poach), do not necessarily agree that poaching "inhibits progress" to a significant degree.

I *do* agree poaching goes against the "spirit of fairness to an individual's contribution to the project".

But I would counter argue for consideration (as others have) that if someone doesn't bother to official register with the server (read: the assignment is to "Anonymous") and/or if they are holding up a milestone, then perhaps that small slight might be forgiven for the "greater good" (read: reaching a GIMPS milestone) as perceived by some active GIMPS participants.

I am *not* trying to pick a fight here.

Serious debate without baggage, on the other hand, is always welcome.... :smile:

I think part of the problem regarding fairness is as follows:

1. Not everyone who joins GIMPS is serious about searching for primes. I think everyone can agree on that. However, who are we to judge? we have no way of knowing who is serious and who is not.

2. Is it fair to poach a double-check assignment from someone who is not serious? (but consider the problem in #1).

3. Keeping these first two in mind... DC assignments that fall under the following categories probably are not assigned to individuals who care too much about project or even know they are still running Prime95 (or are too lazy or lack the knowledge to remove it).

a) the DC assignment is more than 12-18 months old.
b) the assignment is registered to 'anonymous'

We need some system to determine the above. Perhaps info on the last updates of the exponent? Also, if an exponent is being worked on minimally (ex less than 5 hours a week) and is holding up a milestone, is it out of our means to contact these individuals to see if they are serious participants? However, this might take away from the fun-spirited project that GIMPS claims to be.

[QUOTE=Primeinator;221917]I
b) the assignment is registered to 'anonymous' [/QUOTE]

One small point...."anonymous" does not necessarily mean or imply the person is casual, didn't bother to register, is not serious, or anything to that effect.

If could very well be a VERY serious participant who simply CHOOSES to remain anonymous.

[quote=Primeinator;221917]3. Keeping these first two in mind... DC assignments that fall under the following categories[/quote] [strike]probably are not[/strike] might or might not be (but who knows?) [quote]assigned to individuals who care too much about project or even know they are still running Prime95 (or are too lazy or lack the knowledge to remove it).

a) the DC assignment is more than 12-18 months old.
b) the assignment is registered to 'anonymous'[/quote]As petrw1 points out, beware the fallacy of assuming that which you want to be true in order to justify something you want to do.

[quote]We need some system to determine the above.[/quote]Mind-reading to determine who doesn't "care too much about project or even know they are still running ... (or are too lazy or lack the knowledge ..."? Just how do you propose to implement [I]that[/I]?

[quote]holding up a milestone[/quote]Why this fixation on "holding up a milestone"? You do realize, don't you, that those "milestones" are a very poor and distorted measure of GIMPS project progress?

[U]It's that fixation on those "milestones" that is taking away from the fun-spirited project that GIMPS claims to be.[/U]

[U][B]I think George should immediately remove all future "milestone" items from display on any mersenne.org page.[/B][/U] (Yes, I understand that anyone having a maniacal fascination with the number of tests left to complete below some arbitrary exponent can perform the calculation by using available information from online reports. It's also true that no door lock can keep out a determined burglar. The point in both cases is to make it difficult and time-consuming enough to discourage casual amateurs and passers-by.)

[I] Just display (and announce) milestones only _[U]after[/U]_ they are achieved, as has usually been done for the "up to nn,000,000" milestones. [U]Never, ever display countdowns to future milestones.[/U]
[/I]

[QUOTE=cheesehead;221927]

[U][B]I think George should immediately remove all future "milestone" items from display on any mersenne.org page.[/B][/U] [/QUOTE]

This isn't likely to happen.

[QUOTE=petrw1;221924]One small point...."anonymous" does not necessarily mean or imply the person is casual, didn't bother to register, is not serious, or anything to that effect.

If could very well be a VERY serious participant who simply CHOOSES to remain anonymous.[/QUOTE]

Right. I tried to make my language vague for this reason; however, I concede my language was not vague enough to include this particular and obvious caveat. It may have had something to do with the wine at dinner.... Regardless, there are those that do choose to remain anonymous, but is it a fair statement to say these are in the minority?

[QUOTE=Primeinator;221932]This isn't likely to happen.



Right. I tried to make my language vague for this reason; however, I concede my language was not vague enough to include this particular and obvious caveat. It may have had something to do with the wine at dinner.... Regardless, there are those that do choose to remain anonymous, but is it a fair statement to say these are in the minority?[/QUOTE]

My only guage might be that any "ANONYMOUS" with more than a "scant few" GhzDays are serious....mind you, I have no way of knowing how many total "ANONUMOUS" there are.

[QUOTE=petrw1;221924]One small point...."anonymous" does not necessarily mean or imply the person is casual, didn't bother to register, is not serious, or anything to that effect.

If could very well be a VERY serious participant who simply CHOOSES to remain anonymous.[/QUOTE]

True. But two counter arguments (and a sub-point / question)...

1. One can still remain anonymous and have a registered name / handle / alias with the server.

1.2. Why would anyone serious want to be anonymous, unless they were breaking the trust of the actual machine(s)' owner?

2. A "VERY serious participant" will probably not be holding up a milestone.

Just putting that out there....

[QUOTE=Primeinator;221917]I think part of the problem regarding fairness is as follows:

[Snip]

3. Keeping these first two in mind... DC assignments that fall under the following categories probably are not assigned to individuals who care too much about project or even know they are still running Prime95 (or are too lazy or lack the knowledge to remove it).

a) the DC assignment is more than 12-18 months old.
b) the assignment is registered to 'anonymous'[/QUOTE]

This caused me to crystallize an angle of thought I had not articulated, but which I had at the back of my mind during this (and other "poaching") debates.

1. I think we can all accept as an axiom that those DCing do not actually expect to find a "missed Mersenne Prime (MP)".

1.2. The odds of those doing LL work finding an MP are already astronomical (although a few have been lucky).

2. For some reason I don't fully understand, the PrimeNet server appears to continue to hand out low DCs to slow and/or unknown machines.

2.2. This can only lead to frustration of those fixated on DC milestones. (For the record, I am not one of those individuals.)

So, from this then, might I please suggest that the PrimeNet server only hand out low DCs to trusted participants' trusted and fast machines?

New comers and slow machines, if requesting DCs (or if it "makes sense") should be assigned DCs only slightly behind the LL edge.

Yeah, this might discourage someone bringing an ancient machine to GIMPS. But, then, perhaps that's appropriate....

[quote=chalsall;221980]1.2. Why would anyone serious want to be anonymous, unless they were breaking the trust of the actual machine(s)' owner?[/quote]I consider anonymity a valuable and important commodity. I don't like categorizing the possible reasons and motives of people who avail themselves of the opportunities to be anonymous. It is necessary at times to question or guess motivations or even demand commitment of reputation or identity -- but-- it's nice to keep those times to a practical minimum.

So to directly answer the question, in my case, sometimes I like being anonymous so that my behavior can be judged on the merits of the actions themselves without any greater or extraneous history or issues lumped in with it.

[QUOTE=only_human;221984]So to directly answer the question, in my case, sometimes I like being anonymous so that my behavior can be judged on the merits of the actions themselves without any greater or extraneous history or issues lumped in with it.[/QUOTE]

But, as I also argued in my post, it is possible to be anonymous without being "Anonymous".

[QUOTE=chalsall;221988]But, as I also argued in my post, it is possible to be anonymous without being "Anonymous".[/QUOTE]If you look at the top-producers records you will see that there are a lot of different Anonymous accounts so those machines have a separate user ID even if it is anonymous.[QUOTE=chalsall;221982] 2. For some reason I don't fully understand, the PrimeNet server appears to continue to hand out low DCs to slow and/or unknown machines.
2.2. This can only lead to frustration of those fixated on DC milestones. (For the record, I am not one of those individuals.)
So, from this then, might I please suggest that the PrimeNet server only hand out low DCs to trusted participants' trusted and fast machines?[/QUOTE]One of the problems is that the DC wave is very compact, assign an high DC exponent to a slow machine, and you will find that exponent isolated as a straggler in a few months.

Perhaps there should be 2 DC waves : at the moment one at 24M and less reserved for the "known" machines and the other at 27M (or even at 30M...) for the others.

Jacob

[quote=chalsall;221982]So, from this then, might I please suggest that the PrimeNet server only hand out low DCs to trusted participants' trusted and fast machines?

New comers and slow machines, if requesting DCs (or if it "makes sense") should be assigned DCs only slightly behind the LL edge.[/quote]Now, there's a idea -- for newcomer/slow systems, assign not the lowest available exponent for DC but deliberately "skip ahead" toward, or even amongst, the general range in which first-LL's are still in progress. The idea would be that if the slow system didn't make adequate progress, there'd still be plenty of time (after the first DC assignment's time allowance ran out) for reassignment to a more-trusted system without any "holding up" of a milestone. There could be an algorithm for the amount of "skip-ahead", depending on system speed.

[quote]Yeah, this might discourage someone bringing an ancient machine to GIMPS. But, then, perhaps that's appropriate....[/quote]... and there's always LMH or such. Yeah, LMH is about to eliminate all sub-65-bit-TF possibilities among sub-billion exponents, but if an ancient is to be useful, what else (in GIMPS, that is)?

[FONT=Bookman Old Style][FONT=Verdana]This is a very long thread so please excuse me if the answer is already up there somewhere.[/FONT]

[FONT=Verdana]Why is poaching physically possible?[/FONT]

[FONT=Verdana]At my job I use a network. If I open a file with write access another user can have only read access. If something goes wrong no users might have write access and the help desk staff have to change some system settings to put things to rights.[/FONT]

[FONT=Verdana]If an exponent is assigned why can another user poach it? Why if he tries does he not get an error message? An exponent should remain owned until the owner finishes the test or voluntary gives it up (network: closes the file) or an administrator takes it away from him because it is clear that there is some system issue (network: the user reports a problem to the help desk or someone else reports a problem and it is clear that the user has no need for the file – he hasn’t used it for a certain amount of time and can’t be contacted to ask if he still needs it). If a user reports no progress and cannot be contacted in order to explain himself then I see no reason why an exponent should not be made available, but it should be someone in authority and not another user acting by himself who makes the decision.[/FONT]

[FONT=Verdana]G[/FONT][/FONT]

[quote=GARYP166;222003][FONT=Bookman Old Style][FONT=Verdana]Why is poaching physically possible?[/FONT][/FONT][/quote][FONT=Bookman Old Style][FONT=Verdana]Because there are no access-rights to exponents that could be restricted.[/FONT]

[FONT=Verdana][quote]At my job I use a network. If I open a file with write access another user can have only read access.[/quote]... because your OS controls file access.

The GIMPS/PrimeNet assignment system does not have that property. Instead, it is only a method for regulating voluntary actions for the community's interest in non-duplication of efforts. An assignment is "enforceable" only so far as appeals to the voluntary consent of participants to abide by the PrimeNet assignment system are effective.
[/FONT][/FONT]

I mentioned the network only to provide an analogy.

To change the question:

if an exponent is assigned, should there be some safeguard to stop it from being assigned a second time? Presumably there is coding of some sort - otherwise exponents could not be assigned to begin with. If poaching is regarded as a serious issue - and it is by some users - then maybe it would be possible to stop it.

G

[quote=GARYP166;222006]To change the question:

if an exponent is assigned, should there be some safeguard to stop it from being assigned a second time?[/quote]Assignments are made by code in the PrimeNet server. PrimeNet stores assignment information in a database and consults that when considering an assignment request. In this regard, PrimeNet acts as the OS in your example does (when the OS grants file access), being the single point at which assignments are given.

When I previously wrote "[FONT=Bookman Old Style][FONT=Verdana]because your OS controls file access.

The GIMPS/PrimeNet assignment system does not have that property.[/FONT][/FONT]"

what I meant was that GIMPS/PrimeNet does not control access to exponents. It [I]does[/I], however, control access to assignments. An assignment does not signify exclusive access to testing an exponent -- it signifies the exclusive right of a GIMPS participant to test an exponent that is not assigned to any other GIMPS participant for testing at the same time. That is, an assignment is the [I]exclusive right within the bounds of the GIMPS/PrimeNet voluntary cooperative system[/I] to test an exponent.

[quote]If poaching is regarded as a serious issue - and it is by some users - then maybe it would be possible to stop it.[/quote]... but only by persuasion and/or removing incentives. If someone decides to LL-test some Mersenne number with a particular exponent, there is no physical barrier.

GIMPS software (prime95, mprime) contains a license granting permission to use it only if the user abides by GIMPS rules (such as the PrimeNet assignment system). Thus, anyone using GIMPS software with permission is ethically obliged to follow GIMPS rules.

Someone who wants to test an exponent without having a PrimeNet assignment for it (but while someone else does have that) [U]can[/U] ethically do so, but only by using non-GIMPS software and by not knowing the existence and purpose of the PrimeNet assignment system. Of course, someone who is just totally ignorant of GIMPS and PrimeNet, and is not using GIMPS software, has no ethical obligation to honor the PrimeNet assignment system.

[quote=chalsall;221988]But, as I also argued in my post, it is possible to be anonymous without being "Anonymous".[/quote]Is it? I looked up the file that has my true name in it once.

[QUOTE=cheesehead;222012]GIMPS software (prime95, mprime) contains a license granting permission to use it only if the user abides by GIMPS rules (such as the PrimeNet assignment system). Thus, anyone using GIMPS software with permission is ethically obliged to follow GIMPS rules.[/QUOTE]

cheesehead is being somewhat dishonest here.

The truth of the matter is the GIMPS license is a bit closer to Robin Williams' interpretation of the US of A's second amendment:

"You have the right to bear arms, you have the right to arm bears, what ever the hell you want to do!

Some of us, however, try to be as polite to each other as we can, knowing that no one has any true claim on anything....

[quote=cheesehead;222002]Now, there's a idea -- for newcomer/slow systems, assign not the lowest available exponent for DC but deliberately "skip ahead" (...)[/quote]

That is already foreseen in the "Assignment Rules" (if not for slow systems, at least for newcomers). That´s the concept of "preferred exponents". But the ranges have in my opinion become "obsolete": preferred exponents for DC should be <24M instead of 22M and for LL <40M instead of 38M. These figures were OK 1 year ago, but now it is time to move forward. Or perhaps, according to cheesehead´s suggestion, these figures could be even higher.

Assignment rules updated.

For now, 25% of all "whatever makes the most sense" assignments will be double-checks. It would be great if the eagle-eyed readers of this sub-forum would analyze our first-LL and double-check rates over the coming months to suggest any changes.

Since first LL tests take ~4 times longer than dchks, this change represents committing only 7% of "whatever makes sense"'s resources.

I know I shouldn't do this:

[url]http://mersenne.org/assignments[/url] is a grossly inefficient (you'll have to ask SQLServer programmers why) report. DO NOT use this during the first 10 minutes of the hour. DO NOT use this for a large number of assignments. Acceptable ranges are 21 to 23 million or a range of a few thousand in the first LL or TF areas.


New expiration rules coming soon.

[QUOTE=Prime95;222048]Assignment rules updated.

For now, 25% of all "whatever makes the most sense" assignments will be double-checks. It would be great if the eagle-eyed readers of this sub-forum would analyze our first-LL and double-check rates over the coming months to suggest any changes.

Since first LL tests take ~4 times longer than dchks, this change represents committing only 7% of "whatever makes sense"'s resources.[/QUOTE]

Just curious...if it's public knowledge...about what percentage of participants (or PC's) are "whatever makes the most sense"

[QUOTE=Prime95;222053]I know I shouldn't do this:

[url]http://mersenne.org/assignments[/url].[/QUOTE]

Though these are all DC why do some show LL,% in the stage,% column and some just a %?

[quote=petrw1;222057]Though these are all DC why do some show LL,% in the stage,% column and some just a %?[/quote]
It seems that "LL, %" are v5 clients and "%" v4.

[QUOTE=petrw1;222057]Though these are all DC why do some show LL,% in the stage,% column and some just a %?[/QUOTE]You can reserve a double check as a first time test. There were some postings to that effect by a user who changes his "DoubleCheck=AID..." lines to "Test=AID..." so as to increase his LL test standings instead of his DC's one. For GIMPS it is the same : the exponent is assigned to that user for LL testing.

Jacob

I don't see why the latest milestone has provoked all this bruhaha
about double checks. These are progressing in the same orderly fashion
they have always done (~2M increase in exponent p.a.).
What is more alarming (see my thread "Is GIMPS grinding to a halt?")
is that the first time LL wavefront seems to have refused to jump
the 51M hurdle, despite the P-1 effort that has gone into that range.

BTW as an incentive for P-1 and the last bit (or 2?) of TF, why not
acknowledge the person who performed this valuable (if thankless) task,
should the number turn out to be prime?

David

PS Isn't it time to consider passing on intermediate residues
from returned partially completed tests?

PPS Can P-1 and/or TF be "torture tests"?

Maybe we should force pcs with trusted exponents to report every week and not to have a days to go of more than ~90 days.
IMO there is no way that the person who will take 763 days to finish 19632763 should have a trusted exponent. If he keeps that estimate he will have taken 1,388 days to finish an exponent that will have been a trusted exponent for most of that time. Trusted exponents should be aiming to finish in 6 months or less.
I agree with cheesehead when he says that nontrusted pcs should have assignments much further up like 30M for dcs.

[QUOTE=Prime95;222048]Assignment rules updated.

For now, 25% of all "whatever makes the most sense" assignments will be double-checks. It would be great if the eagle-eyed readers of this sub-forum would analyze our first-LL and double-check rates over the coming months to suggest any changes.

Since first LL tests take ~4 times longer than dchks, this change represents committing only 7% of "whatever makes sense"'s resources.[/QUOTE]


Awesome!

[QUOTE=Prime95;222053]I know I shouldn't do this:

[url]http://mersenne.org/assignments[/url] is a grossly inefficient (you'll have to ask SQLServer programmers why) report. DO NOT use this during the first 10 minutes of the hour. DO NOT use this for a large number of assignments. Acceptable ranges are 21 to 23 million or a range of a few thousand in the first LL or TF areas.


New expiration rules coming soon.[/QUOTE]

The first exponent on this list now has a verified LL. I'm wondering... is it possible for us lowly beings to generate this type of report or is that reserved for individuals with super powers such as yourself?

[QUOTE=Primeinator;222092]Is it possible for us lowly beings to generate this type of report or is that reserved for individuals with super powers such as yourself?[/QUOTE]

Only I can do it. You need to know the database layout, PHP, and have server access.

This report has actually been available since 2008 but it can put a nasty load on the server. It is very similar to the old v4 reports.

I just tweaked it to limit the output to 1000 assignments. This should help avoid loading the server down when there a lot of assignments in the specified range.

[QUOTE=petrw1;222057]Though these are all DC why do some show LL,% in the stage,% column and some just a %?[/QUOTE]

Yes, this is the difference between a v4 and v5 client. A v4 client reporting 50% could be 50% through the LL or it could be 50% through the TF or P-1 preceeding an LL test!

[QUOTE=Prime95;222110]Only I can do it. You need to know the database layout, PHP, and have server access.

This report has actually been available since 2008 but it can put a nasty load on the server. It is very similar to the old v4 reports.[/QUOTE]

It would be better if the query is executed against the full dataset and cached in a standalone table (like once a day), and then run the report against the cache. No one really needs up to the minute version of this report. Or is that how it is done already?

axn, the problem with your solution is that it would require the status of all assigned exponents to be generated once a day. With dynamic querying, as long as the number of queries per day is small, you end up with less load on the server.

[QUOTE=garo;222124]axn, the problem with your solution is that it would require the status of all assigned exponents to be generated once a day. With dynamic querying, as long as the number of queries per day is small, you end up with less load on the server.[/QUOTE]

Possibly. It would help if we have sample numbers.

When it comes to load's on server, you should optimize for worst-case behavior even at the cost of average case behavior.

But even this can be addressed, if the cache can be updated incrementally. i.e Find the new assignments (Inserts), status updates (Updates), and completed / unreserved assignments (Deletes) since the last cache update.

[QUOTE=garo;222124]axn, the problem with your solution is that it would require the status of all assigned exponents to be generated once a day. With dynamic querying, as long as the number of queries per day is small, you end up with less load on the server.[/QUOTE]

Here's an alternative suggestion.

Create a new SQL table specifically for this query. Update it on an exponent by exponent basis when the client checks in. Thus the data would be "real-time", and the query would be light (we're talking less than 100,000 rows for both DC and LL).

Yeah, this would break the "fully normalized" structure of the database. But sometimes the ideal of full normalization doesn't actually map well to the real world. And the "full query" (or multiple sub-range queries) would only have to be run once to initially populate the new table.

The reason this query is so "heavy" has to be because of multiple joins through multiple tables.

[QUOTE=chalsall;222126]The reason this query is so "heavy" has to be because of multiple joins through multiple tables.[/QUOTE]

Thinking about this a bit further, I don't fully understand why this query is necessarily so heavy. But then I don't know the PrimeNet DB Schema.

Before creating a new table as I suggested above, have the SQL developers looked at their indexes, and ensured this query is currently optimal?

Have they looked at the SQL "use index" option to specifically tell the DB Engine what index(es) to use (sometimes the Engine makes a sub-optimal choice if more than one index is available).

Lastly, sometimes sub-queries can be your friend for speed....

(My apologies in advance if you've already looked at all these angles. Trying to help, not offend.)

[QUOTE=Prime95;222110]Only I can do it. You need to know the database layout, PHP, and have server access.

[/QUOTE]

I kind of thought so; such information is probably best left only in your hands (for the most part). Out of curiosity, what prompted you/what for reason did you decide to share this info?

[QUOTE=Primeinator;222139]Out of curiosity, what prompted you/what for reason did you decide to share this info?[/QUOTE]

I trust you guys to not abuse the server too badly. There won't be a link to this report from the main web page

Yes, the current server is not enforcing the one-year assignment rule.

My new ideas for recycling assignments:

For LL tests on exponents < 80M and not manual testing:

If assignment is one year old and < 50% complete it is recycled.
If assignment is one-and-one-half years old it is recycled.

For non-LLs:

If assignment is 180 days old and < 50% complete it is recycled
If assignment is 270 days old it is recycled

I've coded up a sample query already. 3113 assignments are affected.

Comments?

[QUOTE=Prime95;222164]I've coded up a sample query already. 3113 assignments are affected.

Comments?[/QUOTE]

Please, please, PLEASE!!! Do not allow these to be reassigned to slow machines.

I would, personally, be willing to take 150 of these and assign them to semi-fast machines immediately which would complete within 10 days.

I have reason to believe that others similarly enabled might be willing to do so as well...

Apparently there is a bug that is allowing v4 computers to get preferred assignments. Witness: 35000923.

Hopefully I've coded up a workaround but cannot test it. Please keep an eye out for whether this problem continues.

[QUOTE=chalsall;222167]Please, please, PLEASE!!! Do not allow these to be reassigned to slow machines.[/QUOTE]

Standard preferred assignment rules will apply. There are many TF assignments in the 3113 - they aren't all LL and DCHKs.

I second chalsall´s request. It´s a good occasion to put some power where it is needed.
But I think the new assignment rules are already in place (are they?...) and that most of the recycled exponents will be reassigned under these rules, which will partially solve the issue.
Anyway, George, will you let us know when they will be up for grabs so we can do something about it ?... :whistle:

[QUOTE=Prime95;222164]Comments?[/QUOTE]

1. If steady progress is being made, however slow, let it be (for exceptions, see 2)
2. Exceptions
a) Doublecheck -- If the exponent is holding up a milestone (< 100 tests to prove a Mxx status), and doesn't look like finishing in 180 days, reassign.
b) ???

My $0.02

It is all well and good to reassign an exponent that is overdue; however, provisions must be made (as others have pointed out) to do the following:

1) Slow machines are not preferred.

2) How do we prevent the exponent from being assigned to these users that are not contributing (i.e. taking 2 years to DC an exponent in the 21M range). Will not some exponents be reassigned to these individuals (albeit a different non-contributing user than the DC was originally given to)? Should we, in effect, have a GIMPS 'naughty list?' I understand there is only one real benefit to this and several major cons (which should be quite deducible to any knowledgeable participant on this thread).

I've lost track of just what, specifically, defines "confidence" and "preferred" in PrimeNet nowadays. May we have the formulas or algorithms posted again?

[QUOTE=cheesehead;222191]I've lost track of just what, specifically, defines "confidence" and "preferred" in PrimeNet nowadays. May we have the formulas or algorithms posted again?[/QUOTE]

[url]http://www.mersenneforum.org/showpost.php?p=177548&postcount=502[/url]

[QUOTE=cheesehead;222191]I've lost track of just what, specifically, defines "confidence" and "preferred" in PrimeNet nowadays. May we have the formulas or algorithms posted again?[/QUOTE]

Reliability is a rolling average of the last 10 results. Where you earn 1.0 for a matching LL result, else 0.0 for a submitted result that did not match a proven good residue (rare), else 0.98 for an error-free result, else 0.5 for an LL run with 1 error, else 0.3 for two or more errors.

Confidence is simply the number of LL runs used in computing the reliability number (max of 10).

[QUOTE=cheesehead;222191]I've lost track of just what, specifically, defines "confidence" and "preferred" in PrimeNet nowadays. May we have the formulas or algorithms posted again?[/QUOTE]

Although I sense this is a sarcastic question, it is a VERY good point. What will define the boundary between a machine we have confidence in and one we don't? Will it be based upon the time it takes to complete exponent N in comparison to how long it should take a computer of that speed to complete the same exponent? I am all for inclusion in GIMPS, but some of these machines contributing minimally do not qualify... unless there are extenuating circumstances in which the participant can only utilize his/her machine for a few precious hours per day/week etc.

Mr. Woltman, I strongly support your actions and given future actions. However, I think that we should define, more precisely, how much subjectivity we are going to introduce.

[quote=Prime95;222164]Yes, the current server is not enforcing the one-year assignment rule.

My new ideas for recycling assignments:

For LL tests on exponents < 80M and not manual testing:

If assignment is one year old and < 50% complete it is recycled.
If assignment is one-and-one-half years old it is recycled.

For non-LLs:

If assignment is 180 days old and < 50% complete it is recycled
If assignment is 270 days old it is recycled

I've coded up a sample query already. 3113 assignments are affected.

Comments?[/quote]

I'll bite.

If I had an LL test at 49% after a-year-and-a-day with 10 days ETC, that would be unassigned and then dealt out to someone with DaysOfWork=90 who'd finish it like 3 or 4 months after I would have? Doesn't exactly seem logical.

I actually [I]do[/I] have 103 P-1 tests between 39M and 40M that are 185-196 days old. All of the exponents have been LL tested at least once before. These tests would then be unassigned and not be dealt out again until the DC wave hits 39M, if at all? That's plain nonsensical.

Finally, I also have 1547 TF assignments between 90M and 91M that are over the 180 days mark (all at 0% and all likely done with this year). These would then be unassigned - making a machine I do not have access to on a regular basis "run dry" - and be dealt out again whenever everything below 90M is at 67 bits, or some such? That's also debatable, I'd say.

Oh, seems like I have half of the 3113 assignments you mention. Call me lucky.

[quote=ckdo;222205]I'll bite.

If I had an LL test at 49% after a-year-and-a-day with 10 days ETC, that would be unassigned and then dealt out to someone with DaysOfWork=90 who'd finish it like 3 or 4 months after I would have? Doesn't exactly seem logical.[/quote]
Hmm...I suppose that could happen if a computer fast enough to do an LL every 20 days has been sitting on a queue of at least 18 (!) of them and is now working on the 18th, but I don't imagine anybody seriously sitting on a queue of that many LL's due to their sheer size.

For TF and P-1 assignments, however, such a scenario is not entirely uncommon, as demonstrated by your current assignments as described. I would suggest, therefore, that non-LL/DC assignments be left alone by the new assignment recycling rules: after all, they don't have any affect on milestones, so nobody's going to care if there's a few TF or P-1 assignments "behind the curve" being worked on over a long span of time.

Thoughts?

[quote=mdettweiler;222206]Hmm...I suppose that could happen if a computer fast enough to do an LL every 20 days has been sitting on a queue of at least 18 (!) of them and is now working on the 18th, but I don't imagine anybody seriously sitting on a queue of that many LL's due to their sheer size.[/quote]

Well ... I'm getting [URL="http://mersenne.org/assignments/?exp_lo=35699737&exp_hi=35839163&execm=1&extf=1&B1=Get+Assignments"]close[/URL]. :wink:

[quote=ckdo;222205]I'll bite.

If I had an LL test at 49% after a-year-and-a-day with 10 days ETC, that would be unassigned and then dealt out to someone with DaysOfWork=90 who'd finish it like 3 or 4 months after I would have? Doesn't exactly seem logical.
...[/quote]
It seems that George's ideas for new rules for recycling assignments ought to be refined to also look at the recent rate of progress for the given assignment to take into account large contributors like you who reserve a lot of work in advance.

However, i'm puzzled: how do you justify reserving many exponents in advance when you are not yet in a position to work on them?

[QUOTE=mdettweiler;222206]Hmm...I suppose that could happen if a computer fast enough to do an LL every 20 days has been sitting on a queue of at least 18 (!) of them and is now working on the 18th, but I don't imagine anybody seriously sitting on a queue of that many LL's due to their sheer size.

For TF and P-1 assignments, however, such a scenario is not entirely uncommon, as demonstrated by your current assignments as described. I would suggest, therefore, that non-LL/DC assignments be left alone by the new assignment recycling rules: after all, they don't have any affect on milestones, so nobody's going to care if there's a few TF or P-1 assignments "behind the curve" being worked on over a long span of time.

Thoughts?[/QUOTE]

I like this idea.

[QUOTE=ckdo;222205]If I had an LL test at 49% after a-year-and-a-day with 10 days ETC, that would be unassigned and then dealt out to someone with DaysOfWork=90 who'd finish it like 3 or 4 months after I would have? Doesn't exactly seem logical.[/quote]

Is there some reason this computer is not set up in a normal manner - to get first-time LL tests in a 90 day queue.

I don't mean to pick on you, just raising a question: I suspect you've set it up this way because you like working on smaller exponents with a better chance of discovering a new prime (I do too). Is it "fair" to other GIMPS members to lock up these smaller exponents for a year? two years? five years?

[quote]I actually [I]do[/I] have 103 P-1 tests between 39M and 40M that are 185-196 days old. All of the exponents have been LL tested at least once before. These tests would then be unassigned and not be dealt out again until the DC wave hits 39M, if at all? That's plain nonsensical.

Finally, I also have 1547 TF assignments between 90M and 91M that are over the 180 days mark (all at 0% and all likely done with this year). These would then be unassigned - making a machine I do not have access to on a regular basis "run dry" - and be dealt out again whenever everything below 90M is at 67 bits, or some such? That's also debatable, I'd say.

Oh, seems like I have half of the 3113 assignments you mention. Call me lucky.[/QUOTE]

It seems like the suggested policy needs to be tweaked somewhat. Perhaps, it should only apply to exponents in or near the "preferred" ranges. That is, something like DC's under 24M, first LLs under 42M, P-1 under 50M, and TF under 60M.

The expired P-1's wouldn't be a problem (theoretically). You'll complete them and get credit long before they are handed out for double-checking -- though clearly it is better to keep the assignments for tracking purposes. I'll have to see how hard it is to query if this is a P-1 assignment on an already LL'ed exponent and thus not holding up anything.

I don't know if we need any LMH rules. Are there any LMH assignments that look abandoned? Probably best to worry about it in a few years -- plenty of exponents to go around.

[QUOTE=Prime95;222164]Yes, the current server is not enforcing the one-year assignment rule.

My new ideas for recycling assignments:

For LL tests on exponents < 80M and not manual testing:

If assignment is one year old and < 50% complete it is recycled.
If assignment is one-and-one-half years old it is recycled.

For non-LLs:

If assignment is 180 days old and < 50% complete it is recycled
If assignment is 270 days old it is recycled

I've coded up a sample query already. 3113 assignments are affected.

Comments?[/QUOTE]

If possible I would also suggest considering "recent" progress. That could possibly address ckdo's concern. So if I have a LL a year old and only 20% done but all 20% is in the last month that is a good indication it was waiting it's time most of the year but now is actively processing and is likely to finish soon. On the other hand if after a year it is 90% done but NO progress in the last 8 months is a good indication it has been abandoned.

I too would be less concerned about TF, P1 and ECM though considering these assignments are measured in hours or days I think the most likely reason for little or no progress over a long period of time is that it was abandoned OR is queued up as in ckdo's scenario again. Could you consider the recent activity of the CPU the "old" assignment is registered to. If it has been churning out 10 TF's a day for the last month then odds are good it will get to these old assignments too in due time.

Mind you, one could argue whether it is reasonable to reserve a large collection of assignments that you won't get to for over a year. In simple terms this is a debate between personal interest in a certain range or type of assignments VS the collective interests or progress of the project as a whole.

[QUOTE=Prime95;222174]Standard preferred assignment rules will apply. There are many TF assignments in the 3113 - they aren't all LL and DCHKs.[/QUOTE]

Does this mean that only fast machines will be assigned "milestone blocking" work?

If not, a sincere question... Is this a policy decision, or because of implementation issues (read: development required on the PrimeNet server)?

If the latter, may I please make an offer.

As many of you know, I have implemented a "mini-you" PrimeNet server which I configure as a Proxy on my "cluster". The machines talk to my server which assigns work, and passes the results back to PrimeNet in a slightly delayed process.

I could, with very little effort, make this available to selected individuals with fast machines to process those exponents which are holding up milestones. George would have to provide me with a dataset containing the work-type and official AID, which my server would hand out to those selected volunteers. Just to be clear, the work would be credited to the volunteer, not me.

I'd suggest that the selected volunteers agree that they must complete the work within, say, one month for a DC and two for a LL (or whatever is agreed is reasonable). And I pledge that my own cluster (which will begin doing serious DC work once all 63 -> 64 LMH work is complete) would not receive any preference (this would be independently verifiable on the PrimeNet server itself).

George -- if you're interested, and the GIMPS community agrees, you have my e-mail address.

(I make this offer in the hopes of avoiding any future poaching arguments. :smile:)

[QUOTE=chalsall;222254]Is this a policy decision, or because of implementation issues (read: development required on the PrimeNet server)?[/QUOTE]

George: I probably missed the updates when I was off but what ever happened to the thread discussion this Spring about getting a new PrimeNet Server? Is it already in place?

Thanks

[quote=Prime95;222240]
It seems like the suggested policy needs to be tweaked somewhat. Perhaps, it should only apply to exponents in or near the "preferred" ranges. That is, something like DC's under 24M, first LLs under 42M, P-1 under 50M, and TF under 60M.

I don't know if we need any LMH rules. Are there any LMH assignments that look abandoned? Probably best to worry about it in a few years -- plenty of exponents to go around.[/quote]
Excellent idea. Since all the heartburn is being caused by lagging exponents - i.e. those in the preferred ranges, applying the policy only to the preferred ranges - and updating the preferred ranges on a six-monthly basis - would ease most of the trouble.

[quote=Prime95;222240]Is there some reason this computer is not set up in a normal manner - to get first-time LL tests in a 90 day queue.
[/quote]

I was speaking of a theoretical machine, although I'm still coping with 2 computers I lost in December. I moved their work to a third machine which had 4 cores, but enough work for 10 cores, in effect - a rather bad idea, in hindsight. In reality, I'll probably get everything done before the one year mark. We'll see.

As long as the new expiration policies only affect, say, LL tests below 60M and DCs below 30M, I'm fine. I'd vote to leave TF, P-1 and ECM alone, though. Long term assignments are not likely to cause any holdup in milestone achieval - present or future - in these categories.

[quote=Primeinator;222197]Although I sense this is a sarcastic question,[/quote]Not at all!

It was just that I wanted to inject those definitions into this discussion, but was short of time; else I'd have looked them up and posted them myself.

I'm genuinely interested in how the current measurements (and possible supplemental measures) can be applied to the proposed ethical methods for dealing with the poaching problem. This is an exciting discussion, going farther in that direction (ethical methods ...) than any I recall from the past.

- - -

[quote=Brian-E;222217]how do you justify reserving many exponents in advance when you are not yet in a position to work on them?[/quote]He doesn't want a system with infrequent access to run dry -- I think.

Shall we lower the upper limits on values of parameters DaysOfWork=, MaxExponents= and/or UnreserveDays= to curb that?

How about introducing different allowable DaysOfWork=, MaxExponents= and/or UnreserveDays= values for different types of work?

DaysOfTFWork=
DaysOfP-1Work=
DaysOfDCWork=
DaysOfFirst-timeLLWork=

(similar for Max[i]Type[/i]Exponents= and Unreserve[i]Type[/i]Days=)

[QUOTE=cheesehead;222359]He doesn't want a system with infrequent access to run dry -- I think.[/QUOTE]Would not ECM on low level expos be a good choice for a 'backstop' assignment? One could let it run on and on with virtually no chance of it going idle. With the right bounds set it should work nice.

[QUOTE=Prime95;222164] For LL tests on exponents < 80M and not manual testing:

If assignment is one year old and < 50% complete it is recycled.
If assignment is one-and-one-half years old it is recycled.

For non-LLs:

If assignment is 180 days old and < 50% complete it is recycled
If assignment is 270 days old it is recycled

I've coded up a sample query already. 3113 assignments are affected.

Comments?[/QUOTE]

I like the idea of setting term limits with some adjustments for those that continually progress along at a reasonable pace (what justifies that is arguable but looking at the assignment reports and sorting them in various ways, 30% after 500 days is much too long with progress under 30% - there are four such assignments under 22,000).

Cutting off a slow(er) machine that is making regular progress by setting the cutoff bar too high is wasteful. It is not easy finding a middle ground. Also, giving preference to trusted or reliable computers in the lower ranges is a great idea and those not to higher ranges. It has a good incentive/disincentive balance.

I would prefer that if progress is <50% and >400 days that it be recycled (of those assignments over 400 days, 5 tests are with no progress, 2 tests that are at .9% and 11 under 33%).

A quick look at the first 1,000 test sequentially from smallest assignment:

Those over 365 days there are 68:

3 have not started
17 are under 33% complete
28 are under 50% complete
39 are under 66% complete
67 are under 95% complete

1 is over 95% complete.

I guess I could have found better stats quicker but I was too lazy to separate the data, format cells to number, etc., so I used the manual count method.

This is a very small sample and subject to change and error. It does not say anything about the periodicity or amount of progress and thus the probability of abandonment so does not help in directing cutoff limits. It is obvious though that those not started within the 1 year mark should have been reassigned.

Correct me if I'm wrong on my anything here.

I have attached the current Active assignments webpage so that we can compare in a few days.

Casual observation - DCs are being assigned more rapidly than before and the proportion of Anonymous assignees in the DC leading edge has also increased significantly.

[LIST][*][SIZE=2]Countdown to testing all exponents below M(30402457) once: 0[/SIZE][/LIST]

After a few months of virtually no progress in the first time tests between 28-37M they have been systematically dropping at the rate of 1 every few days.

Three possibilities:
- These slow assignments are coincidentally all starting to finish
- They have been declared too slow and too old and been released to reliable PCs
- Someone is doing some house cleaning

[quote=petrw1;223249]After a few months of virtually no progress in the first time tests between 28-37M they have been systematically dropping at the rate of 1 every few days.

Three possibilities:
- These slow assignments are coincidentally all starting to finish
- They have been declared too slow and too old and been released to reliable PCs
- Someone is doing some house cleaning[/quote]

I choose door number three.

It appears that the first-time LL for 29057299 is still assigned to someone who has had that assignment since 2009-02-08.

[quote=Prime95;222053]I know I shouldn't do this:

[link removed] is a grossly inefficient (you'll have to ask SQLServer programmers why) report. DO NOT use this during the first 10 minutes of the hour. DO NOT use this for a large number of assignments. Acceptable ranges are 21 to 23 million or a range of a few thousand in the first LL or TF areas.[/quote]

Pardon my ignorance, but how could an assignment possibly have an Estimated Completion prior to the last time it was Updated, like [URL="http://mersenne.org/assignments/?exp_lo=34744883&exp_hi=38569603&execm=1&exdchk=1&exfirst=1&extf=1&B1=Get+Assignments"]these[/URL]? :confused:

What is PM1-L?

[QUOTE=ckdo;223271]Pardon my ignorance, but how could an assignment possibly have an Estimated Completion prior to the last time it was Updated[/QUOTE]

I have no idea.

PM1-L is P-1 factoring on large exponents.

[QUOTE=ckdo;223271]Pardon my ignorance, but how could an assignment possibly have an Estimated Completion prior to the last time it was Updated, like [URL="http://mersenne.org/assignments/?exp_lo=34744883&exp_hi=38569603&execm=1&exdchk=1&exfirst=1&extf=1&B1=Get+Assignments"]these[/URL]? :confused:[/QUOTE]

Maybe this is because the user has their machine set up update only every so often but the exponent will be completed prior that next scheduled update. These two dates may not have to coincide- yet the result will be reported when it completes. In other words, the next update may be the date that the machine would normally report progress with the server regardless of whether an assignment was close to finishing or not. However, this is just speculation.

[quote=Primeinator;223301]Maybe this is because the user has their machine set up update only every so often but the exponent will be completed prior that next scheduled update. These two dates may not have to coincide- yet the result will be reported when it completes. In other words, the next update may be the date that the machine would normally report progress with the server regardless of whether an assignment was close to finishing or not. However, this is just speculation.[/quote]

The case at hand is 6 exponents updated this month with completion dates in 2009...

[QUOTE=ckdo;223309]The case at hand is 6 exponents updated this month with completion dates in 2009...[/QUOTE]

I would assume that that is because they have not been started.

If there is no progress, no completion date can be established. Seems like an odd quirk.

[quote=ckdo;223271]Pardon my ignorance, but how could an assignment possibly have an Estimated Completion prior to the last time it was Updated, like [URL="http://mersenne.org/assignments/?exp_lo=34744883&exp_hi=38569603&execm=1&exdchk=1&exfirst=1&extf=1&B1=Get+Assignments"]these[/URL]? :confused:[/quote]Perhaps it was reported without updating the completion dates. (There's a check box for that.)

Double checks for M41 seem to be occurring at a MUCH faster rate now.

[QUOTE=Primeinator;223531]Double checks for M41 seem to be occurring at a MUCH faster rate now.[/QUOTE]

If this is the case, hopefully it will be sufficient to dissuade poaching, narrow the band of work done and satisfy those who have a thing for quasi-arbitrary milestones. The only other issue that may still require some resolution is term limits. A quick look at the first 10 active assignments:

21041719 D 34.00% 639 -26 2010-07-06 2010-07-14 2010-06-16 2008-10-31 blackivory v4_computers
21065063 D 16.80% 500 22 2010-08-23 2010-08-01 2010-07-31 2009-03-19 gangho v4_computers
21076607 D 31.40% 643 281 2011-05-09 2010-07-29 2010-07-28 2008-10-27 ANONYMOUS v4_computers
21096547 D LL, 43.40% 502 16 2010-08-17 2010-07-23 2010-07-22 2009-03-17 ANONYMOUS
*21128461 D 641 13 2010-08-14 2010-08-26 2010-07-29 2008-10-29 ANONYMOUS v4_computers
21131827 D LL, 80.60% 467 5 2010-08-06 2010-08-02 2010-08-01 2009-04-21 ANONYMOUS
21181877 D 85.80% 624 -6 2010-07-26 2010-08-10 2010-07-13 2008-11-15 blackivory v4_computers
21205913 D 94.50% 524 -14 2010-07-18 2010-08-14 2010-07-17 2009-02-23 ANONYMOUS v4_computers
21238873 D 27.90% 635 9 2010-08-10 2010-07-31 2010-07-28 2008-11-04 ANONYMOUS v4_computers
21253487 D 35.70% 631 -1 2010-07-31 2010-08-20 2010-07-23 2008-11-08 ANONYMOUS v4_computers
21260417 D 55.70% 460 -11 2010-07-21 2010-07-22 2010-06-24 2009-04-28 ANONYMOUS v4_computers

I have no issue with slow and steady progress. I couldn't be bothered much by an assignment almost two years old as long as sufficient [subjective] regular progress was being done. However, there is one test (as well as about a half dozen within the first 1,000 assignments currently sorted from smallest to largest and almost or over a year old), 21128461, which has seemingly not started or server does not report work, as mentioned previously, due to the possibility of no network connection (although it's update reporting is current so I assume it has a network connection) or work submission restrained (I suppose forced through editing the prime.txt file or otherwise - I suppose for good reason?), hence requiring manual submission. If the latter is the case, perhaps there should be a renewal process through one's account required with approximate work_done% submitted, otherwise such assignments may remain in limbo for far too long before ultimately being reassigned.

[QUOTE=Primeinator;223531]Double checks for M41 seem to be occurring at a MUCH faster rate now.[/QUOTE]

I haven't implemented my suggestions for unreserving 12-18 month old assignments. I've been watching how preferred assignments are handed out. I'm still seeing some go to v4_computers even though there is code in place to prevent this.

[QUOTE=Prime95;223570]I haven't implemented my suggestions for unreserving 12-18 month old assignments. I've been watching how preferred assignments are handed out. I'm still seeing some go to v4_computers even though there is code in place to prevent this.[/QUOTE]

Even if you had implemented these changes, would it not be too soon to see the fruits? As for the server, that is a rather odd conundrum!

Am I going spare?????
 

Double checks are running fine.

LLs are going backwards.

David

This appears to be the case... I'm keeping a graph starting 8 or so days back for single checks under M47 remaining.