mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Information & Answers (https://www.mersenneforum.org/forumdisplay.php?f=38)
-   -   Trial Factoring for Dummies (https://www.mersenneforum.org/showthread.php?t=25493)

LOBES 2020-04-27 16:08

Trial Factoring for Dummies
 
I've recently got back into things, and really enjoy using mfaktc-win-64.exe to do TF'ing. I've got an nVidia 1080 Ti so it can burn through them at a fairly good pace. But I do have a couple of comments/questions about TF'ing and Manual Testing I would love to get more info on:

1. So lets look at exponent 203437321. I recently used mfaktc to TF from 71 to 74, and no factors were found. So the status (of this writing anyway) of this exponent is: [B]No factors below 2^74[/B] Did my TF work actually save any time for when this exponent is actually tested for being prime, say using LL? Will LL run any faster for whomever tests it because it knows there are no factors below that level? Or did I simply not eliminate the exponent from testing because it was not factored? I'm not entirely clear on how I contributed in this instance.

2. As I said, I enjoy doing the TF work, and like getting manual assignments (both directly from ([url]https://www.mersenne.org/manual_assignment/[/url]) and also from GPU72 ([url]https://www.gpu72.com/account/getassignments/[/url]). However, it seems to me that the submission process is wide open to fraudulent results? I would never do so, but from looking at the results.txt that gets generated, it would be easy to fudge that to claim work that wasn't actually done.

3. On a slightly different topic, is work that is done on Primenet duplicated on Primegrid? If I'm going to be away from my PC for a while, I sometimes fire up Generalized Fermat Prime Search using BOINC. Is there any "stepping on toes" so to speak between these two projects?

Uncwilly 2020-04-27 16:28

[QUOTE=LOBES;543960]1. So lets look at exponent 203437321. I recently used mfaktc to TF from 71 to 74, and no factors were found. So the status (of this writing anyway) of this exponent is: [B]No factors below 2^74[/B] Did my TF work actually save any time for when this exponent is actually tested for being prime, say using LL? Will LL run any faster for whomever tests it because it knows there are no factors below that level? Or did I simply not eliminate the exponent from testing because it was not factored? I'm not entirely clear on how I contributed in this instance.[/quote]
If you didn't find a factor, we still have to do a primality test. (Currently because of lower error rates we are favoring PRP tests. If an exponent passes that then we will do an LL to nail it down for sure.) On a good GPU we should take that exponent to 79 bits. TF is being used to eliminate the need for primality tests. It does not speed them up individually, but the project overall.
[quote]2. As I said, I enjoy doing the TF work, and like getting manual assignments (both directly from ([url]https://www.mersenne.org/manual_assignment/[/url]) and also from GPU72 ([url]https://www.gpu72.com/account/getassignments/[/url]). However, it seems to me that the submission process is wide open to fraudulent results? I would never do so, but from looking at the results.txt that gets generated, it would be easy to fudge that to claim work that wasn't actually done.[/quote]This is a known issue. If someone reports a false factor, that is easy to detect. If they report a single false "No Factor" that is only possible to detect by repeating the TF. If someone reports 500 results with "No Factor", now we can use stats to look at how many they 'should' have found. So big fraud is easy to detect. The overhead in producing some checksum during TF has been discussed. Some ideas of how to do it have been mentioned. But no action taken.

I will let someone else answer #3

LaurV 2020-04-27 16:29

[QUOTE=LOBES;543960]
1.Did my TF work actually save any time for when this exponent is actually tested for being prime, say using LL?
[/QUOTE]

No.

[QUOTE]
Will LL run any faster for whomever tests it because it knows there are no factors below that level?

[/QUOTE]
No.
[QUOTE]
Or did I simply not eliminate the exponent from testing because it was not factored?

[/QUOTE]
Yes.
[QUOTE]
I'm not entirely clear on how I contributed in this instance.
[/QUOTE]
No contribution for this particular exponent. But if you factor to x bits, your chance is to find (about) one factor in x trials. In that case, you will eliminate an exponent, and we will only need to make x-1 LL/PRP tests and x-1 DC tests, instead of x and x. If the time to TF x exponents to x bits is faster than making 2 LL/PRP tests (which usually IS), then it is a gain for the project, and THAT is your contribution.
[QUOTE]
2.However, it seems to me that the submission process is wide open to fraudulent results?
[/QUOTE]
Yes. It appears so. You can cheat few times, and never got caught. But doing so repeatedly, you will be caught with your paw in the cookie jar, because there is an expected rate of factors, which you will not be able to reach (see above) if you cheat. Sooner than you expect, some guys here have nothing better to do than watching their neighbors... :razz:
[QUOTE]
3. On a slightly different topic, is work that is done on Primenet duplicated on Primegrid? If I'm going to be away from my PC for a while, I sometimes fire up Generalized Fermat Prime Search using BOINC. Is there any "stepping on toes" so to speak between these two projects?
[/QUOTE]

Not really. Those guys know what they are doing.

chalsall 2020-04-27 16:33

[QUOTE=LOBES;543960]Did my TF work actually save any time for when this exponent is actually tested for being prime, say using LL?[/QUOTE]

Strictly speaking, no. Only when a factor is found is an FC (LL or PRP) test saved.

BUT, the P-1 run /will/ be slightly faster, because Prime95/mprime spends slightly less time (with a slightly less chance of finding a factor) the deeper a candidate has been TF'ed.

[QUOTE=LOBES;543960]However, it seems to me that the submission process is wide open to fraudulent results?[/QUOTE]

You are correct. There is no way to prove that a TF run was actually done, except for where a factor is found.

However, GPU72 (and I believe Primenet) both keep track of what number of factors /should/ have been found as a heuristical function of the number of runs done.

When GPU72 was first started, I would often waste days of GPU time double-checking runs of participants who's stats were "outliners". Not once did I ever find anyone cheating (and/or, had bad kit).

kriesel 2020-04-27 17:12

[QUOTE=chalsall;543964]There is no way to prove that a TF run was actually done, except for where a factor is found.[/QUOTE]Not currently implemented on client software and server, but R. Gerbicz came up with a method for providing a proof of work in the TF no-factor case. See the many links to its discussion at [URL]https://www.mersenneforum.org/showpost.php?p=509936&postcount=2[/URL]
I think a variation could be applied to P-1. See [url]https://www.mersenneforum.org/showpost.php?p=510079&postcount=127[/url]

chalsall 2020-04-27 17:50

[QUOTE=kriesel;543967]See the many links to its discussion at [URL]https://www.mersenneforum.org/showpost.php?p=509936&postcount=2[/URL][/QUOTE]

Again, I must thank you for your thorough curation of this very technical and rarified space! Very valuable. :tu:

I don't have the time to drill down on all the prior discussion. I will say, however, that Oliver asked (many years ago) if anyone had ideas on how to produce a "checksum" or some other "proof of work" mechanism. Several ideas were proposed, but they all failed to be viable because of the unpredictable (and massive) concurrency of the CUDA TF runs.

If Gerbicz has proposed something which /is/ viable, it would be cool to see it codified and beta-tested.

Not that I think there's much, if any, cheating going on. But there /could/ be more "bad kit" out there than we realize. Having mfakt[c|o] be able to provide a long-term sanity data stream would be very useful to many people.

kriesel 2020-04-27 19:09

[QUOTE=chalsall;543971]Again, I must thank you for your thorough curation of this very technical and rarified space! Very valuable.[/QUOTE]You're welcome. It's my hope that when I become unwilling or unable (hopefully many years later) to continue it, someone else will step forward to continue it somehow. No I don't have anyone in mind.

LOBES 2020-04-27 19:54

Is there perhaps a better use of my 1080 Ti than doing TF'ing? From what I understand, mfaktc-win-64.exe is only used for Trial Factoring.

What is (if there is) the recommended program for doing actual prime testing using GPU (Windows based only at this time)? That is why I also use PrimeGrid, since BOINC makes it so easy.

chalsall 2020-04-27 20:05

[QUOTE=kriesel;543984]No I don't have anyone in mind.[/QUOTE]

It's a somewhat rare skill-set -- not everyone can do it. But ask a librarian *anything*, and they'll know (or know where to read). :smile:

You're probably best equipped to answer LOBES questions. I'd be interested in the answer(s) myself.

Dylan14 2020-04-27 20:06

@lobes: For GPU primality testing on Nvidia cards you can either use CUDAlucas, or you can use gpuowl. gpuowl has the advantage that it has Gerbicz error detection (at the slight cost of the test being a probable prime test).
Builds and source code links for gpuowl can be found [URL="https://www.mersenneforum.org/showpost.php?p=488539&postcount=4"]here[/URL] and that for CUDAlucas [URL="https://download.mersenne.ca/CUDALucas"]here.[/URL]

kriesel 2020-04-27 20:06

[QUOTE=LOBES;543990]Is there perhaps a better use of my 1080 Ti than doing TF'ing? From what I understand, mfaktc-win-64.exe is only used for Trial Factoring.

What is (if there is) the recommended program for doing actual prime testing using GPU (Windows based only at this time)? That is why I also use PrimeGrid, since BOINC makes it so easy.[/QUOTE]TF will provide the most computing credit from such a gpu, and the most benefit to the GIMPS project per hour of running. P-1 factoring is another possibility, either CUDAPm1 or gpuowl. If setting out to use a gpu for primality testing or P-1, first run at least one or two doublechecks of the work of others that did first-tests, to test the reliability of your setup. (Get assignments for whatever you run.) Verifying P-1 known factors is another reliability test.
For primality testing, gpuOwl to run PRP with Gerbicz error checking. PRP indicating composite with the GEC is almost conclusive proof of not prime. If it returns P indicating probably prime, it is either a software bug, a false positive, or time to test it with multiple LL tests to confirm or disprove the discovery of a new prime. To doublecheck an LL test, either CUDALucas or a very recent version of gpuowl. [URL]http://www.mersenneforum.org/showpost.php?p=488291&postcount=2[/URL]


All times are UTC. The time now is 14:53.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.