fond of a factor? Urn yourself to become remains

[LaurV]

Good points axn and Dubslow.
It may be a hardware error, or some guys who love the credit more than the truth.

FWIW, mfaktc v0.18 finds both factors in a blink of an eye, with three different settings: 0 to 70, 65 to 70 and 65 to 66 bits (the difference is important, as for example in the first case he is sieving all 0-69 range in a single step).

[PageFault]

Found another one ... M70002461

P-1 found a factor in stage #2, B1=810000, B2=21060000.
UID: PageFault/boxen_01, M70002461 has a factor: 10006641404605893135455599

k = 3 * 7 * 11 *17 * 1063 * 4931 * 3472289

[Bdot]

Originally Posted by dabaichi

M601983997 has a factor: 60136908979114760311 (65.705 bits)
M601986001 has a factor: 41955526838838866881 (65.185 bits)

Both were found by trial factoring using Prime 95. However, the interesting part is that both had been TFed using mfakto up to 67 bits, but reported no factors. It leads me to think is it necessary to double check trial factoring results?

Good catch. I had already asked James to go over his factor DB to see if there are P-1 results that fall into a range that mfakto cleared as NF. I did not think of someone rechecking using prime95 ...

Originally Posted by axn

It depends. If it is a reproducible error (i.e. bug) in mfakto, then maybe. If it is a hardware issue, then no. AFAICT, "gpu 2 72" has been finding the expected number of factors.

In GPU272 I'm even 5% ahead of the expected (I know, law of small numbers).

Originally Posted by Dubslow

So someone should rerun those with mfakto, but I'd only be worried if they were different users.

I'll definitely check different settings for that tomorrow.

Would it be useful to add a checksum in the result lines, just to make sure it's not modified before submittal but we (I) really have to deal with a bug? At first, that checksum would only be recorded, but later the server could also verify it ...

[TheJudger]

Originally Posted by Bdot

Would it be useful to add a checksum in the result lines, just to make sure it's not modified before submittal but we (I) really have to deal with a bug? At first, that checksum would only be recorded, but later the server could also verify it ...

Yepp, would be useful! It would be easy to spot transmission errors and spot "stupid" people cheating. Because the code is GPL we must put the key (or whatever generates the checksum) into to code, too. So a "smart" cheater can create correct checksums for fake results. So a simple CRC32 is a good idea.

Oliver

[Bdot]

Axelsson posted on the GPU272 thread. I've sent him a PM asking for more details and help to spot the error/bug.

[Axelsson]

I've been suspicious of the code, as I didn't find any factors after a couple of hundred candidates tested. When another guy found factors at the same bit level I finally got something to test against and when running mfakto I didn't find anything. I've been hunting for the bug a couple of days now but I wanted to be sure it was a bug in the code and not something I did....
... I've made a fool out of myself more than one time when I start posting on a new forum.



I almost understand the code now so I had started writing on an error report this afternoon, but Bdot beat me to it.

You don't need to worry about my exponents, when the bug is squashed I'll rerun any suspected exponents that I've reported.

/Göran

[Bdot]

Short update: I can reproduce the bug and am debugging it right now. At first it seemed like it happens only when multiple bitlevels are done at once. But I've also seen the failure once with just 2^65 to 2^66.

[TheJudger]

Hi,

please sent me a list of the test cases which fail with mfakto. I want to test them with mfaktc (because mfakto is based on mfaktc).
Bdot: if you have some details what/why it fails I would be happy if you tell me the details.

Oliver

[Bdot]

Originally Posted by TheJudger

Hi,

please sent me a list of the test cases which fail with mfakto. I want to test them with mfaktc (because mfakto is based on mfaktc).
Bdot: if you have some details what/why it fails I would be happy if you tell me the details.

Oliver

The testcase boils down to
Factor=N/A,601983997,65,66
Factor=N/A,601986001,65,66
which fails for two kernels with mfakto (barrett15_75 and mfakto_cl_71).

I've added them to the selftest where they fail as well. The other kernels find the factor, so it must be something in these two kernels. LaurV has done the tests for mfaktc already, and did not find a problem. I plan to not go to bed today before I killed that bug. By then I hopefully can tell you all what is affected and what not.

[Bdot]

Originally Posted by Bdot

The testcase boils down to
Factor=N/A,601983997,65,66
Factor=N/A,601986001,65,66
which fails for two kernels with mfakto (barrett15_75 and mfakto_cl_71).

The kernels are all OK, it's the precomputing step (doing the exponentiation without modular reduction on the CPU). One step too much for these two kernels led to an overflow in the first modulus in the kernel.

What are the conditions for the bug to happen?

1. the exponent in binary must start with 1000111 (which means 71*2ⁿ < exp < 71*2ⁿ+2ⁿ). Interesting ranges include, for example, 37.224.449 .. 37.748.735, 74.448.897 .. 75.497.471, 595.591.169 .. 603.979.775 (the range where the two testcases came from).
2. mfakto must have chosen either barrett15_75 or mfakto_cl_71 for the test
3. the bitlevel(s) to be tested must be up to 2⁷¹ or lesser (tests for 2⁷¹..2⁷² and 2⁷²..2⁷³ are not affected).
4. barrett15_75 only: The lower the bitlevel, the higher the chance for the bug to occur. This kernel will likely not find any factors below 2⁶⁸ in the ranges mentioned in (1).
5. mfakto_cl_71 only: the "miss" chance depends only on the bit-pattern of the factor - I did not evaluate them exactly as it would not add any value - the above ranges that were tested with this kernel should be rechecked.

Tests with (1) AND (2) AND (3) should be redone. Question is, how can we find them?

Tomorrow I will verify the above information - right now I'm quite tired ... I will provide a patch for mfakto within the next days - until then: keep away from the above ranges.

I'm really sorry for this trouble ...

[chalsall]

Originally Posted by Bdot

Tests with (1) AND (2) AND (3) should be redone. Question is, how can we find them?

If you give me the all of the ranges in question, I could quite easily spider them to find which candidates were TFed at the depths you've specified with mfakto using the two kernels in question.