[QUOTE=chalsall;364987]
1. Any candidate held for 120 days without reported [I]progress[/I] is automatically recycled.[/QUOTE]

In early January I left a computer in N.C. running until mid-May unattended and without an internet connection.

[QUOTE=Prime95;364995]In early January I left a computer in N.C. running until mid-May unattended and without an internet connection.[/QUOTE]

How much progress did said computer achieve (and I'm assuming you mean last year, since we're now in late January 2014)?

Could you please, sir, speak a little more deeply about the current debate?

[QUOTE=chalsall;364987]In all honesty, and to be quite frank, it almost seems like George is tacitly approving this current "poaching" activity.[/QUOTE]

I had no objections to tha's very conservative approach. I think your proposal and TheMawn's are too aggressive.

Some rambling thoughts of my own:

As best we can, we need to honor our prior commitment to not recycle for a year exponents that are being actively reported.

I don't think we can place much value on the %complete metric. I often queue up months of work. These exponents report no progress until they finally reach the top of the queue and then they finish quickly.

We can however use the %complete metric once it goes non-zero. If an exponent starts progressing at 1% a week for an extended period of time, it is likely to take a 100 weeks. The downside is the server does not keep a history of this data.

We need to come up with different strategies for DC and LL work at or near the trailing edge. LL work in the 100M area. Other DC and LL work. TF and P-1 work. ECM work. IIRC, this where my proposal 5 years ago failed.

Manual assignments do need to default to a longer time to expire. When I download exponents for a GPU, I get several months worth (and extend the expiration dates). I don't want to be bothered with doing this manually every 1, 2, or even 3 months.


How to proceed? Do you want me to start separate threads for each strategy with an initial proposal?

[QUOTE=chalsall;364996]How much progress did said computer achieve?[/QUOTE]

I left the computer in January 2014, so we don't know. I did several tests of having it reboot after a manufactured power failure. It passed all the tests, so I have hopes it will be able to run for 4+ months straight.

[QUOTE=Prime95;364998]How to proceed? Do you want me to start separate threads for each strategy with an initial proposal?[/QUOTE]

Yes. Please.

The current situation with Primenet is demonstrably sub-optimal.

[QUOTE=Prime95;364999]I left the computer in January 2014, so we don't know. I did several tests of having it reboot after a manufactured power failure. It passed all the tests, so I have hopes it will be able to run for 4+ months straight.[/QUOTE]
Similarly, I've left a few tests without supervision for what is now getting to be near the end of [URL="http://mersenneforum.org/showthread.php?p=335439#post335439"]the "free year" (on the EC2 cloud)[/URL]. All of them finished without an error, but were quite slow (and [I]so what[/I]). They did the job (even if only 3 or 4 DC tests per year).

I have retired them now. [SIZE=1]I've later used a free instance of so-ugly-it's-beautiful 32-bit linux "tiny"s which I used as a time machine to travel back to 2007 and build modified NewPGen binaries (one needs an ancient gcc-3 and accompanying static libs). [/SIZE]

[QUOTE=Batalov;365002]Similarly, I've left a few tests without supervision for what is now getting to be near the end of [URL="http://mersenneforum.org/showthread.php?p=335439#post335439"]the "free year" (on the EC2 cloud)[/URL]. All of them finished without an error, but were quite slow (and [I]so what[/I]). They did the job (even if only 3 or 4 DC tests per year).[/QUOTE]

From my perspective, we're trying to figure out and agree as to what is reasonable and fair.

Slow (or often offline) computers are more than welcome. But they should be assigned work which is appropriate for their ability. Ideally the curves would cross perfectly.

It's a difficult problem. But, then, we here often deal with difficult problems....

Agreed. Clearly defined rules and open discussion are fine things to have.

(As opposed to simply poaching "because the bureaucracy will be too slow to change the rules". Here, at GIMPS, the list of bureaucrats is very short ;-) and they actually demonstrate reasonable nimbleness.)

You wouldn't want to turn away any live users, no matter how slow they are. What seems to be the problem are zombies/unmanned droid type of things. You need a Turing like test to recognize their behaviors from the patterns in the existing database of accesses (which is hard because it is not very detailed) - and at the same time not hurt live users no matter how closely they might look like droids. When you set the new rules, you leave a grandfathered period for old rules, too - you are right in theory that "Slow computers ... should be assigned work which is appropriate for their ability." But they enter the pool all the time and you don't know if they are slow or not right away; and then fast forward to "now", they have the assignments and they are holding "the milestones" and if we will yank some assignments away, we will arguably have some immediate acceleration and then (depending on the fairness of the execution) piss more (or less) live users off and they will leave. Try to integrate this.

Conservative changes make sense.

[URL="http://mersenne.org/report_milestones/"]Countdown to proving M(30402457) is the 43rd Mersenne Prime: 15[/URL]

:max:

It appears that I have been absent for a great deal of interesting conversation. :coffee:

[QUOTE]some grow impatient with those who waste our time holding up milestones,.[/QUOTE]I've seen this and similar complaints many times over the years.

[U]Not one single person has EVER been able to explain to me what "waste" occurs in these case![/U]

In fact there is no "waste" involved, but what there _is_ is that some people want to justify taking poaching-type (or assignment-cancelling) action by projecting their own internal feelings of impatience onto the GIMPS project. By doing this, they can pretend that GIMPS is somehow "impatient" with the progress of milestones, but that's only their own self-deception, not reality.

Such people need to learn self-control, not propose rules that unjustifiably demean the contributions of "slow" systems.

[B]If anyone disagrees, then please publicly explain just how there is any [U]"waste"[/U] when milestones are not achieved as fast as impatient people want them to be completed.[/B] Do NOT confuse project "waste" with internal feelings of impatience because of poor self-control.