P4 SSE2 routine bug?

Ok now I have run three P4's on these same examples with PRP and I get sum out errors, it wont even start to test 15k*2^29-1. Thomas said he tried one P4Zenon with the same behaviour.

This narrows it down to SSE2, and/or PRP framework.
The machines used have quality parts, that vary in memory syles, ie Rambus, DDR, SDRAM, and plenty of it.

What version are you using George?
I cant seem to find it listed as seperate dates. :?

ebx wrote:

I reproduced the same on my p4 2.26/Win2K
and XP1900+/WinXP.
Does anybody have a Opteron so we can see how AMD does SSE2?

This would be ideal, and quick.
Who could we contact?


Thanks ebx

[trif]

George is presumably using this one:

ftp://mersenne.org/gimps/prp.zip

Yes trif, I have used that one, and found the matching date.
Nope afraid not, errors, with multiple machines.

Can you run the example?

[Thomas11]

I did some new tests with PRP on a P4 machine, runing Linux, and got the following:

Starting probable prime test of 290499495*2^31-1
Bit: 13/60, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 2436568024401 != 2436568024401

Starting probable prime test of 290499495*2^34-1
Bit: 22/63, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 4579612840009 != 4579612840009

290499495*2^36-1 is a probable prime.
...
290499495*2^77-1 is a probable prime.
290499495*2^84-1 is a probable prime.
290499495*2^87-1 is a probable prime.
290499495*2^93-1 is a probable prime.
290499495*2^103-1 is a probable prime.
290499495*2^108-1 is a probable prime.
290499495*2^109-1 is a probable prime.

So the missing (probable) primes are indeed found (as George told us), but I feel uneasy about the SUM(IN)/SUM(OUT) errors. On a Dual-P4-Xeon I get an analoguous behaviour (both machines are NOT overclocked and run very stable on other software ...)

Someone should test this on a Windows machine (P4) too.

Now it looks to me that (besides that SUM(IN/OUT) error) it is a problem of LLR only. :?

Thomas.

[trif]

Originally Posted by TTn

Yes trif, I have used that one, and found the matching date.
Nope afraid not, errors, with multiple machines.

Can you run the example?

I don't have a P4 available.

[Thomas11]

The SUM(IN)/SUM(OUT) errors of PRP, I found earlier on a P4, are reproduced by an Athlon XP (Win98SE) too:

[code:1]Starting probable prime test of 290499495*2^31-1

Bit: 13/60, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 2436568024401 != 2436568024401

Starting probable prime test of 290499495*2^34-1
Bit: 22/63, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 4579612840009 != 4579612840009[/code:1]

Now, this seems to be a different problem to me (not the one we have encountered using LLR).
George, are you able to reproduce that SUM(IN/OUT) error too?

Shane, I have tested the following coefficients/exponents using PRP on my P4 Linux machine and found all of them to be probable primes:

504017085(n=104,117,126,133,605,649)
509070705(n=79,86,107,112,117,586)
515179665(n=76,80,85,110,118,123,126)

LLR reports them as non-primes, mostly followed by a memory fault.
If I understand you correctly, Shane, then on your Windows machine LLR gives you no warning after that negative false tests, right? On Linux I didn't get any warning too, but in most cases LLR stops with a memory fault.
So I would suggest that everyone who encountered such a memory fault too, or who's LLR stops without any reason, should test that last exponent on a different machine or a different software ...

Thomas. :?

The only difference I see, that helped a little it Linux, over windows.
Clearly the framework is faulty.

[Prime95]

Originally Posted by Thomas11

Bit: 13/60, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 2436568024401 != 2436568024401

I wouldn't worry about these "error" reports. The SUM(INPUTS) = SUM(OUTPUTS) test was designed with million digit multiplies in mind. We are comparing two floating point values to see if they are close to each other. Obviously, when testing real tiny numbers the FFT routines need to allow more leeway in this closeness test. I'll work on a fix.

Obviously, when testing real tiny numbers the FFT routines need to allow more leeway in this closeness test

And thats why it was allowed to happen in the first place,
because it was so obvious.
Im sorry but none of what you say adds up.
I wont be downloading any of your patches, thats for sure.
Most of us, have gotten these errors on a P4, with either LLR, or PRP or Prime95 . You have a laptop P4 if I recall correctly.
Since there is no explanation of M40, lets call a spade a spade, same bug until otherwise proven different.

[ET_]

Bit: 13/60, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 2436568024401 != 2436568024401

TTn, all of my SUM(inputs) != SUM(outputs) errors showed different values between the two sides of the equation... while there is no difference between those printed out. Maybe is the trigger that has to be adjusted a "bit" ;)

If you don't give George the credit he deserves, you'd better leave out your 15K search: there are lots of distributed math projects out there... 8)

If you stay here, on the contrary, you only show that your behavior conflicts with your ideas...

Have fun, and just trust the man who started it all...

Luigi