PrimeNet has mechanisms to take care of stragglers according to established standards. Let it work.

[quote=cheesehead;214659]PrimeNet has mechanisms to take care of stragglers according to established standards. Let it work.[/quote]
Wouldn't an exponent that's being worked on 1 hour a day (and therefore, expected completion dates updated daily) have its expiry date forever pushed off into la-la land and never be reassigned? (Or am I missing something here?)

[quote=mdettweiler;214701]Wouldn't an exponent that's being worked on 1 hour a day (and therefore, expected completion dates updated daily) have its expiry date forever pushed off into la-la land[/quote]No, not forever. Why exaggerate, if you have a sound argument?

[quote]and never be reassigned?[/quote]No, not never. Why exaggerate?

[quote](Or am I missing something here?)[/quote]a) Do we have actual evidence that an exponent is being worked on for only 1 hour/day?

b) Suppose we do. So, what? What harm, if any, does it do to GIMPS?

As I have explained multiple times, it is better to have a contribution from a "slow" computer while faster systems work on other exponents, than not to have that "slow" contribution. 1001 kph is faster than 1000 kph.

If we were to divert a "fast" system to perform the assignment being worked-on by the "slow" system, that would:

a) prevent the "fast" system from working on some other assignment, [I]thus guaranteeing a delay in a future milestone[/I], and

b) tend to discourage owners of "slow" systems from contributing. (But 1001 kph is faster than 1000 kph.)

So, if you're impatient, just turn your attention elsewhere. That's not only the best way to help GIMPS; it's also handy in other life situations.

Why would anyone want to delay a future milestone for the purpose of needlessly speeding up a current milestone, and perhaps (if the poaching discourages a "slow" system owner from future participation) slowing down overall GIMPS progress? Is it only because of shortsightedness?

GIMPS/PrimeNet has been designed to make efficient use of systems, whatever their speeds. Let it work.

[QUOTE=mdettweiler;214701]Wouldn't an exponent that's being worked on 1 hour a day (and therefore, expected completion dates updated daily) have its expiry date forever pushed off into la-la land and never be reassigned? (Or am I missing something here?)[/QUOTE]You are missing the following provision from the [url=http://www.mersenne.org/thresholds/]Assignment Thresholds[/url] : "The server may reassign exponents when the assignment is more than one year old." (With a little syntax correction on my part.)

What might be necessary is a review the assignment thresholds...

Jacob

[quote=cheesehead;214704]No, not forever. Why exaggerate, if you have a sound argument?

No, not never. Why exaggerate?

a) Do we have actual evidence that an exponent is being worked on for only 1 hour/day?

b) Suppose we do. So, what? What harm, if any, does it do to GIMPS?

As I have explained multiple times, it is better to have a contribution from a "slow" computer while faster systems work on other exponents, than not to have that "slow" contribution. 1001 kph is faster than 1000 kph.

If we were to divert a "fast" system to perform the assignment being worked-on by the "slow" system, that would:

a) prevent the "fast" system from working on some other assignment, [I]thus guaranteeing a delay in a future milestone[/I], and

b) tend to discourage owners of "slow" systems from contributing. (But 1001 kph is faster than 1000 kph.)

So, if you're impatient, just turn your attention elsewhere. That's not only the best way to help GIMPS; it's also handy in other life situations.

Why would anyone want to delay a future milestone for the purpose of needlessly speeding up a current milestone, and perhaps (if the poaching discourages a "slow" system owner from future participation) slowing down overall GIMPS progress? Is it only because of shortsightedness?

GIMPS/PrimeNet has been designed to make efficient use of systems, whatever their speeds. Let it work.[/quote]
I think you misunderstood what I was saying: I wasn't by any means advocating poaching to move ahead milestones, just asking because as I understood it at the time, assignments really would be kept reserved for all eternity as long as the assignee continued to report progress. Jacob's answer has since clarified that.

I thought my "Or am I missing something here" clarified my intended meaning adequately, but it seems not.

[QUOTE=S485122;214706]"The server may reassign exponents when the assignment is more than one year old." Jacob[/QUOTE]

This happened to me personally a few months ago. One of my team PC's which due to a long story, I no longer have access to was used VERY sporadically. Some assignments that due to this low activity did NOT finish in 365 days were dropped by the server.

[QUOTE=mdettweiler;214701]Wouldn't an exponent that's being worked on 1 hour a day (and therefore, expected completion dates updated daily) have its expiry date forever pushed off into la-la land and never be reassigned? (Or am I missing something here?)[/QUOTE]

[quote]No, not forever. Why exaggerate[/quote]
Theoretically, an exponent could be worked on for less than a second every 59 days on a slow computer. That comes out to about 1 iteration every 2 months, and the 60 day update limit will still be satisfied.

It'll take a year just to complete 6 iterations, and more than three million years to finally complete a 6 million digit candidate.

[quote]"The server may reassign exponents when the assignment is more than one year old." [/quote]
The key word is "may", not "will".
edit: This doesn't mean that I support poaching. However, if that one exponent holding up the double checking milestone is somehow still there after a few years, I bet the attitudes towards poaching would change.

I know this message wasn't directed at me, but I'll go ahead and respond.
[QUOTE=cheesehead;214704]
If we were to divert a "fast" system to perform the assignment being worked-on by the "slow" system, that would:

a) prevent the "fast" system from working on some other assignment, [I]thus guaranteeing a delay in a future milestone[/I],
[/quote]
Not necessarily. You're assuming that the fast system is always busy, while this isn't always the case. Let's say that I have a fast system that I usually use to play games. One day, I see the GIMPS milestone page and decide to poach an exponent. Instead of playing a computer game that day, I decide to leave it on until the exponent finishes and do something else less CPU-intensive, like surfing the web.

Now what happens if I didn't poach that exponent? No benefit to GIMPS or any other DC project; I just continue playing games in my spare time instead of doing some web surfing.

[quote]
b) tend to discourage owners of "slow" systems from contributing. (But 1001 kph is faster than 1000 kph.)
[/quote]
Not always. Many of those "slow" systems cannot participate on higher exponents due to factors such as a lack of memory or a lack of stability for multi-year periods. Even worse, they may be unattended and forgotten, and the original searcher of the exponent that got poached won't even know or care what happened.

[quote]
So, if you're impatient, just turn your attention elsewhere. That's not only the best way to help GIMPS; it's also handy in other life situations.
[/quote]
True, but patience has a limit. Waiting a few weeks, months, or even years is fine in certain cases, but you'll have a hard time finding anyone who's willing to wait a couple of centuries. In an extreme case, how would you feel about waiting for the sun to burn up?

[quote=S485122;214706]"The server may reassign exponents when the assignment is more than one year old."[/quote]
I wonder just what the criteria for this is, considering [URL="http://www.mersenne.org/report_exponent/?exp_lo=20742307"]M20742307[/URL]'s (which was poached) proper assignment is now over 18 months old and was never reassigned. In any case, [URL="http://www.mersenne.org/report_exponent/?exp_lo=20425091"]M20425091[/URL], the last one, has only been assigned for just under 7 months, so assuming ANONYMOUS has been checking in updates on the number, I don't see it as unusual that it's not been reassigned.
Have we heard from one of the people in charge (George or Scott(?)) whether the reassignment is working properly, and what more specifically is the requirements for the server to reassign? (since e.g. that 1.5-year-old assignment was not reassigned)

[QUOTE=Mini-Geek;214762]Have we heard from one of the people in charge (George or Scott(?)) whether the reassignment is working properly, and what more specifically is the requirements for the server to reassign? (since e.g. that 1.5-year-old assignment was not reassigned)[/QUOTE]I do not know if the reassignment of work-units older than a year work. I do not remember George or Scott commenting about it. I do remember something about (factoring ?) manual assignments in the higher ranges having a longer expiration time.

Perhaps some of the straggling exponents are at the bottom of long worktdodo.txt files ?

I must say that I find all those assignments of small exponents to some of the Anonymous accounts strange : how can they build up enough reliability and confidence ? Confidence is the number of LL (first time or double-check) tests completed without error. A computer needing more than a year to finish a test will have difficulty accumulating confidence. Once again the Assignment Thresholds must be periodically reviewed. For instance the threshold for unknown computers should be round 26 M, leaving the trailing edge to known computers.

For exponents above 24 930 000 the FFT size is 1536 KiB. The double checks will soon be out of reach for slower computers (200 ms iteration time still implies two month to complete a double check.) There has been so much LMH factoring done lately by quick computers (because of productivity expressed in GHz days) that even that could get out of reach for slower computers.

Jacob

The DC for M20742307 was poached, and then completed on April 17. Don't you mean something else?