130 GHz-days for a 41M LL?!?

[NBtarheel_33]

Just finished an LL test of M41968981, and was shocked to receive 130.9636 GHz-days of CPU credit! This is about 1.5 times what I usually get for an exponent of this size, and is far more than the 92 GHz-days I recently received for a 50M test. Is there a new crediting formula, or did I just encounter a PrimeNet "feature"?

...not that anyone would complain about such a "feature", I'm sure...

(According to the calculator at mersenne-aries.sili.net, this assignment would normally net just under 73 GHz-days @ 2560k FFT. Could Prime95 have somehow run this test with a larger than necessary FFT?)

[davieddy]

Weird.

[petrw1]

Originally Posted by NBtarheel_33

Could Prime95 have somehow run this test with a larger than necessary FFT?)

That would be one way....

I've noticed with version 26 that at times it will try a few iterations for a new exponent range and if the roundoff is more than expected it will take a higher FFT.

Another hint would come from how long the test took. When a larger FFT is chosen the test takes longer and by a similar measure the credit is higher.

[davieddy]

Originally Posted by petrw1

I've noticed with version 26 that at times it will try a few iterations for a new exponent range and if the roundoff is more than expected it will take a higher FFT.

And my hunch is that this procedure is a stupid way of settling on
the appropriate FFT size.

David

[Prime95]

Can you email prime.log to me? Thanks.

[NBtarheel_33]

Originally Posted by Prime95

Can you email prime.log to me? Thanks.

Sure, I should be able to get it to you later this evening. Thanks.

By the way, I'm thinking that this is definitely an FFT selection problem. I have two similar sized exponents queued on the system in question and their reported completion dates are on the order of 160 and 320 days, respectively.

[davieddy]

Originally Posted by NBtarheel_33

Just finished an LL test of M41968981, and was shocked to receive 130.9636 GHz-days of CPU credit! This is about 1.5 times what I usually get for an exponent of this size, and is far more than the 92 GHz-days I recently received for a 50M test. Is there a new crediting formula, or did I just encounter a PrimeNet "feature"?

...not that anyone would complain about such a "feature", I'm sure...

(According to the calculator at mersenne-aries.sili.net, this assignment would normally net just under 73 GHz-days @ 2560k FFT. Could Prime95 have somehow run this test with a larger than necessary FFT?)

Did it take longer than you expected?

[cheesehead]

Originally Posted by davieddy

And my hunch is that this procedure is a stupid way of settling on the appropriate FFT size.

What's stupid about it?

Experimentation has found that when exponents are near the upper end of an FFT size range, there can be significant differences between the sizes of rounding errors produced from two side-by-side exponents (and this isn't linear, so it's not just a matter of "correcting" the limits of fixed FFT ranges). The extra iterations test is only performed when an exponent is near the upper limit of an FFT range. (How "near" is a settable parameter.)

Most (99%?) exponents never go through that test, so don't "waste" any cycles on it. (Or else, the test finds an acceptable roundoff error with the lower FFT, in which case the LL proceeds from the end of the test, wasting not a single iteration.) But when the test finds a high roundoff error, shifting to the next larger FFT could mean the difference between a bad LL result and a good LL result.

[NBtarheel_33]

Originally Posted by Prime95

Can you email prime.log to me? Thanks.

Done - it's quite long (started back in Sept. 2009), so if you want to cut to the chase, just do a Find on the string "26.3 INSTALLED". It looks like the ETAs went nuts after I installed 26.3; I'm thinking that 26.3 maybe selected a much larger than needed FFT for finishing the test, as well as for the two subsequently queued tests.

[NBtarheel_33]

Originally Posted by davieddy

Did it take longer than you expected?

Now that I think about it, yes it did. And it's claiming that similar sized exponents in the queue will take around five months each to complete - way more than normal.

[NBtarheel_33]

Originally Posted by cheesehead

What's stupid about it?

Experimentation has found that when exponents are near the upper end of an FFT size range, there can be significant differences between the sizes of rounding errors produced from two side-by-side exponents (and this isn't linear, so it's not just a matter of "correcting" the limits of fixed FFT ranges). The extra iterations test is only performed when an exponent is near the upper limit of an FFT range. (How "near" is a settable parameter.)

Most (99%?) exponents never go through that test, so don't "waste" any cycles on it. (Or else, the test finds an acceptable roundoff error with the lower FFT, in which case the LL proceeds from the end of the test, wasting not a single iteration.) But when the test finds a high roundoff error, shifting to the next larger FFT could mean the difference between a bad LL result and a good LL result.

But is 41,968,981 near an FFT boundary? According to the old colorful status page, the boundary between 2048k and 2560k FFTs is 40,250,000. Even with the addition of the 2304k FFT size, I'm thinking that ~42M isn't near enough to an FFT boundary to warrant a round-off check.

Will be interesting to find out what's happening here.