Modifications to DC assignment rules

[Prime95]

Wow. Querying LL results below 50e6 returned this year:

Assigned more than 240 days: 373
Assigned more than 270 days: 294
Assigned more than 300 days: 217
Assigned more than 330 days: 158
Assigned more than 360 days: 133
Assigned more than 450 days: 82
Assigned more than 540 days: 55
Assigned more than 720 days: 20
Assigned more than 2100 days: 1

So moving the cat 4 requirement from 360 to 240 would possibly have expired and reassigned 240 DC results that later completed (in less than 4 months). I guess lowering the 360-day limit is not a great idea.

Also, the perseverance award to Mr. 2184 days to complete a single LL test!!! I wonder if it matched....

[Prime95]

Originally Posted by Syntony

A double-check which disagrees with the first LL check is apparently counted as 'suspect'

That is not my understanding. A suspect result is one where the error code returned by prime95 indicates there may have been a hardware error.

There are rare times when operating near the limit of an FFT where you could get a non-reproducible roundoff error. I don't think it has ever happened to me, so it is definitely rare.

[axn]

Originally Posted by Prime95

There are rare times when operating near the limit of an FFT where you could get a non-reproducible roundoff error. I don't think it has ever happened to me, so it is definitely rare.

I would have thought that since FFT computation is deterministic, this shouldn't even be possible in theory! What could be the possible source(s) of s/w non-reproducibility?

[Syntony]

OK, my fault, I've just spotted my mistake - I tried freeing DC 35963129 (Cat 1 currently) and got DC 36809363 (Cat 2) back as a replacement. I didn't get Cat 1 as my 'days of work' was still set to 10 (now reduced). I guess I was mislead by the e-mails I get whenever my DC doesn't agree with the original LL, which tell me that my result was suspect! Got 35963129 back now...

[Prime95]

Originally Posted by axn

I would have thought that since FFT computation is deterministic, this shouldn't even be possible in theory! What could be the possible source(s) of s/w non-reproducibility?

FFT computation is deterministic.

However, the assembly carry propagation code does not guarantee FFT data will be in balanced notation. It does guarantee it will get really, really close -- enough so that roundoff errors will only increase by an insignificant amount. But, when FFT data is read from a save file, the FFT data is in 100% balanced notation. So, after a roundoff error we could go back to the last save file and get a different round off error.

[axn]

Originally Posted by Prime95

However, the assembly carry propagation code does not guarantee FFT data will be in balanced notation. It does guarantee it will get really, really close -- enough so that roundoff errors will only increase by an insignificant amount. But, when FFT data is read from a save file, the FFT data is in 100% balanced notation. So, after a roundoff error we could go back to the last save file and get a different round off error.

Ah!

Would it make sense to use the balanced data used for savefile (is it balanced when written or only upon reading back?) for normal computation so that we have full reproducibility or will there be a net performance loss?

[markr]

To get Cat 2 manual DC or LL assignments, is there more to it than signing up for the smallest exponents? The server gives me Cat 3 DCs and LL. I have a vague recollection of reading about a possible throughput criterion for manual tests in the new LL rules thread.

That aside, the new rules look very good & it will be interesting to see how the system settles down - and then the self-adjusting part! But perhaps better than that is the process of George et al and the community settling the new rules. I raise my cup to you all!

[Madpoo]

Originally Posted by Prime95

That is not my understanding. A suspect result is one where the error code returned by prime95 indicates there may have been a hardware error.

There are rare times when operating near the limit of an FFT where you could get a non-reproducible roundoff error. I don't think it has ever happened to me, so it is definitely rare.

I get those sometimes... I've had two in the past week, but that could be due to testing exponents in the 39M range which is near an FFT boundary. In each case, I think the initial FFT size test put me just barely into the lower FFT size and then it started having roundoff errors along the way. In one of the two cases, I think a roundoff error occurred near the end of the run so it may not have had a chance to try reproducing it before it just finished.

In both cases, my result matched the first check, but it did get marked as a suspect result.

But yeah, ditto what you said... a mismatch is not a suspect result...only certain errors reported during the run will mark a result as suspect, not whether or not it mismatched.

However, many mismatches *are* due to a suspect result during the first run, and that's because a first-time test coming in as "suspect" means it's re-assigned as another first-time check right away.

Which is good, because roughly 50% of all tests marked "suspect" do end up being bad. It's not uncommon at all to look at mismatches and see that the first one is suspect but the second one is simply listed as unverified.

[Siegmund]

Interesting how many DCs were completed very slowly.

And I have to reiterate my objection form the other thread about a very short queue length as a criterion for small exponents. (Briefly, I want to be able to leave for a week and be confident my machine won't have gone idle if it has a network hiccup, and one Friday to the subsequent Monday is conveniently 10 days, not 5.)

Guess I better be happy I got one more 35M assignment yesterday before the new rules took effect...

[chalsall]

Originally Posted by Siegmund

And I have to reiterate my objection form the other thread about a very short queue length as a criterion for small exponents. (Briefly, I want to be able to leave for a week and be confident my machine won't have gone idle if it has a network hiccup, and one Friday to the subsequent Monday is conveniently 10 days, not 5.)

Personally I find this to be a bit of straw-man argument. Some of my machines which work for GIMPS go years without my ever being in front of them. Heck, three are over five years old, and I've never once even seen them (they're rented co-located servers, somewhere...).

Originally Posted by Siegmund

Guess I better be happy I got one more 35M assignment yesterday before the new rules took effect...

Not to be widely encouraged, but if you're *really* concerned about this before a trip you can always "cheat" the system. Bring your "Days to reserve" down, reserve a few assignments (cutting and pasting your worktodo.txt file(s)) and then amalgamate the assignments.

But, honestly, when was the last time you had a network issue which would have resulted in your systems being idle?

[Siegmund]

Yes, I am aware that I can manipulate the system. (The fact still remains that I don't think the queue length requirement serves any purpose, so long as there is a requirement about time from assignment to completion.)

But, honestly, when was the last time you had a network issue which would have resulted in your systems being idle?

Since you asked...

I had just such an issue most of the time from October 2014 to December 2015. I had two systems sitting on my desktop at work (one of them with the screen off and ignored most the time.) That latter system, for some bizarre reason, could report results, but threw an odd proxy error when it tried to fetch new assignments. If, however, I logged in to mersenne.org in a web browser on that machine, it became able to fetch them again (for a short time.)

I did not have any idle time for Prime95 as a result, but I did have several days, twice, when MISFIT was idle for lack of factoring assignments -- I became aware of the problem when I checked my recent results from another computer and saw that no factoring had happened. (And then it happened again because I thought it was just a transient issue.)

MISFIT was only retrieving about 1 week's worth of factoring work at a time, and each task finished quickly. As it happened, Prime95 was fetching 10 days ahead and the DCs took 5 days each on that machine (LLs about 3 weeks), so I noticed the lack of factoring first.

I have actually used that machine regularly this spring. But I am very aware of the possibility of it happening again the next time I am away from the office for an extended period.

* * *

I agree that most network hiccups are shorter duration, unless there is a persistent configuration issue.