What is a "suspect" result

[sixblueboxes]

http://www.mersenne.org/report_expon...5936641&full=1

Says my "C" result was "suspect". What does that mean?

[Mini-Geek]

Throughout the test, Prime95 does some self-checks to see if you're making good results. If one or more of these checks show some problems, your test may be considered "suspect", which means that it is more likely to have errors than a typical test. Just like any test, it will eventually be independently double-checked until two matching tests happen.

[Madpoo]

Originally Posted by sixblueboxes

http://www.mersenne.org/report_expon...5936641&full=1

Says my "C" result was "suspect". What does that mean?

Ditto what mini-geek said.

In your case, the client reported this an error code of 07000800

I'm not familiar with what the different bits in the error code signify. Specifically, the last 4 hexits: If the error code ends with 0001 or 0100 I guess it's slightly more reliable... if those last 4 are "0000" then it's actually marked as unverified/clean. The first 4 must be related to some other non-critical errors encountered during the run.

George has probably already explained somewhere in the past what those indicate.

[TheMawn]

How does a person look into their error code? I have a suspect run of my own on a machine that has been running clear for quite a while. I am waiting for the triple-check but I really don't like the idea of having a not 100% machine.

FYI: http://www.mersenne.org/report_expon...4246697&full=1

[TObject]

• Go to “Reports–Detailed Reports–LL Results”
• In the second “Exponent range” box put 999999999.
• Activate the “Display results for user name” radio button.
• Uncheck the “Exclude known bad results” and “Exclude results with known factor” check boxes.
• Check the “Exclude verified results” check box.
• Click the “Get LL Data” button.

Then check out the “Error code (if any) column in the unverified test results grid.

HTH

[TObject]

For a particular exponent, you can just do this:
www.mersenne.org/report_ll/?exp_lo=34246697&exp_hi=34246697

[TObject]

The error code “00000100” or "00000200" means your memory could be fried. Try running Memtest86 (I prefer the one without “plus”) for a couple of days non-stop.

If the memory is fine, maybe you had a misfortune of cosmic particle flipping some data during the test.

[S485122]

A reminder for the significance of error codes from a post by George Woltman (http://www.mersenneforum.org/showpos...0&postcount=12)

Jacob

error code = AABBCCDD (in hex)

AA = top bit on means "test was started using a version that did not count errors", remaining 7 bits is count of errors that were reproducible

BB = count of ILLEGAL SUMOUTS

CC = count of round off > 0.4 errors

DD = count of SUM(IMPUTS) != SUM (OUTPUTS)

[Madpoo]

Originally Posted by S485122

A reminder for the significance of error codes from a post by George Woltman (http://www.mersenneforum.org/showpos...0&postcount=12)

Jacob

error code = AABBCCDD (in hex)

AA = top bit on means "test was started using a version that did not count errors", remaining 7 bits is count of errors that were reproducible

BB = count of ILLEGAL SUMOUTS

CC = count of round off > 0.4 errors

DD = count of SUM(IMPUTS) != SUM (OUTPUTS)

Good info. According to that and what the code does when a result is checked in, if there's only 1 error in either CC or DD then it'll still get checked in as clean if that's the first time check.

I can't be sure, but if it's a double-check and it doesn't match the first-time residue, the one with any kind of non-zero error at all will be marked suspect (or if both had some kind of error, both are marked suspect I think).

For example, in the case of The Mawn's result, it logged and error of 00000100. Had that been a first time check it wouldn't have batted an eye, but since it mismatched the first check The Mawn's entry is marked suspect. Nothing personal... the first one could very well have been the bad one.

It's assigned for a triple-check now so you'll know soon enough. Fingers crossed that yours is the winner.

[TheMawn]

Aight thanks.

This one was a bit different. I went back through the logs to see what went wrong. Roundoff was 0.5 and it just straight up went back to the save file as opposed to re-attempting the iteration. This leads me to believe hope that the error was fixed and that nothing else is wrong.

The computer MawnRVE has returned two double-checks since and they match. I know which worker / which core was in charge of the problematic assignment so I'll be keeping an eye on it. At any rate, roundoff = 0.5 is proof that stability isn't exactly 100%. The likelihood of me getting a corrected error while working on an exponent that had a bad residue isn't something I'm holding my breath for either.


Would anyone here like to queue 57499583, 57517877, 57557993 and 57568403 for a double-check? These are first-time LL tests that were running on that CPU at the time of the error and I would like to know sooner rather than later if anything else blew up.

[cuBerBruce]

Originally Posted by TheMawn

Would anyone here like to queue 57499583, 57517877, 57557993 and 57568403 for a double-check? These are first-time LL tests that were running on that CPU at the time of the error and I would like to know sooner rather than later if anything else blew up.

I'll be willing to do the first one, 57499583 (or one of the other ones), if you're willing to do a "triple check" of M51903653.