M40, what went wrong?

[jeff8765]

I do not really know, but I think that it was just a freak accident and that there is no inhernet flaw in Prime 95. I think that we will probably just continue as we were before M40 was reported.

[Prime95]

Originally Posted by jocelynl

We don't have any technical details. It would be nice to know what type of hardware was used and overclock if not.

P4 1.6 GHz Willamette, not overclocked

[Paulie]

Ah, v17. Lost a few tests, but hey, I'm still here. Thanks for the ride, it's bound to get only better in the next 10 years. ;) ;)

I only win at Roullete. :D :D :D

[Paulie]

We keep looking for M40. :D :D :D

[alienz]

ops: ops: prime 40 must be getting close, will it be this month???

[trif]

I think it is obvious that this is to blame for the whole "M40" situation. It's obvious the universe was having a hard time coping with this paradox, and it snapped in a very strange way.

I beg you Cheesehead, don't push things this far again or who knows what could happen.

[Prime95]

Originally Posted by ewmayer

Is it prime95 that does the integer conversion, or the compiler? If the former, why not just do the compare-with-zero in floating-point form.

It was the C compiler. I've written a very easy assembly routine to check for NaN and infinity. This way I can be sure it will work on Linux, FreeBSD, OS/2, etc.

In 23.5 prime95 will check for NaN and infinity before checking for zero.

[Prime95]

Originally Posted by ewmayer

It seems EXTREMELY unlikely to me that a run would have valid (non-NaN) data every iteration, then go awry on the very last step, the rounding-and-carry-propagation following the final IFFT. Perhaps something slipped through the on-the-fly NaN checking. Or perhaps there were in fact no NaNs at all in the run in question, but the shift count related to the subtract-2 step (or some other datum used in the carry step) getting corrupted caused the residue to get zeroed in the carry step without triggering any roundoff warnings. Actually, since prime95 only does RO checking every so often (I believe every 100th iteration or so), it's possible there may in fact have been a suspiciously large RO error in the crucial carry step that got missed isn't it?

Several facts to consider:

Every iteration prime95 sums all the input FFT values and all the output FFT values. If sum_input^2 != sum_outputs, then you get a SUM(INPUTS) != SUM(OUTPUTS) error. The output sum is also checked for NaN or infinity. If the sum is one of these values, then you get an ILLEGAL SUMOUT error. If carry-propogation & round-off generates NaNs, then that should be picked up on the next LL iteration.

The last 50 iterations of every LL test do the extra round-off error checking.

My records show 6 LL residue results of 0000000000000002. Thus, there obviously is some way a hardware error can zero the FFT data. I just don't see an easy way for this to happen. Any ideas?

Would a check each iteration for zero or two be a good idea?

[smh]

Would a check each iteration for zero or two be a good idea?

Depending on how much time that costs.

Maybe check it once every million iterations, or even better, prior to writing a new save file. If the residue at that point is 0 or 2, you can go back to the last save file.

[asdf]

Is it possible for an LL test running accurately to go to 0, 1, or 2 before completion?

[Prime95]

Originally Posted by asdf

Is it possible for an LL test running accurately to go to 0, 1, or 2 before completion?

No. And a check every iteration would be real cheap.