Suspect results

[koekie]

Recently I have a bunch of suspect results on a bunch of different machines which had recently a power failure. Since all have a suspect status and I can't find exactly why, although I suspect the power failure, I want to ask if anyone is interested in an early double check of one of the following exponents:
77956897 C - Suspect 2018-02-13
77934083 C - Suspect 2018-02-10
77890711 C - Suspect 2018-02-09
77920327 C - Suspect 2018-02-08
77916463 C - Suspect 2018-02-07
77905741 C - Suspect 2018-02-05
77897749 C - Suspect 2018-02-04

Thanks in advance!

[Madpoo]

Originally Posted by koekie

Recently I have a bunch of suspect results on a bunch of different machines which had recently a power failure. Since all have a suspect status and I can't find exactly why, although I suspect the power failure, I want to ask if anyone is interested in an early double check of one of the following exponents:
77956897 C - Suspect 2018-02-13
77934083 C - Suspect 2018-02-10
77890711 C - Suspect 2018-02-09
77920327 C - Suspect 2018-02-08
77916463 C - Suspect 2018-02-07
77905741 C - Suspect 2018-02-05
77897749 C - Suspect 2018-02-04

Thanks in advance!

A suspect result is assigned back out as if it was a first-time check. Since those are around the smallest exponents for first-time checks I guess they'll probably be automatically assigned to someone pretty quick (within a few days or a week maybe).

In fact, it looks like all of them except M77897749 already are assigned to someone, and all within a day of when they were submitted by you. That other one is actually already double-checked and verified (your result was fine apparently).

[cuBerBruce]

I also just got a suspect result for an exponent in the same range (77911433). I had messages about roundoff error > 0.4 throughout the test. This makes me think it may be an issue with the FFT size being used on LL tests in this range. My exponent has also already been reassigned.

[VictordeHolland]

It is at the boundary of the 4096K FFT / 4480K FFT, so that could explain the 0.4 roundoff errors and suspect result status.

[GP2]

Originally Posted by koekie

Since all have a suspect status and I can't find exactly why, although I suspect the power failure, I want to ask if anyone is interested in an early double check of one of the following exponents

All of your exponents were already assigned as of a few days ago. Most are already partly completed, and one was successfully double checked.

[Madpoo]

Originally Posted by VictordeHolland

It is at the boundary of the 4096K FFT / 4480K FFT, so that could explain the 0.4 roundoff errors and suspect result status.

Yup, that. Which is why I'd be interested at some point to analyze bad (or even suspect-but-good) results around the FFT boundaries. Could help narrow down any bands of badness and make the strategic doublechecking a little more focused on the ones most likely to be bad.

[koekie]

Thanks for the responses! Glad to see there is no structural problem with the machines causing the suspect results.

[ATH]

You can add these values to prime.txt to help near the FFT boundaries..

From undoc.txt:

The program no longer uses hard FFT crossover points. The soft crossovers
have two adjustments in prime.txt:
SoftCrossover=n
SoftCrossoverAdjust=n
The first setting controls which exponents are examined. The default value
is 0.2. This means that an exponent that is 0.2% above or below an FFT
crossover point are tested for the best FFT size to use. A value of 0.0
will turn off this soft FFT crossovers feature. The second setting
defaults to 0.000. This controls how aggressive or conservative the program
is in selecting the best FFT size. The program normally uses the smaller
FFT size if the average roundoff error is below a value in 0.241 to 0.243
range. If you set SoftCrossoverAdjust to say 0.003 then the program will
use the smaller FFT size if the average roundoff error is below a value
in 0.244 to 0.246 range. This will generate more iterations that generate
roundoff error above 0.40 warnings and a time loss returning to the previous
save file. It also increases the chance that a deadly roundoff error
above 0.6 will occur. On the plus side, using the smaller FFT size each
iteration will be a bit quicker. I wouldn't set this adjustment to more
than 0.006. If you set SoftCrossoverAdjust to say -0.002, then the program
will be more conservative and use the larger FFT size more often.