Suspect results
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 20180213 77934083 C  Suspect 20180210 77890711 C  Suspect 20180209 77920327 C  Suspect 20180208 77916463 C  Suspect 20180207 77905741 C  Suspect 20180205 77897749 C  Suspect 20180204 Thanks in advance! 
[QUOTE=koekie;479938]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 20180213 77934083 C  Suspect 20180210 77890711 C  Suspect 20180209 77920327 C  Suspect 20180208 77916463 C  Suspect 20180207 77905741 C  Suspect 20180205 77897749 C  Suspect 20180204 Thanks in advance![/QUOTE] A suspect result is assigned back out as if it was a firsttime check. Since those are around the smallest exponents for firsttime 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 doublechecked and verified (your result was fine apparently). 
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.

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

[QUOTE=koekie;479938]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[/QUOTE]
All of your exponents were already assigned as of a few days ago. Most are already partly completed, and one was successfully double checked. 
[QUOTE=VictordeHolland;479976]It is at the boundary of the 4096K FFT / 4480K FFT, so that could explain the 0.4 roundoff errors and suspect result status.[/QUOTE]
Yup, that. Which is why I'd be interested at some point to analyze bad (or even suspectbutgood) 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. 
Thanks for the responses! Glad to see there is no structural problem with the machines causing the suspect results.

You can add these values to prime.txt to help near the FFT boundaries..
From undoc.txt: [QUOTE]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.[/QUOTE] 
All times are UTC. The time now is 05:52. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.