SkylakeX teasers (aka prime95 29.5) - Page 33

Chuck · 2019-02-12, 20:11

Just for fun I just updated to build 10. I have been running 29.5 doing LL DC with no errors since the "Chuck fix" when George changed the register saves.

However, when build 10 started I immediately got an "Invalid FFT data. Restarting from last save file."

I went back to build 9.

simon389 · 2019-02-13, 00:53

Oh my gosh. You solved it. I moved all my systems back to build 9 (with the RAM still slightly underclocked like what it took to pass AIDA64) and they are all STABLE.

The quest is complete.

Prime95 · 2019-02-13, 02:09

Quote:

Originally Posted by Chuck

Just for fun I just updated to build 10. I have been running 29.5 doing LL DC with no errors since the "Chuck fix" when George changed the register saves.

However, when build 10 started I immediately got an "Invalid FFT data. Restarting from last save file."

I went back to build 9.

Oops, sorry about that -- dumb programming error in the new check for errors returned by generateResidue64. Do not use build 10 for LL testing, PRP is just fine.

GP2 · 2019-02-13, 02:36

Quote:

Originally Posted by simon389

I'm still having major hardware troubles with the 29.5b10 release.

29.4 still works great on all 3 9800X machines, but 29.5b10 cannot get a stable LL doublecheck, no matter what settings I use.

Quote:

Originally Posted by simon389

I've always used brand new installations of build 10, so I'm unsure how prime.txt and local.txt could have bad settings. I will install Linux, run Prime95 via Linux, and see if that helps.

Somehow I missed the fact that you were using build 10. Oops.

I don't think a Linux version of it was ever released, anyway.

kriesel · 2019-02-13, 02:58

Quote:

Originally Posted by Prime95

Oops, sorry about that -- dumb programming error in the new check for errors returned by generateResidue64. Do not use build 10 for LL testing, PRP is just fine.

Well that's a pretty sneaky way of motivating LL testers to switch to PRP!

Meanwhile, simon's

I suppose it's too late in the build numbering to suggest further error detection features.

Quote:

Originally Posted by GP2

I don't think a Linux version of it was ever released, anyway.

re linux builds, I've seen at least 3, 4, 5, 6, 9.

Flammo · 2019-02-13, 10:27

Quote:

Originally Posted by Prime95

Oops, sorry about that -- dumb programming error in the new check for errors returned by generateResidue64. Do not use build 10 for LL testing, PRP is just fine.

I've also fallen into this trap, downloading the 'latest' p95 29.5.10 on the major downloads sites, and getting these errors with DC's and LL's over 4 out of 4 PC's. I thought it was to do with having merged my 4 workers on each of the PC's to a single, after performing benchmarks and finding the single worker is indeed the way to go these days, and I thought that maybe it had to be finished on the core it had started on. Unfortunately in a desperate attempt to resolve my same error, I released a bit of progress on some LL exponents :(

I'd love to see this problematic false error in 29.5 built 10 be updated ASAP so that others don't also do the same and ditch their current progress, and either way thought I better also report the issue. Am rolling back to 29.5 b9 now. Just updated to the latest beta as I've been working on a Google Sheet to visually compare the benchmark results to help me and my brother gain confidence what the best worker thread numbers to use should be.

Flammo · 2019-02-13, 11:06

Quote:

Originally Posted by simon389

Oh my gosh. You solved it. I moved all my systems back to build 9 (with the RAM still slightly underclocked like what it took to pass AIDA64) and they are all STABLE.

The quest is complete.

I thought my quest was complete. I have one computer that's started giving 15 illegal sumout errors on a LL exponent. Going back to build 9 isn't helping on one of my PC's. Does having an illegal sumout have anything to do with these latest error checking bugs? I'm hoping it does as I've never had such messages with 29.4 and prior for several years with these PCs.

Flammo · 2019-02-13, 21:43

Just to follow up, I've rolled back to build 9 from build 10, it has resolved all my Bad FFT Data errors, but replaced them all with Illegal Sumout errors.

Having never had these illegal sumout messages before with 29.4 (and upgrading straight to 29.5 build 10, then back to build 9), I'm wondering has something gone wrong when rolling back from build 10, back to build 9, or is there extra checking performed in 29.5 which hasn't been the case in 29.4, and that by coincidence all my PCs are running with hardware errors for LL and DC, only detected the first time with some new checking in 29.5?

I'm assuming I should just keep running with all these "possible hardware errors have occurred during the test - 15 or more illegal sumout - confidence in final result is excellent" messages. I read on https://www.mersenne.org/various/math.php that illegal sumouts are not counted as serious errors. Forgive my ignorance, but would this not have occurred if I'd been running SUM(INPUTS) error checking as enabled from the beginning of each test on each PC?

Advice on whether this is just a bug with the beta and what I've done with rolling back from build 10, or whether I have to be concerned with hardware problems would be most appreciated.

chalsall · 2019-02-13, 21:57

Quote:

Originally Posted by Flammo

Advice on whether this is just a bug with the beta and what I've done with rolling back from build 10, or whether I have to be concerned with hardware problems would be most appreciated.

People who actually know will respond shortly.

"Don't Panic" ^TM Your kit is probably (read: statistically likely to be) OK.

Prime95 · 2019-02-13, 22:57

Quote:

Originally Posted by Flammo

Just to follow up, I've rolled back to build 9 from build 10, it has resolved all my Bad FFT Data errors, but replaced them all with Illegal Sumout errors.occurred during the test - 15 or more illegal sumout - confidence in final result is excellent"[/I] messages.

Short answer -- all is well, carry on.

Long answer: When you erroneously got the Bad FFT Data errors prime95 updated the error count in the save file (the error counter it updated is the same one as the illegal sumout error counter which maxes out at 15).

You are now getting a warning that "sometime during the LL test 15 errors occured". You now those errors were erroneous and can ignore the message.

Why does prime95 warn you about errors that occurred days ago? Because it is likely that the user missed the error messages when they happened and they subsequently scrolled off the screen. The warning lets the user know there may be messages worth investigating in the results.txt file.

BTW, if those messages bother you add "ErrorCountMessages=0" to prime.txt. Described in undoc.txt.

Sorry about the mess -- the dangers of using beta software.

Flammo · 2019-02-14, 02:58

Quote:

Originally Posted by chalsall

"Don't Panic" ^TM Your kit is probably (read: statistically likely to be) OK.

Thanks chalsall, this message really helped to ease my nerves this morning!

Thanks Prime95 (George?), your help is much appreciated. Have been running some torture tests on my fleet just to be safe and all seems well.

I have enjoyed beta testing the new Prime95's and will certainly just restrict my beta testing to only one in my fleet at a time, in future ;-)

On the topic of beta testing, and just as a little bit of feedback of the good intent variety. I've always found it interesting that when you type 'download prime95' into a search engine, every woman and her dog seems to be fileserving the latest prime95 beta versions but not the stable version available from mersenne.org. As a long term user I've kind of formed an impression of these fileservers being used to save the mersenne server from download activity, and that mersenne.org just needs to be updated but no one has had time to update the website with the latest p95 version, as no one gets paid to run the GIMPS. I'm learning that these fileservers really are serving quite beta versions though. I'm proud to be bleeding on the edge and be part of the evolution process and tell my grand-kids where I was in 2019 doing this. But, I fear others might not really realise that unless you download from mersenne.org it shouldn't be assumed as stable. So my thoughts are have you considered labelling the beta versions out in the wild on these file servers as beta, and serving the beta on mersenne.org to keep the masses searching for the latest beta drawn to the site? (No need to actually respond, just sharing a perspective that might not be obvious to people more actively involved in me than GIMPS).

Thanks again! :-)

2019-02-12, 20:11	#353
Chuck May 2011 Orange Park, FL 1556₈ Posts	Build 10 Just for fun I just updated to build 10. I have been running 29.5 doing LL DC with no errors since the "Chuck fix" when George changed the register saves. However, when build 10 started I immediately got an "Invalid FFT data. Restarting from last save file." I went back to build 9. Attached Thumbnails

2019-02-13, 00:53	#354
simon389 Aug 2013 57₁₆ Posts	Oh my gosh. You solved it. I moved all my systems back to build 9 (with the RAM still slightly underclocked like what it took to pass AIDA64) and they are all STABLE. The quest is complete.

2019-02-13, 21:43	#360
Flammo Feb 2019 1100₂ Posts	Just to follow up, I've rolled back to build 9 from build 10, it has resolved all my Bad FFT Data errors, but replaced them all with Illegal Sumout errors. Having never had these illegal sumout messages before with 29.4 (and upgrading straight to 29.5 build 10, then back to build 9), I'm wondering has something gone wrong when rolling back from build 10, back to build 9, or is there extra checking performed in 29.5 which hasn't been the case in 29.4, and that by coincidence all my PCs are running with hardware errors for LL and DC, only detected the first time with some new checking in 29.5? I'm assuming I should just keep running with all these "possible hardware errors have occurred during the test - 15 or more illegal sumout - confidence in final result is excellent" messages. I read on https://www.mersenne.org/various/math.php that illegal sumouts are not counted as serious errors. Forgive my ignorance, but would this not have occurred if I'd been running SUM(INPUTS) error checking as enabled from the beginning of each test on each PC? Advice on whether this is just a bug with the beta and what I've done with rolling back from build 10, or whether I have to be concerned with hardware problems would be most appreciated.