P-1 vs. TF

[kriesel]

Originally Posted by GP2

If I do this and run mprime -d for my current assignment M87776147 (which has been TF'd to 76 bits, with 2 LL tests to be saved), it chooses the bounds B1=710000, B2=13490000 and tells me that the chance of finding a factor is an estimated 3.08%.

These B1 and B2 are very typical for the P−1 exponents I've been doing lately. However, as mentioned earlier, over the last 438 such tests in the 80M+ range, I've been finding factors at a rate of about 1.1%, not 3.1%. Presumably I should have found 13 factors, not 5.
...(clip)...

What is the global discovery rate for all users at the 87M wavefront for P−1 testing? Is it similar to mine, or does it match the estimated rate? I could dig into XML files for the answer, but I suspect someone out there might be able to come up with it faster.

I made a similar comment back in August, about my attempts and fewer than expected factors, and got schooled about statistics a bit.

Then I applied some analysis using the binomial distribution, useful for estimating probabilities of factors in various size samples of runs https://www.easycalculation.com/stat...stribution.php to my own results and saw the probability function in samples of such size is quite broad. Also analyzed some gputo72.com data in bins containing hundreds to thousands of attempts each and saw considerable variations in both directions from the "expected" probability.

[GP2]

Originally Posted by kriesel

I made a similar comment back in August, about my attempts and fewer than expected factors, and got schooled about statistics a bit.

Unless I'm doing the math wrong, with a probability of 0.0308 of success, the probability of 5 successes or fewer out of 438 is 0.0071 (0.71%).

Of course maybe not all of those exponents had an identical fixed 0.0308 probability of finding a P−1 factor, but still, this is really low.


I am using the latest version 29.4 of mprime. The release notes for 29.3 indicate that there was a change to the code: "The GCD step in P-1 and ECM factoring is faster."

Version 29.3 build 1 was released on 2017-09-08. Three of my five factors were found before this date, so if I include only the tests done after this date, I found only 2 factors out of 311 tests. The odds of 2 or fewer successes out of 311 trials @ 0.0308 probability per trial are... 0.00065 (0.065%) 0.0035 (0.35%)

At this point I might install version 29.2 and retest some of these same exponents, or run 29.4 on exponents with known factors of length 24 or higher to see if it rediscovers them.

But clearly it seems something is wrong.

Is it possible to look in the Primenet log files to see if versions 29.3 and 29.4 are finding P−1 factors at the expected rate, compared to 29.2 and earlier?

[S485122]

Originally Posted by GP2

...
What is the global discovery rate for all users at the 87M wavefront for P−1 testing? Is it similar to mine, or does it match the estimated rate? I could dig into XML files for the answer, but I suspect someone out there might be able to come up with it faster.

I will give you statistics for 3 computers : about 3000 P-1 factoring attempts in the 80M to 88M range in the last two years and a success rate of about 4 %. The computer with 30GB of memory allocated to P-1 has a success rate of almost 5%, the other 2 with 15 GB of memory have 4% and 3 %. The differences in success rate are not really explained by the memory allocated : the B1 and B2 bounds do not differ much between 30GB and 15 GB allocated. I attribute the differences to randomness. For the 87M range 13 successes out of 318 attempts is a 4% success rate.
As expected successes come in clumps, dry spells do occur.
As an example of what randomness can do, in my 12 years GIMPS "career", computers I manage(d) found 248 factors at the end of stage 2 of P-1 factoring. Of those 15 were found thanks to the Brent-Sumaya extension. In the last month amongst the 8 factors found at the end of stage 2 P-1 factoring, 5 where found thanks to the Brent-Sumaya extension.

Jacob

[chalsall]

Originally Posted by GP2

At this point I might install version 29.2 and retest some of these same exponents, or run 29.4 on exponents with known factors of length 24 or higher to see if it rediscovers them.

The latter scenario would make more sense. A bit like a Double Check for P-1. You could also go a step further, and run a few LLDCs on the machines in question, just to ensure their sanity.

FWIW, I've been running 29.4 on all of my P-1'ing machines since it was released, and they've been finding factors at the expected ratio (give or take).

Originally Posted by GP2

But clearly it seems something is wrong.

Possibly....

[kriesel]

Originally Posted by GP2

At this point I might ... run 29.4 on exponents with known factors of length 24 or higher to see if it rediscovers them.

Run several knowns. Requiring differing fft lengths. Run the self-test. Run a memory tester. Run some LL DC.

Some exponents with known factors, with min b1 and b2 necessary to find them with P-1, and a reasonable fft length to use (from a draft revision of the CUDAPm1 readme):
exponent min b1 min b2 fft length factor(s)
50001781 94,709 4,067,587 2688k 4392938042637898431087689
51558151 5,953 2,034,041 2880k 755277543419074012358186647
54447193 1,181 682,009 3072k 17261184235049628259201
58610467 70,843 694,201 3200k 69057033982979789260999
61012769 10,273 1,572,097 3360k 2018028590362685212673
81229789 6,709 11,282,221 4704K 355078783674010195200030259699844128700274440385857 =488121804389130135740149369 x 727438890213848757119753
100000081 1,289 7,554,653 5600K 3441393510714285782119
120002191 1563 3,109,391 7168K 100835659918276033441
150000713 15,131 2,294,519 8640K 1447762785107694357647
200000183 953 1,138,061 11200K 849003842550205126847
200001187 204,983 207,821 11200K 3050161780881530584679
200003173 4,651 229,813 11200K 14652109287435525414352647642348599 = 4320552944485007 x 3391257895852957657
249500221 4 2.58951e+9 14336K 5168661482381201657 62.16 bits
249500501 307 167,381 14336K 3571511465549660434777661921959439 = 11607130072256471 x 307699788260867209
290001377 2,551 34,354,769 16384K 10645243382592701071676802590718709559 = 1436135993277492383 x 7412420155488583273

Feel free to pick your own.
Evaluate them at equivalent of http://www.mersenne.ca/exponent/249500501

[GP2]

Originally Posted by chalsall

You could also go a step further, and run a few LLDCs on the machines in question, just to ensure their sanity.

Hah. They're virtual machines on the AWS cloud, where the underlying hardware has ECC memory. There is no way of knowing which physical machine, out of millions, is in use at any given time.

Indeed, because spot instances can terminate at any time and relaunch later, a single exponent may have been worked on at different stages by a number of different physical machines.

I do almost exclusively double checks, so all the LL results get verified. I've never had a single bad LL result for mprime in the AWS cloud, out of a few thousand. Even in extreme cases where a single LL test was done by dozens of different spot instances in succession.

(My only bad LL result was from running Mlucas on Google cloud, due to an issue with the program reverting back to a smaller FFT size, which will be fixed in the next Mlucas release.)

So it's unlikely to be a hardware issue.

[GP2]

Originally Posted by kriesel

Run several knowns. Requiring differing fft lengths. Run the self-test. Run a memory tester. Run some LL DC.

As I replied to chalsall, there is no single machine to run these tests on. Just a cloud of millions of virtual-machine clones, which wink in and out of existence, and collectively have a 100% successful track record for LL tests so far.

[kriesel]

Originally Posted by GP2

As I replied to chalsall, there is no single machine to run these tests on. Just a cloud of millions of virtual-machine clones, which wink in and out of existence, and collectively have a 100% successful track record for LL tests so far.

Then perhaps it reduces to

Run several knowns. Requiring differing fft lengths. Until you're satisfied V29.4 is reliable on whatever size sample of knowns you choose to run, or you have something interesting to bring to Prime95's attention.

[kriesel]

Originally Posted by GP2

Unless I'm doing the math wrong, with a probability of 0.0308 of success, the probability of 5 successes or fewer out of 438 is 0.0071 (0.71%).
...

I am using the latest version 29.4 of mprime. The release notes for 29.3 indicate that there was a change to the code: "The GCD step in P-1 and ECM factoring is faster."

Version 29.3 build 1 was released on 2017-09-08. Three of my five factors were found before this date, so if I include only the tests done after this date, I found only 2 factors out of 311 tests. The odds of 2 or fewer successes out of 311 trials @ 0.0308 probability per trial are... 0.00065 (0.065%) 0.0035 (0.35%)

I tried the stats calcs and got probabilities even lower, 0.46% and 0.28%. Either your stats math is wrong, or mine is, or the probabilities per candidate are, or combinations.

Maybe you'll be "the lucky winner" that discovers evidence of an obscure bug in the AWS virtualization. (Recall Dr. Nicely, independently discovering in his number theory computation the FDIV bug, the $500 million recall /replace of early Pentiums, and the eventual admission that Intel had already known about it before him but kept it quiet, presumably for business reasons.) Is there some acid test of virtualization reliability you could run on AWS that's independent of mprime/Prime95?

Or, as you speculated, a bug in mprime/Prime95's P-1 code. Running a sufficient number of P-1 computations with expected factors within given bounds could address that. It wouldn't take much to cause some missed factors. Falling short on memory available could do it, but I think you're avoiding that.

[petrw1]

I had a similar dry spell on one of my computers.

P1 work with an expected success rate of 3% was under 1.5% over 900 attempts.

I took this advice and ran 16 that had known factors and found all 16.

Then as luck would have it over the next 100 or so I had triple the expected success rate and now this PC is close to the expected average.

[GP2]

Originally Posted by GP2

If I do this and run mprime -d for my current assignment M87776147 (which has been TF'd to 76 bits, with 2 LL tests to be saved), it chooses the bounds B1=710000, B2=13490000 and tells me that the chance of finding a factor is an estimated 3.08%.

The universe is obviously mocking me. This very exponent had a factor found, a couple of hours ago.

Anyways, I'm going to do a bunch of exponents in the 86M and 87M ranges where other people found factors with P−1 and try to rediscover all of them. We'll see.

If there was a bug in mprime, perhaps it might be in the code that writes savefiles and later restores memory structures from those savefiles. The one significant difference between spot instances and physical machines is that the former may get interrupted and resumed a lot, so any rare bug in the savefile code would get triggered more often.