mfaktc: a CUDA program for Mersenne prefactoring

[Neutron3529]

Originally Posted by kriesel

prime95 by design runs at a quite low priority, to use otherwise-idle cpu cycles, without slowing user applications and console interactive response speed. (See the end of undoc.txt)

Maybe It is the memory bandwith that make the rewrite slower.
I will check it later since I am running an R script now.

Originally Posted by kriesel

Hmm, unless I'm mistaken, that's not for assignments, that's a report generator page.
It's my understanding that assignments are issued through Primenet automatic connections in prime95 or mprime, or manually through
https://www.mersenne.org/manual_assignment/ or https://www.mersenne.org/manual_gpu_assignment/ and include unique assignment IDs in the worktodo records.

Output of https://www.mersenne.org/report_factoring_effort/ for 92M to 93M just now includes exponents I have assigned TF work for.
Exponents in such a report listing, even if current assignments are excluded, won't exclude assignments made in the near future either through automatic primenet connections or through the manual assignment pages. It seems likely to me, that the assignee and you will be duplicating work.

I did a quick test on https://www.mersenne.org/report_factoring_effort/ for 92000000 to 92002000. If I check exclude currently assigned exponents, and check worktodo format, and specify 76 bits, it does not include an assignment ID in its output, it provides a prime95 style manual assignment format record, and the resulting assignment if any does not show up in my current assignments retrieved afterward. Its output was:

Factor=N/A,92000429,75,76

Checking the status of https://www.mersenne.org/report_expo...000429&exp_hi= afterward indicates no active TF assignment. Therefore, I conclude, that if I were to use this method to obtain a large list of exponents needing more factoring, and factored them over time, without taking other actions promptly to reserve them, meanwhile they very likely are being assigned to other people, by the usual mechanisms listed above, and for many if not most of the exponents so obtained, wasteful duplication of TF effort on the same exponent and bit level would occur as a result.
N/A is the dead giveaway in the record produced, that an assignment was not issued. That's where the lengthy AID would normally appear (32 upper case hexadecimal characters).

I tried report page to generate worktodo file is that, I want to test some relative low exponent, but manual_gpu_assignment/ may return an error, while manual_assignment/ may assign a really large exponent to me.

[James Heinrich]

Originally Posted by Neutron3529

I want to test some relative low exponent

What kind of exponent range are you testing, and to what bitdepth? How long does each "assignment" (I say in quotes because they're not actually assigned to you) take to run on your GPU?

[Neutron3529]

I'm factoring exponent above 900000000, to 71 bitdepth.
as @kriesel suggests, I tried https://www.mersenne.org/manual_gpu_assignment/ and get some results.
And unfortunately some collision occur:
https://www.mersenne.org/M903462383
I find it might be a collision due to the latter submit:

processing: TF no-factor for M903482861 (270-271)
Result was not needed. TF on M903482861, sf: 70, ef: 71 CPU credit is 0.2647 GHz-days.

[kriesel]

Originally Posted by Neutron3529

I'm factoring exponent above 900000000, to 71 bitdepth.
as @kriesel suggests, I tried https://www.mersenne.org/manual_gpu_assignment/ and get some results.
And unfortunately some collision occur:
https://www.mersenne.org/M903462383
I find it might be a collision due to the latter submit:

processing: TF no-factor for M903482861 (2⁷⁰-2⁷¹)
Result was not needed. TF on M903482861, sf: 70, ef: 71 CPU credit is 0.2647 GHz-days.

Not certain if you actually meant results, assignments, or factors, there.
Collisions, waste, or poaching can be frustrating.

That's a low bit level, but above 900M is a very high exponent, in the upper range of what mersenne.org supports. (Not low exponent as earlier stated) The GIMPS primality testing wavefront won't get there for decades if not lifetimes.
See https://www.mersenneforum.org/showthread.php?t=23845, particularly post 11.
At 0.265 GhzD/day, any reasonable speed gpu will do hundreds or thousands of such exponents from 2⁷⁰ to 2⁷¹ per day.

It may be easier to avoid collision by working longer on fewer exponents, closer to the wavefront, where the investment in computing time will also pay off sooner for the project, perhaps in the next decade or less.
Or get actual TF assignments on scattered exponents, such as in the first thousand range of some million exponent range bins, and take them to full gputo72 recommended TF bit level. Those are very helpful and useful to have partly or fully done for exponent qualification for software testers of P-1 and primality test code, testing well ahead of the wavefront.
Some portions of the exponent range do not yield assignments from the mersenne.org assignment page for TF or P-1. That may be because it is (not so visibly) reserved to gputo72, or is simply not being issued at the time, or someone has grabbed a huge span for single-bit-level trial factoring.
In my experience, once runs break through and establish "islands" above the bit level "sea", collisions with other users reporting results are very rare.

[James Heinrich]

Originally Posted by Neutron3529

And unfortunately some collision occur

Collisions will occur if you don't get assignments and just work on random exponents. Many more collisions will occur than you know about, when you do work that's already assigned to other people, when they submit their results their efforts will be wasted.

If you want to work on really big exponents you can try TF above 1000M, but please use the provided scripts to automate fetching/submitting work and avoid getting more work than you can complete in one day.

[kriesel]

Originally Posted by James Heinrich

Collisions will occur if you don't get assignments and just work on random exponents. Many more collisions will occur than you know about, when you do work that's already assigned to other people, when they submit their results their efforts will be wasted.

That's one way to look at it. Another is to consider that your own efforts are less likely to be wasted and not credited if diligently using the assignment methods. And others have less reason to be annoyed with you then.
Good point though about the probable magnitude of the entire waste of working without assignments being much larger than may be apparent to one user though.

[storm5510]

Originally Posted by James Heinrich

If you want to work on really big exponents you can try TF above 1000M, but please use the provided scripts to automate fetching/submitting work and avoid getting more work than you can complete in one day.

Congrats! All the 65's and 66's are done.

On another note: I am now using a separate PSU to power my GTX 1080 in the HP. I am getting a lot of, what I would call, screen noise. Is this harmful in any way? That PSU is 550W and nine years old.

[James Heinrich]

Originally Posted by storm5510

Congrats! All the 65's and 66's are done.

Slightly premature congratulations, there's still 2,562,566 exponents below 2⁶⁷, but they're already assigned. Everything should be complete within a week or two though.

[LaurV]

Originally Posted by storm5510

On another note: I am now using a separate PSU to power my GTX 1080 in the HP. I am getting a lot of, what I would call, screen noise. Is this harmful in any way?

Yes. You should use a firm ground between the two PS, and DO NOT rely on the ground connection that goes through the card! You most probably have different ground potential between the two PS grounds (as they are insulated outputs each) and have a lot of EMI in that card (which causes the screen flickering**). You can have EMI sparks of over 500V there. This will shorten the life time of your card, and also can give calculus errors. You must connect a thick and short wire between the grounds of the two PS, using one of the unused outputs of each).

-------
** related to screen flickering, it can also be due to mechanical vibrations (from the fans, etc), so first check if the card is well stuck in the socket, and if the monitor cables are firm stuck in the connectors, etc., otherwise the plugs vibrate causing intermittent losing of contacts which may cause flickering.

[storm5510]

Originally Posted by LaurV

Yes. You should use a firm ground between the two PS, and DO NOT rely on the ground connection that goes through the card! You most probably have different ground potential between the two PS grounds (as they are insulated outputs each) and have a lot of EMI in that card (which causes the screen flickering**). You can have EMI sparks of over 500V there. This will shorten the life time of your card, and also can give calculus errors. You must connect a thick and short wire between the grounds of the two PS, using one of the unused outputs of each).

-------
** related to screen flickering, it can also be due to mechanical vibrations (from the fans, etc), so first check if the card is well stuck in the socket, and if the monitor cables are firm stuck in the connectors, etc., otherwise the plugs vibrate causing intermittent losing of contacts which may cause flickering.

Thank you for the reply! I disconnected the extra PSU after I posted the above. I was not comfortable with running it that way. I got this card just before crypto began to tank, so it was a large investment, for me.

To run mfaktc, I use MSI Afterburner to throttle it back to 80%. There is a little performance drop, but everything runs much cooler. CUDALucas and CUDAPm1 are not nearly as demanding so I let the card run at its factory defaults. The PSU in the HP is 400W, and proprietary. I do not tax it hard. Replacements are scarce and expensive!

The reason I moved the card to the HP was because it became like the watched pot that never boiled in my i7. I was always stopping the process to do something else. I never seemed to get anywhere. In the HP, it can simply run unattended, monitor off, until I have to give it more work. With DC's, it's like a once-a-day peek to see if it needs anything.

[kriesel]

After seeing mfaktc not produce the expected GhzD/day numbers on my runs, and looking through the thread here for guidance, here's what I found, on my Windows 7 installation.
Following Mark Rose's advice on tuning parameters and sequence,

https://www.mersenneforum.org/showpo...postcount=2505
I iterated to individually tune, in order,
GPUSieveProcessSize
GPUSieveSize
GPUSievePrimes
and then went back, and varied each separately, recording and plotting the results. There was still some performance left on the table; running a second instance gained about 2%. That reached 1285 GhzD/day, not quite the 1300 GhzD/day benchmark rating, on current assignments (92M, 75-76 bits) All the preceding was with Numstreams=3, not sure that matters. (Varying Numstreams the results look like measurement noise.) See the attachment. Note that this gpu was thermally throttling at 83C and 175-200 Watts, gpu core clock around 1570Mhz at the time.

The plots look consistent with some further gains being possible, particularly if the maximum for gpusievesize was larger.