primenet: Error code: 45 - mfaktc 95bit_mul32_gs

[mattmill30]

Using mfaktc-0.21 on Windows 7 64bit and the automatically selected 95bit_mul32_gs kernel, I encountered the following error when reporting 'M332347303 has a factor: 38814612911305349835664385407 [TF:77:81:mfaktc 0.21 95bit_mul32_gs]':

Splitting composite factor 38814612911305349835664385407 into:
* 48684837137044687
* 797262868561
processing: TF factor 48684837137044687 for M332347303 (277-281)
Error code: 45, error text: 48684837137044687 is not a factor of M332347303
processing: TF factor 797262868561 for M332347303 (277-281)
Error code: 45, error text: 797262868561 is not a factor of M332347303

I believe the factor was found at class 165, however I've run these follow-up tests without a result:
77-78 class 665 ( barrett87_mul32_gs - GPUSievePrimes=82486 GPUSieveProcessSize=8 GridSize=0)
77-78 class 168 ( barrett87_mul32_gs - GPUSievePrimes=1075765 GPUSieveProcessSize=8 GridSize=0)
78-79 class >165 ( barrett87_mul32_gs - GPUSievePrimes=1075765 GPUSieveProcessSize=8 GridSize=0)
79-80 class 200 ( barrett87_mul32_gs - GPUSievePrimes=1075765 GPUSieveProcessSize=8 GridSize=0)
80-81 class 225 ( barrett87_mul32_gs - GPUSievePrimes=1075765 GPUSieveProcessSize=8 GridSize=0)
77-81 class 168 ( 95bit_mul32_gs - GPUSievePrimes=1075765 GPUSieveProcessSize=32 GridSize=3).

Note: the results.txt still contained the original result during the follow-up tests.

AFAIK, the GTX 660 isn't OC'd.

Is it possible to determine which class would have contained the reported factor?
Can anyone recommend a method for diagnosing an invalid factor report?

[firejuggler]

hmmm both seem to be factor of M3321928619 instead.
http://factordb.com/index.php?query=48684837137044687-1
and http://factordb.com/index.php?query=797262868561-1

please note that M3321928619 is well beyond GIMPS scope ( for now)

[Madpoo]

Originally Posted by firejuggler

hmmm both seem to be factor of M3321928619 instead.
http://factordb.com/index.php?query=48684837137044687-1
and http://factordb.com/index.php?query=797262868561-1

please note that M3321928619 is well beyond GIMPS scope ( for now)

I think mersenne.ca keeps track of factors as large as 2^32 (4,294,967,296) ... not sure about that.

Primenet only knows about stuff up to 999,999,999

I was actually looking last night at what it would take to at least track factors up to the same size as mersenne.ca. I didn't get too far, but it would be nice to get that coordinated with James.

[ET_]

Originally Posted by Madpoo

I think mersenne.ca keeps track of factors as large as 2^32 (4,294,967,296) ... not sure about that.

Primenet only knows about stuff up to 999,999,999

I was actually looking last night at what it would take to at least track factors up to the same size as mersenne.ca. I didn't get too far, but it would be nice to get that coordinated with James.

If you need data from the Billion digits project, be my guest

[mattmill30]

I'm interpretting the responses as meaning that the cause of the primenet error is because factors of the composite factor 38814612911305349835664385407 (48684837137044687 and 797262868561) are > 999999999.

However, my question is whether primenet is correct in reporting that neither factor is valid for M332347303?

More importantly, why hasn't mfaktc reported the same factor on the 77-81 retest; or if they aren't valid, how do I diagnose the cause of the false positive?

[axn]

Originally Posted by mattmill30

However, my question is whether primenet is correct in reporting that neither factor is valid for M332347303?

Originally Posted by firejuggler

hmmm both seem to be factor of M3321928619 instead.
http://factordb.com/index.php?query=48684837137044687-1
and http://factordb.com/index.php?query=797262868561-1

Already answered. They are both factors of a different Mersenne number and cannot be the factor of M332347303.

Couple of things:
1) The composite factor is 95 bits. So it should not have been found by the mfaktc run for 77-81 bit level(s).
2) It is for a completely different exponent.

Conclusion
There was internal corruption during that particular mfaktc run, where both the exponent and the bitlevel got corrupted.

EDIT:- Please redo the entire run.

[TheJudger]

Originally Posted by axn

Conclusion
There was internal corruption during that particular mfaktc run, where both the exponent and the bitlevel got corrupted.

Or: was the very last dataset from the builtin selftest (the short one running during each startup) written into the results file? Seems the results array on GPU or CPU wasn't cleared (correctly) somehow. I will check this but will be hard with no steps to reproduce.

Oliver