I have more RAM than I thought :grin:

Edge case
 

Had been working on a motherboard with 32GB ram, prime95 allowed to use 12GB in P-1.
Switched the hard drive with Windows 10 installed to a different motherboard with only 6GB installed, and launched prime95 without thinking about the memory limit. That's a very quickly pretty hung system, after launching prime95 that goes straight into a P-1 in progress; responds to ping, but that's about it. And the reset button.

The following local.txt line does not work so well when there's only 6144MB physical ram installed:
Memory=12288 during 7:30-23:30 else 12288
s/12288/4096/g;
better.

I've had two instances of mprime 30.6 (on different computers) delete the AutoBench=0 setting without permission and run benchmarks in the past couple of days. One is not connected to PrimeNet. Not sure what's going on.

30.6b4:

Both mprime on an EC2 instance and Prime95 on my own computer did not generate and upload a proof for this PRP-CF test: [M]11109569[/M]

The PRP-CF just before that one on the same EC2 instance did generate proof: [M]11199701[/M]
and the last PRP-CF test I did on my own computer about 1 month ago also generated a proof: [M]11059453[/M]

[url]https://mersenneforum.org/showthread.php?t=26861[/url]

[QUOTE=ATH;580230]Both mprime on an EC2 instance and Prime95 on my own computer did not generate and upload a proof for this PRP-CF test: [M]11109569[/M]
[/QUOTE]
I just started it on v30.5b2

[QUOTE=Uncwilly;580236]I just started it on v30.5b2[/QUOTE]

Looks like your test did not generate a proof either. There might be a bug in the proof generation triggering on this exponent.

[QUOTE=ATH;580311]Looks like your test did not generate a proof either. There might be a bug in the proof generation triggering on this exponent.[/QUOTE]

I was experimenting with testing the exponent:
base 3, type 1 - no proof
base 5, type 1 - no proof
base 3, type 5 - proof!
Other exponents behaved the same.

Then it hit me. Shouldn't only the type 5 be proof-capable? All previous PRP tests on that exponent were type 1.

Also, checking ATH's mentioned exponents that generated proofs, they are all type 5.

It could be that my memory is incorrect and previous proof-capable versions of Prime95/mprime could do the proofs on type 1, but I doubt that.

[QUOTE=Viliam Furik;580322]Then it hit me. Shouldn't only the type 5 be proof-capable? All previous PRP tests on that exponent were type 1.[/QUOTE]
This is a type 1 base 3 with a proof: [M]108230981[/M]
Looking back at other PRP-CF's I've done before, they were 5, 3.

Aye, there's the rub. I was the blind following the blind in regard to our current expo.

[QUOTE=Uncwilly;580336]This is a type 1 base 3 with a proof: [M]108230981[/M]
Looking back at other PRP-CF's I've done before, they were 5, 3.

Aye, there's the rub. I was the blind following the blind in regard to our current expo.[/QUOTE]

Yes, of course, type 1 for normal PRP is proof-capable, but I think it is not the case for PRP-CF.

You seem to already understand the situation, so consider this as only an additional explanation.

[QUOTE=Viliam Furik;580373]Yes, of course, type 1 for normal PRP is proof-capable, but I think it is not the case for PRP-CF.[/QUOTE]Ken needs to update his page to explain that.

I noticed that factors found via P+1 currently do not appear on the "Recent Cleared" page. Here's an example: [url]http://mersenne.org/m1717043[/url]

Are they going to be included in the future?

[QUOTE=ixfd64;580495]I noticed that factors found via P+1 currently do not appear on the "Recent Cleared" page. Here's an example: [url]http://mersenne.org/m1717043[/url]

Are they going to be included in the future?[/QUOTE]

Fixed. Thanks.

[QUOTE=Uncwilly;580376]Ken needs to update his page to explain that.[/QUOTE]
This happened to me once. I ended up re-running it as a "FT" type-5, as IIRC there was no GEC being done either (since with type-1, it's actually doing a regular Fermat test on the actual cofactor, which has no special form).

[QUOTE=Happy5214;580733]... cofactor, which has no special form).[/QUOTE]

Except for the 2kp+1 form, which holds for any factor of Mp.

Just noticed I am working this unusual exponent at CoLab.
[CODE]Work thread Jun 12 06:09] Iteration: 7050000 / 11115952 [63.42%], ms/iter: 2.566, ETA: 02:53:54[/CODE]

My session time was reset so I was able to connect to CoLab. My worktodo entry was:
[CODE]PRPDC=194F96.......,1,2,11115983,-1,99,0,3,1,"1267222063"[/CODE]
So I let it run. It finally credited me with the exponent in the worktodo file even though every output line showed the rogue exponent!

You should edit your post and remove the assignment ID .
194F96ACE9...
Change it to AID, and everyone will know what you mean, without the security risks

Oops. Given you say it's completed, there's probably no harm in having the AID printed, as it would be expired now. At least I think that's the case - I would still not print it myself, just in case, but I think you are safe the fact it has completed.

[QUOTE=RichD;580865]My session time was reset so I was able to connect to CoLab. My worktodo entry was:
[CODE]PRPDC=194......D8F,1,2,11115983,-1,99,0,3,1,"1267222063"[/CODE]
So I let it run. It finally credited me with the exponent in the worktodo file even though every output line showed the rogue exponent![/QUOTE]

I have an unconfirmed feeling that it happens on all exponents, because it doesn't iterate the entire Mersenne number, but only the cofactor, which is smaller by the size of known factors.

The fact, that the factor has 31 bits (rounded up) suggests it's true because 11115983 - 31 = 11115952.

[QUOTE=Viliam Furik;580869]I have an unconfirmed feeling that it happens on all exponents, because it doesn't iterate the entire Mersenne number, but only the cofactor, which is smaller by the size of known factors.

The fact, that the factor has 31 bits (rounded up) suggests it's true because 11115983 - 31 = 11115952.[/QUOTE]

My next one, before the session expired, appears to be correct. The output line:
[CODE][Work thread Jun 13 03:17] Iteration: 5800000 / 6397693 [90.65%], ms/iter: 1.524, ETA: 00:15:10[/CODE]
And the worktodo entry:
[CODE]PRPDC=5F.....9D,1,2,6397693,-1,99,0,3,5,"1880921743,150224692370214966223"[/CODE]
This one is not completed so the AID is masked.

[QUOTE=Viliam Furik;580753]Except for the 2kp+1 form, which holds for any factor of Mp.[/QUOTE]

Well, of course there's that. I should have said there was no special [I]binary[/I] form, beyond a couple of bits (guaranteed by the 2[I]kp[/I]+1 form). Recall, a Mersenne number is all 1's in binary.

[QUOTE=Happy5214;581029]Well, of course there's that. I should have said there was no special [I]binary[/I] form, beyond a couple of bits (guaranteed by the 2[I]kp[/I]+1 form). Recall, a Mersenne number is all 1's in binary.[/QUOTE]

Yes, of course. I just wanted to point out the tiny error that made the statement false. Otherwise, I agree.

Weird single exponent FFT issue: I'm doing P+1 in the 4M range in mprime 30.6b4 and at the exponent M4037479 kept failing with the chosen AVX-512 FFT 200K.
Pplus1=N/A,1,2,4037479,-1,2500000,250000000,1,70

It did not work until I added ExtraSafetymargin=0.03 to prime.txt forcing it to use 240K FFT.

But subsequent exponents works fine at AVX-512 FFT 200K, and that exponent M4037479 also works fine with FMA3 FFT 200K (in Prime95 30.6b4).


[CODE][Work thread Jun 20 12:38:29] P+1 on M4037479, start=2/7, B1=2500000, B2=TBD
[Work thread Jun 20 12:38:29] Using AVX-512 FFT length 200K, Pass1=640, Pass2=320, clm=1
[Work thread Jun 20 12:42:20] Possible roundoff error (0.44758343), backtracking to last save file.
[Work thread Jun 20 12:42:20] Using AVX-512 FFT length 200K, Pass1=640, Pass2=320, clm=1
[Work thread Jun 20 12:46:12] Possible roundoff error (0.44758343), backtracking to last save file.
[Work thread Jun 20 12:46:12] Using AVX-512 FFT length 200K, Pass1=640, Pass2=320, clm=1
[Work thread Jun 20 12:50:12] Possible roundoff error (0.44758343), backtracking to last save file.[/CODE]

[QUOTE=ATH;581774]Weird single exponent FFT issue: I'm doing P+1 in the 4M range in mprime 30.6b4 and at the exponent M4037479 kept failing with the chosen AVX-512 FFT 200K.[/QUOTE]

That happened to me too a week ago. I changed the code (in 30.7) so that if an error occurs it retries with a maximum allowable error of 0.46. I suppose it could still infinite loop if an even worse roundoff error is encountered.

Happened again and only for 200K AVX-512, worked fine on 200K FMA3. I will leave ExtraSafetymargin=0.03 on for now and use 240K AVX-512.

[CODE][Work thread Jun 24 22:19:42] P+1 on M4040059, start=2/7, B1=2500000, B2=TBD

[Work thread Jun 24 23:52:22] Possible roundoff error (0.43976434), backtracking to last save file.
[Work thread Jun 24 23:52:22] Using AVX-512 FFT length 200K, Pass1=640, Pass2=320, clm=1
[Work thread Jun 24 23:52:22] M4040059 stage 1 is 70.105240% complete.
[Work thread Jun 24 23:59:19] Possible roundoff error (0.43976434), backtracking to last save file.
[Work thread Jun 24 23:59:19] Using AVX-512 FFT length 200K, Pass1=640, Pass2=320, clm=1
[Work thread Jun 24 23:59:19] M4040059 stage 1 is 70.105240% complete.
[Work thread Jun 25 00:06:16] Possible roundoff error (0.43976434), backtracking to last save file.
[/CODE]

[QUOTE=ATH;581911]Happened again and only for 200K AVX-512[/QUOTE]

I'll lower the maximum allowable exponent for AVX-512 200K FFT to 4037000. I'll start testing the maximums of other FFT lengths.

[QUOTE=Prime95;582043]I'll lower the maximum allowable exponent for AVX-512 200K FFT to 4037000. I'll start testing the maximums of other FFT lengths.[/QUOTE]

You need help testing AVX-512 or FMA3 candidates?

It could be hard to find though, since not all exponents above a certain threshold gives the error.
I turned back to AVX-512 200K FFT for a while before I got the 2nd error, and these 7 exponents worked fine at 200K:
M4039429,M4039447,M4039487,M4039537,M4039583,M4039733,M4039843


I guess this could not be an mprime issue? Just in case could someone with a Prime95 (Windows) AVX-512 computer test one of these? No need to finish it unless you want to, just run like 50% of stage1 to check if you get a roundoff error:
Pplus1=N/A,1,2,4037479,-1,2500000,250000000,2,70
Pplus1=N/A,1,2,4040059,-1,2500000,250000000,2,70

[QUOTE=ATH;582075]You need help testing AVX-512 or FMA3 candidates?

It could be hard to find though, since not all exponents above a certain threshold gives the error.
I turned back to AVX-512 200K FFT for a while before I got the 2nd error, and these 7 exponents worked fine at 200K:
M4039429,M4039447,M4039487,M4039537,M4039583,M4039733,M4039843

I guess this could not be an mprime issue? Just in case could someone with a Prime95 (Windows) AVX-512 computer test one of these? [/QUOTE]

Sure, help is welcome. A stray roundoff error of 0.43 or 0.44 is not too alarming. Yours was because you weren't that close to the FFT maximum of 4043000. I tested the 16K FFT maximum. I'll test the 12800 FFT maximum of 267,400 next. I'll do this by running P-1 and P+1 to largish bounds using the python worktodo generator (ECM would also be a good test) on 266,000 to 267,400. I'm using Windows and prime95. Linux and mprime would provide the same data.

Other AVX-512 FFT maximum exponents that remain to be tested (turn on roundoff checking):

[CODE]22469
33423
44307
98407
108700
130200
151300
162400
172600
194300
214800
225600
256500
267400
382900
424300
507400
527800
672200
835300
1001000
1161000
1244000
1324000
1490000
1649000
1730000
1976000
2457000
2616000
2941000
3893000
4843000
5623000
5798000
6022000
6408000
6730000
7219000
7682000
7815000
7985000
8384000
8640000
8907000
9547000
10020000
[/CODE]

[QUOTE=ATH;582075]
I guess this could not be an mprime issue? Just in case could someone with a Prime95 (Windows) AVX-512 computer test one of these? No need to finish it unless you want to, just run like 50% of stage1 to check if you get a roundoff error:
Pplus1=N/A,1,2,4037479,-1,2500000,250000000,2,70
Pplus1=N/A,1,2,4040059,-1,2500000,250000000,2,70[/QUOTE]

I'll try these two.

I didn't get any roundoff errors.

If doing P-1 work on (k^p-1)/(k-1) or (k^p+1)/(k+1) with p prime
Does Prime95 automatically includes p in the B1 stage?


Thanks

[QUOTE=Chuck;582110]I didn't get any roundoff errors.[/QUOTE]

@Prime95: Is this strange that there are no roundoff errors in Prime95 on AVX-512 200K on these 2 exponents that I got roundoff errors on in mprime? or is it very dependent on the specific processor?

[QUOTE=Citrix;582120]If doing P-1 work on (k^p-1)/(k-1) or (k^p+1)/(k+1) with p prime
Does Prime95 automatically includes p in the B1 stage?[/QUOTE]

I believe so. Can you run a small test case?

[QUOTE=ATH;582124]@Prime95: Is this strange that there are no roundoff errors in Prime95 on AVX-512 200K on these 2 exponents that I got roundoff errors on in mprime? or is it very dependent on the specific processor?[/QUOTE]

One started at 2/7, the other started at 6/5.

[QUOTE=Prime95;582128]One started at 2/7, the other started at 6/5.[/QUOTE]

Yeah I switched it :( In case whoever tested it wanted to finish it, then it would not be wasted effort.


[QUOTE=Prime95;582081]Other AVX-512 FFT maximum exponents that remain to be tested (turn on roundoff checking):

[CODE]22469
33423[/CODE][/QUOTE]

I'm working on these 2 and going upwards after them. I'm doing P+1, do I need to do P-1 as well on each exponent?
Should I continue above the maximum in case of no failures below?

Edit: I reached a failure in the 33423 case. I started at M32611 and reached a roundoff error at M33391, should I do more testing for this FFT?

[CODE][Work thread Jun 28 16:01:03] P+1 on M33391, start=2/7, B1=100000000, B2=10000000000
[Work thread Jun 28 16:01:03] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:09:30] Possible roundoff error (0.4520854), backtracking to last save file.
[Work thread Jun 28 16:09:30] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:17:55] Possible roundoff error (0.4520854), backtracking to last save file.
[Work thread Jun 28 16:17:55] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:26:17] Possible roundoff error (0.4520854), backtracking to last save file.[/CODE]

Max roundoff errors before the failure:
M33301 Round off: 0.4065263058
M33347 Round off: 0.4113334932
M33353 Round off: 0.4064540519
M33359 Round off: 0.401012083
M33377 Round off: 0.4146345477

[QUOTE=ATH;582158]Yeah I switched it :( In case whoever tested it wanted to finish it, then it would not be wasted effort.
...
I'm doing P+1, do I need to do P-1 as well on each exponent?
Should I continue above the maximum in case of no failures below?

Edit: I reached a failure in the 33423 case. I started at M32611 and reached a roundoff error at M33391, should I do more testing for this FFT?

[CODE][Work thread Jun 28 16:01:03] P+1 on M33391, start=2/7, B1=100000000, B2=10000000000
[Work thread Jun 28 16:01:03] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:09:30] Possible roundoff error (0.4520854), backtracking to last save file.
[Work thread Jun 28 16:09:30] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:17:55] Possible roundoff error (0.4520854), backtracking to last save file.
[Work thread Jun 28 16:17:55] Using AVX-512 FFT length 1536
[Work thread Jun 28 16:26:17] Possible roundoff error (0.4520854), backtracking to last save file.[/CODE]

Max roundoff errors before the failure:
M33301 Round off: 0.4065263058
M33347 Round off: 0.4113334932
M33353 Round off: 0.4064540519
M33359 Round off: 0.401012083
M33377 Round off: 0.4146345477[/QUOTE]

For example on M33391 we know a pretty large d (=p1*p2*p3*p4) divisor which enables a good error checking at least on the first stage of P+-1 : do the computation also in Z[d] and then regularly do the check for the intermediate number(s) that r(i) mod d is still good. What could give you a greedy FFT size.

Or for example at P-1 test the check is only: we computed that b^e==res mod N then check: res==b^(e mod eulerphi(d)) mod d [Euler-Fermat], for gcd(b,d)=1 and d|N, so you need to update only the e mod eulerphi(d) at each step and not the slightly more costly b^e mod d. [since d is usually very small compared to N this makes not a large difference in timing].

[QUOTE=ATH;582158]I'm doing P+1, do I need to do P-1 as well on each exponent?
Should I continue above the maximum in case of no failures below?[/quote]

P+1 is sufficient. Don't go above the maximum if no failures are found.

[quote]I started at M32611 and reached a roundoff error at M33391, should I do more testing for this FFT?[/quote]

To be safe, length 1.5K AVX-512 FFT max exponent changed to 33380.

I am having a worker-count related issue with Prime95. I have been using (4 workers, 3 cores) configuration for a while. Now I've decided to make it (12 workers, 1 core), because of the better throughput at 50K FFT, which is what I am doing now - P-1 in 1M range on factored exponents. So I went and set the Prime95 accordingly. When I started the workers, it went fine, but when it got to starting worker #6, it crashed. The same happened when I restarted the program.

Workers #1 to #4 have plenty of work in their worktodo entries, worker #5 was assigned CERT, but the rest is hungry. Is it possible that it crashes because of that?

I am using version 30.6b4, processor is Ryzen 9 3900X (12 cores).

After a few testing attempts, it seems to crash precisely when all the first 4 workers finally agreed on RAM consumption (3 of them are in stage 2) and started working. That happens somewhere around the start of worker #8, i.e. about 40 seconds after the start of the program (there are 5-second delays between worker starts).

Weird... When I fed the workers with assignments, it's no longer crashing.

But I am going to (6 workers, 2 cores), because 12 workers make the CPU really hot, 92 °C.

Sounds like a bug in workers coordinating memory allocation. Read undoc.txt and look for the option that limits each workers maximum memory. Also I'd consider limiting the number of workers that can be in stage 2 at the same time.

Something like for 6 workers / 16GB, only allow 3 workers do stage 2 at one time with a 5.3GB cap on each workers mem usage.

[QUOTE=Prime95;583214]Sounds like a bug in workers coordinating memory allocation. Read undoc.txt and look for the option that limits each workers maximum memory. Also I'd consider limiting the number of workers that can be in stage 2 at the same time.

Something like for 6 workers / 16GB, only allow 3 workers do stage 2 at one time with a 5.3GB cap on each workers mem usage.[/QUOTE]

I'll keep that in mind in case I need to apply it - so far, 6 well-fed workers are working fine.

But there is a roundoff related bug. P-1 test of M1041949, B1=10,000,000, FFT=50K, Pass1=640, Pass2=80, clm=1, seems to have the same error - it reports possible roundoff error with value 0.4375 and cycles from the last savefile - at the same place during Stage 1 (49.15%). Behavior repeats after the deletion of all related savefile and a fresh start.

[QUOTE=Viliam Furik;583262]
But there is a roundoff related bug. P-1 test of M1041949, B1=10,000,000, FFT=50K, Pass1=640, Pass2=80, clm=1, seems to have the same error - it reports possible roundoff error with value 0.4375 and cycles from the last savefile - at the same place during Stage 1 (49.15%). Behavior repeats after the deletion of all related savefile and a fresh start.[/QUOTE]

I'll work on improving error recovery in 30.7. For now, you'll need to force a larger FFT length. SafetyMargin in undoc.txt may help.

[QUOTE=Prime95;583264]I'll work on improving error recovery in 30.7. For now, you'll need to force a larger FFT length. SafetyMargin in undoc.txt may help.[/QUOTE]

Setting it to 0.005 should do the trick?

EDIT:
For some reason, setting the ExtraSafetymargin to 0.005 and 0.01 just makes it crash right at the beginning.

One can [B]add[/B] lines to worktodo.txt whilst mprime is running by use of worktodo.add, as documented in undoc.txt. A similar facility to [B]remove[/B] entries, using a file worktodo.remove, would be useful.

[QUOTE=drkirkby;583532]One can [B]add[/B] lines to worktodo.txt whilst mprime is running by use of worktodo.add, as documented in undoc.txt. A similar facility to [B]remove[/B] entries, using a file worktodo.remove, would be useful.[/QUOTE]One obvious way to do that, and it can help cleaning up manual assignments one don't bother about anymore, is to go to the [url=https://www.mersenne.org/workload/]Assignments page on Primenet[/url] and un-assign them. If they are not manual assignments, the next synchronisation, be it manual or automatic, will remove them from the work list.

Jacob

[QUOTE=Viliam Furik;583266]Setting it to 0.005 should do the trick?

EDIT:
For some reason, setting the ExtraSafetymargin to 0.005 and 0.01 just makes it crash right at the beginning.[/QUOTE]

At 200K AVX-512 FFT I had to use "ExtraSafetymargin=0.03" for it to use the next higher 240K FFT, but I guess it depends on how far from the border you are, and maybe on the current FFT.

The next FFT above 50K for you should be 60K, so keep increasing ExtraSafetymargin until it chooses 60K for the assignments.

[QUOTE=ATH;583536]At 200K AVX-512 FFT I had to use "ExtraSafetymargin=0.03" for it to use the next higher 240K FFT, but I guess it depends on how far from the border you are, and maybe on the current FFT.

The next FFT above 50K for you should be 60K, so keep increasing ExtraSafetymargin until it chooses 60K for the assignments.[/QUOTE]

I've made it 0.1. I will see if it works.

[QUOTE=S485122;583534]One obvious way to do that, and it can help cleaning up manual assignments one don't bother about anymore, is to go to the [URL="https://www.mersenne.org/workload/"]Assignments page on Primenet[/URL] and un-assign them. If they are not manual assignments, the next synchronisation, be it manual or automatic, will remove them from the work list.

Jacob[/QUOTE]Thank you.

[QUOTE=drkirkby;583532]to [B]remove[/B] entries, using a file worktodo.remove, would be useful.[/QUOTE]
Why not text editor including save file, followed by stop all workers, continue all workers, manual communication, send new expected completion dates to server?

[QUOTE=kriesel;583558]Why not text editor including save file, followed by stop all workers, continue all workers, manual communication, send new expected completion dates to server?[/QUOTE]That requires stopping all the workers, which I would rather not do. I suspect George must have felt it desirable to be able to add entries to worktodo.txt without stopping workers, which is probably why the worktodo.add facility exists.

As a test I just
[LIST=1][*]Added something like "PRP=1,2,big_exponent,-1,76,1" to worktodo.add[*]Forced a manual communication with mprime -c. The server assigned me the big exponent, so it got added to worktodo.txt[*]Unassigned the unwanted exponent at [URL]https://www.mersenne.org/workload/[/URL][*]Forced a second manual communication (mprime -c). The entry got removed from worktodo.txt, just as S485122 wrote it would.[/LIST]I think that's preferable to stopping all workers.

Only if you are near the work that everyone else is doing or you keep less than a day of work in you queue do you need to force coms right away. If you just stick the work in the worktodo.add and go to sleep for the night, at some point it will do coms and pick up the AID. Same thing the other way. Normal coms will catch it.

[QUOTE=Uncwilly;583561]Only if you are near the work that everyone else is doing or you keep less than a day of work in you queue do you need to force coms right away. If you just stick the work in the worktodo.add and go to sleep for the night, at some point it will do coms and pick up the AID. Same thing the other way. Normal coms will catch it.[/QUOTE]Thank you. I forced the communications because I wanted to verify it all behaved as I was hoping it would, but I take your point, in normal circumstances there would be no need to do it. (For the test purposes I picked an exponent in the 200 million range, so there would have been little interest by others.)

[QUOTE=Prime95;583264]I'll work on improving error recovery in 30.7[/QUOTE]
Hope you could fix in v30.7 the old "worker windows" bug, where the "CPU cores to use" option is very difficult to adjust.

Dissimilar exponents get very similar stage 2 ram allocation by default
 

Tested on prime95 V30.6b4, dual 12-core Xeon E5-2697v2, Win10 pro, 128 GiB system, total available ram for stage 2 110 GiB, no per worker settings. In local.txt (yes that global memory line could be simplified)

[CODE]Memory=112640 during 7:30-23:30 else 112640

[Worker #1]

[Worker #2][/CODE]For 105M P-1 on worker 1 of 2, 100Mdigit P-1 on worker 2 of 2, while worker 1 stage 1 or 2 coincide with worker 2 stage 1, no ram contention. When worker 2 runs the 100Mdigit stage 2 which will be ~(332/105)[SUP]2.1[/SUP] ~11 times as long as for worker 1's 105M stage 2's, the system will toggle repeatedly several times per 100Mdigit on worker two, between 1 and 2 workers wanting lots of stage 2 ram at a given time. That looks like the following. It splits the available ram equally between the two (or n) workers with disparate exponents. ram of any stage 2 P-1 worker ~ availableram / n. Regardless of exponent.
A perhaps more optimal way to split the available ram would be ram[SUB]n[/SUB] ~ availableram * exponent[SUB]n[/SUB]/(sum of exponents of workers in stage 2). For example, in the case above, 105M and 332M, ram[SUB]1[/SUB] ~ 110 * 105 / (105+332) = 26.4 GiB; ram[SUB]2[/SUB] ~ 110 * 332 / (105+332) = 83.6 GiB. 26.4GiB/83.6GiB ~105M/332M.

[CODE][Jul 21 16:21:46] Waiting 5 seconds to stagger worker starts.
[Jul 21 16:21:52] Worker starting
[Jul 21 16:21:52] Setting affinity to run worker on CPU core #13
[Jul 21 16:21:52] Optimal P-1 factoring of M332222819 using up to 112640MB of memory.
[Jul 21 16:21:52] Assuming no factors below 2^78 and 2 primality tests saved if a factor is found.
[Jul 21 16:21:52] Optimal bounds are B1=2759000, B2=176703000
[Jul 21 16:21:52] Chance of finding a factor is an estimated 6.08%
...
[Jul 21 16:21:56] M332222819 stage 1 is 19.553% complete.
[Jul 21 16:25:24] M332222819 stage 1 is 19.804% complete. Time: 208.451 sec.
...
[Jul 22 11:46:50] M332222819 stage 1 is 99.455% complete. Time: 233.422 sec.
[Jul 22 11:50:40] M332222819 stage 1 is 99.706% complete. Time: 230.289 sec.
[Jul 22 11:54:33] M332222819 stage 1 is 99.957% complete. Time: 232.733 sec.
[Jul 22 11:55:11] M332222819 stage 1 complete. 6403366 transforms. Time: 70394.576 sec.
[Jul 22 11:55:11] Starting stage 1 GCD - please be patient.
[Jul 22 11:58:14] Stage 1 GCD complete. Time: 182.190 sec.
[Jul 22 11:58:14] Available memory is 112587MB.
[Jul 22 11:58:15][B][I] D: 462, relative primes: 765, stage 2 primes: 9655948, pair%=87.93[/I][/B]
[Jul 22 11:58:15][I][B] Using 112478MB of memory.[/B][/I]
[Jul 22 12:00:58] Stage 2 init complete. 6971 transforms. Time: 164.592 sec.
[Jul 22 12:06:09] M332222819 stage 2 is 0.177% complete. Time: 310.526 sec.
[Jul 22 12:11:21] M332222819 stage 2 is 0.355% complete. Time: 312.158 sec.
...
[Jul 22 12:47:51] M332222819 stage 2 is 1.604% complete. Time: 315.325 sec.
[Jul 22 12:53:10] M332222819 stage 2 is 1.782% complete. Time: 319.193 sec.
[Jul 22 12:58:25] M332222819 stage 2 is 1.960% complete. Time: 315.494 sec.
[Jul 22 13:00:26] [I][B]Restarting worker with new memory settings.[/B][/I]
[Jul 22 13:00:40] Optimal P-1 factoring of M332222819 using up to 112640MB of memory.
[Jul 22 13:00:40] Assuming no factors below 2^78 and 2 primality tests saved if a factor is found.
[Jul 22 13:00:40] Optimal bounds are B1=2759000, B2=176703000
[Jul 22 13:00:40] Chance of finding a factor is an estimated 6.08%
[Jul 22 13:00:40]
[Jul 22 13:00:42] Setting affinity to run helper thread 3 on CPU core #16
[Jul 22 13:00:42] Setting affinity to run helper thread 9 on CPU core #22
[Jul 22 13:00:42] Setting affinity to run helper thread 5 on CPU core #18
[Jul 22 13:00:42] Setting affinity to run helper thread 7 on CPU core #20
[Jul 22 13:00:42] Setting affinity to run helper thread 6 on CPU core #19
[Jul 22 13:00:42] Setting affinity to run helper thread 2 on CPU core #15
[Jul 22 13:00:42] Setting affinity to run helper thread 1 on CPU core #14
[Jul 22 13:00:42] Setting affinity to run helper thread 4 on CPU core #17
[Jul 22 13:00:42] Using AVX FFT length 18M, Pass1=1536, Pass2=12K, clm=2, 12 threads
[Jul 22 13:00:42] Setting affinity to run helper thread 10 on CPU core #23
[Jul 22 13:00:42] Setting affinity to run helper thread 11 on CPU core #24
[Jul 22 13:00:42] Setting affinity to run helper thread 8 on CPU core #21
[Jul 22 13:00:45] Available memory is 56322MB.
[Jul 22 13:00:47] [B][I]D: 420, relative primes: 380, stage 2 primes: 8359345, pair%=80.86[/I][/B]
[Jul 22 13:00:47] [I][B]Using 56176MB of memory.[/B][/I]
[Jul 22 13:02:08] Stage 2 init complete. 3998 transforms. Time: 83.241 sec.
[Jul 22 13:02:09] M332222819 stage 2 is 2.035% complete.
[Jul 22 13:07:01] M332222819 stage 2 is 2.209% complete. Time: 292.909 sec.
[Jul 22 13:11:55] M332222819 stage 2 is 2.383% complete. Time: 293.947 sec.
[Jul 22 13:16:47] M332222819 stage 2 is 2.555% complete. Time: 291.975 sec.
[Jul 22 13:21:40] M332222819 stage 2 is 2.730% complete. Time: 292.363 sec.
[Jul 22 13:26:37] M332222819 stage 2 is 2.902% complete. Time: 297.669 sec.[/CODE]

I'm trying to see what happens as the saved tests varies, so I set it to [B]1.05[/B] in worktodo.txt. But mprime reports it is using [B]1.1[/B]. Is mprime using 1.05, and just rounding the output to 2 significant digits, or is it using 1.1? If it is rounding the output, is there any chance of giving an extra two or three decimal places in the reported output? I expect people will start using values slightly over 1.0, to take account of the time to verify the proof.

My interest was to see if I could maximise the equation
[URL]https://www.mersenne.org/various/math.php#p-1_factoring[/URL]
by using values of saved test slightly different from 1.0, since I expect the best value might depend on the speed of access to RAM in stage 2 of the P-1 factoring.

I noticed that setting it to 1.15 also has Prime95 reporting as using 1.1

Try some of 1.0, 1.05, 1.1, 1.15, 1.2, and note both variation in prime95's indication of tests_saved, [B]and any corresponding variation in the selected bounds[/B], for same or very similar exponents. If tests_saved is being rounded for display only, bounds display will give greater resolution.
If tests_saved is being subjected to a 0.1-unit stairstepping before determining bounds, bounds matching at 0.05 tests-saved differences would confirm that.

Or have a look at the source code.

If use Prime95 as I use to find PRP on CRUS then I dont need proof files. But I like option that P-1 is little faster. So I can do all I do before except fact to disable creating of proof files. I try all options in undoc.txt but still proof files are created.
Any help?
Version was latest build of Prime95 30.6

[QUOTE=pepi37;583986]If use Prime95 as I use to find PRP on CRUS then I dont need proof files. But I like option that P-1 is little faster. So I can do all I do before except fact to disable creating of proof files. I try all options in undoc.txt but still proof files are created.
Any help?
Version was latest build of Prime95 30.6[/QUOTE]

Did you try simply deleting the paths to directories for residues and proofs in the advanced section of the resource limits menu? That might be able to force it to not create proofs. Or the program will be stubborn and will use its home folder. Either way, worth trying.

[QUOTE=Viliam Furik;583990]Did you try simply deleting the paths to directories for residues and proofs in the advanced section of the resource limits menu? That might be able to force it to not create proofs. Or the program will be stubborn and will use its home folder. Either way, worth trying.[/QUOTE]
Good idea, but not working, directory path are empty at the start...

I must say George, this has some of the best commented C code I have ever seen. :tu::tu::tu::tu::tu: It would be nice if there were some instructions for building on linux, but I eventually worked it out.
[CODE]$ cd gwnum
$ make -f make64
$ cd ../linux64
$ make
[/CODE]Prior to realising that the gwnum library had to be built first, I had a few problems, as I was trying to change linux64/makefile unnecessarily to use the gwnum.a included with the source distribution.

But the actual C code is very readable. :tu::tu::tu::tu::tu: I found it more readable than some of my own code that I wrote years ago!

Is there any chance you giving us an extra digit or two in the probability of finding a factor, by changing this line in ecm.c?
[CODE] sprintf (buf, "Chance of finding a factor is an estimated %.3g%%\n", prob * 100.0);[/CODE]I was keen to know if giving more RAM to stage 2 of P-1 was beneficial or not. For that I need the probability of finding the factor, along with the time to execute the P-1 factoring and the time to perform the PRP test. An extra digit or two would be useful. Fortunately I can don't need to re-run my tests, as I can simply increase the number of digits, then exit the code, without repeating the test.
I've not actually run my modified mprime yet, as I'm benchmarking a PRP test and don't want to change the load on the machine, which would change the completion times.

Immediate PC crash on starting Prime95
 

PS. Windows 10

There have been a couple power outages recently here.
When one of my 5 PCs came up it had lost worktodo.txt and local.txt.
I recreated them and restarted and the PC immediately shutdown (no blue screen...just boom)
I deleted the pminus1 workfiles (on a whim) and it proceeded to work.

The most recent outage; same symptoms. The above did not help.
I upgraded to the newest version here...same result.

I downgraded to the version on the public GIMPS website and now it runs.

I can't be sure it is version related or just a flaky PC.

PS: memtest ran error free.

I don't know the cause, but I submitted the results from a PRP test of [M]M105212323[/M] using mprime 30.6b4. The log does not indicate any errors, but the proof file was never generated.

[CODE][Worker #2 Jul 28 01:55] Generating proof for M105212323. Proof power = 9, Hash length = 64
[Worker #2 Jul 28 02:00] M105212323 is not prime. RES64: 2C388CF0B9F55BCD. Wh8: 5FC89719,92743653,00000000
[Comm thread Jul 28 02:00] Sending result to server:...[/CODE]After the result was sent to there's noting more in the logs - no error message. There's nothing left in the working directory.

It could of course be a problem with my computer, but it is not overclocked, has mostly empty PCI slots and has ECC RAM.

[QUOTE=drkirkby;584380]I don't know the cause, but I submitted the results from a PRP test of [M]M105212323[/M] using mprime 30.6b4. The log does not indicate any errors, but the proof file was never generated.

[CODE][Worker #2 Jul 28 01:55] Generating proof for M105212323. Proof power = 9, Hash length = 64
[Worker #2 Jul 28 02:00] M105212323 is not prime. RES64: 2C388CF0B9F55BCD. Wh8: 5FC89719,92743653,00000000
[Comm thread Jul 28 02:00] Sending result to server:...[/CODE]After the result was sent to there's noting more in the logs - no error message. There's nothing left in the working directory.

It could of course be a problem with my computer, but it is not overclocked, has mostly empty PCI slots and has ECC RAM.[/QUOTE]

When you say "working directory" what do you mean? Are you sure it is absolutely empty? Do you have the correct permissions for the "working directory"? Have you allowed some time to elapse for the upload and the reporting?

[QUOTE=paulunderwood;584382]When you say "working directory" what do you mean? Are you sure it is absolutely empty? Do you have the correct permissions for the "working directory"? Have you allowed some time to elapse for the upload and the reporting?[/QUOTE]I run all the GIMPS work from $HOME/gimps. Everything runs from there. The PRP test result was uploaded more than 52 hours ago, but I don't believe a proof has been uploaded.

An hour and fifteen minutes after [M]M105212323[/M] was known not to be prime, [M]M105196813[/M] was completed on the machine, working in the same directory. Looking at what happened with [M]M105196813[/M]
[CODE][Worker #3 Jul 28 03:09] Generating proof for M105196813. Proof power = 9, Hash length = 64
[Worker #3 Jul 28 03:15] M105196813 is not prime. RES64: B36955DB15C715B8. Wh8: DD238B1C,24691551,00000000
[Comm thread Jul 28 03:26] MD5 of p105196813.proof is 638b15dc2ea53a58984ef43d9c5506dc
[Comm thread Jul 28 03:26] Proof file exponent is 105196813
[Comm thread Jul 28 03:26] Filesize of p105196813.proof is 131496078

[Comm thread Jul 28 03:43] Proof file p105196813.proof successfully uploaded
[/CODE]So for [M]M105196813[/M], the proof was successfully uploaded 28 minutes after the number was known not to be prime, with most of that 28 minutes being the upload - the proof had been generated 11 minutes after the number was known not to be prime. I think it is safe to say that no proof will be generated or uploaded for [M]M105212323[/M], since it should have happened long before now.

I don't know if its any coincidence, but I had run two P-1 tests on [M]M105212323[/M], as I was doing a bit of benchmarking. It will be interesting to see if [M]M105211111[/M] gets a proof uploaded when it completes, as I had run multiple P-1 tests on that too. [M]M105211111[/M] should complete by about 23:00 UTC today. My strategy for running the multiple P-1 tests on [M]M105212323[/M] was

[LIST=1][*]Start the mprime with the entry in worktodo.txt indicating 1 test would be saved.[*]When I'd seen that the P-1 had finished, and the PRP started, I would kill mprime and delete any files on disk related to it.[*]Edit worktodo.txt to put the number of saved tests to 2.[*]Run mprime again, but this time let the PRP test finish after the P-1 had been run.[/LIST]I find it a bit hard to believe that doing this would have stopped the proof being generated, but it is something I did which I don't normally do.

[QUOTE=petrw1;584353]PS. Windows 10

There have been a couple power outages recently here.
When one of my 5 PCs came up it had lost worktodo.txt and local.txt.
I recreated them and restarted and the PC immediately shutdown (no blue screen...just boom)
I deleted the pminus1 workfiles (on a whim) and it proceeded to work.

The most recent outage; same symptoms. The above did not help.
I upgraded to the newest version here...same result.

I downgraded to the version on the public GIMPS website and now it runs.

I can't be sure it is version related or just a flaky PC.

PS: memtest ran error free.[/QUOTE]

My first 2 results since are showing up under -Anonymous-.

This is my Comm window:
[CODE][Main thread Jul 29 16:15] Mersenne number primality test program version 30.3
[Main thread Jul 29 16:15] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 4x256 KB, L3 cache size: 6 MB
[Main thread Jul 29 16:15] Starting workers.
[Comm thread Jul 30 06:21] Sending result to server: UID: petrw1/Rocky, M35385751 completed P-1, B1=1500000, B2=45000000, E=6, Wh4: 91BFD03E
[Comm thread Jul 30 06:21]
[Comm thread Jul 30 06:21] PrimeNet success code with additional info:
[Comm thread Jul 30 06:21] CPU credit is 7.0144 GHz-days.
[Comm thread Jul 30 06:21] Done communicating with server.
[Comm thread Jul 30 07:19] Sending result to server: UID: petrw1/Rocky, M35329157 completed P-1, B1=1500000, B2=45000000, E=6, Wh4: 9338DECD
[Comm thread Jul 30 07:19]
[Comm thread Jul 30 07:19] PrimeNet success code with additional info:
[Comm thread Jul 30 07:19] CPU credit is 7.0144 GHz-days.
[Comm thread Jul 30 07:19] Done communicating with server.[/CODE]

These are the exponent status pages from here:
[url]https://www.mersenne.org/report_exponent/?exp_lo=35385751&exp_hi=&full=1[/url]

[CODE]35385751 No factors below 274
P-1
B1= 1 500 000
B2= 45 000 000
Date User Type Result
2021-07-30 -Anonymous- NF-PM1 B1=1500000, B2=45000000, E=6
[/CODE]

This part got fixed....
 

Something was awry in local or prime.txt I checked the Test... Primenet... box and both fields were there.
I did manual comm and checked again and userid was blank.
I filled it in again and re commed and its okay now.

I'll try again tomorrow to see if I can run 30.5 yet....not holding my breath.

[QUOTE=petrw1;584415]My first 2 results since are showing up under -Anonymous-.

This is my Comm window:
[CODE][Main thread Jul 29 16:15] Mersenne number primality test program version 30.3
[Main thread Jul 29 16:15] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 4x256 KB, L3 cache size: 6 MB
[Main thread Jul 29 16:15] Starting workers.
[Comm thread Jul 30 06:21] Sending result to server: UID: petrw1/Rocky, M35385751 completed P-1, B1=1500000, B2=45000000, E=6, Wh4: 91BFD03E
[Comm thread Jul 30 06:21]
[Comm thread Jul 30 06:21] PrimeNet success code with additional info:
[Comm thread Jul 30 06:21] CPU credit is 7.0144 GHz-days.
[Comm thread Jul 30 06:21] Done communicating with server.
[Comm thread Jul 30 07:19] Sending result to server: UID: petrw1/Rocky, M35329157 completed P-1, B1=1500000, B2=45000000, E=6, Wh4: 9338DECD
[Comm thread Jul 30 07:19]
[Comm thread Jul 30 07:19] PrimeNet success code with additional info:
[Comm thread Jul 30 07:19] CPU credit is 7.0144 GHz-days.
[Comm thread Jul 30 07:19] Done communicating with server.[/CODE]

These are the exponent status pages from here:
[url]https://www.mersenne.org/report_exponent/?exp_lo=35385751&exp_hi=&full=1[/url]

[CODE]35385751 No factors below 274
P-1
B1= 1 500 000
B2= 45 000 000
Date User Type Result
2021-07-30 -Anonymous- NF-PM1 B1=1500000, B2=45000000, E=6
[/CODE][/QUOTE]

[QUOTE=petrw1;584476]Something was awry in local or prime.txt I checked the Test... Primenet... box and both fields were there.
I did manual comm and checked again and userid was blank.
I filled it in again and re commed and its okay now.

I'll try again tomorrow to see if I can run 30.5 yet....not holding my breath.[/QUOTE]

After 2 days of it running version 30.3 just find I stopped Prime95 and tried a few different version of 30.4/30.5 ... all caused my PC to shutdown seconds after starting Prime95.

I reverted back to 30.3 ... guess what BOOM! PC Shutdown on start of Prime95; 3 tries; 3 shutdowns.

So it is software conflicts or faulty hardware....???

Running a Prime95 stress test now...after 2 hours all tests passed so far.

PS...is there some secret debug option in Prime95 what will spew out logs that can be analyzed after a failure such as this?

So the latest is that this PC has no issue running DC, ECM or Pfactor. But still shuts down as soon as it starts or continues a Pminus1.

For now I've converted my Pminus1 to comparable Pfactor and it seems to be content.

[QUOTE=petrw1;584566]So the latest is that this PC has no issue running DC, ECM or Pfactor. But still shuts down as soon as it starts or continues a Pminus1.

For now I've converted my Pminus1 to comparable Pfactor and it seems to be content.[/QUOTE]

It's possible there is some weird connection to my problems with Pminus1. (starting here at post #329)

Are your workers well-fed? :grin:

I didn't have problems with system shutdowns, only the Prime95 stopped. But still, there may be more to it.

What is your worker configuration, and CPU model?

Is it continuing from a savefile? If so, try renaming it.

If that fixes it, send me the savefile and worktodo.txt

I assume it is an oversight, but in the source distribution of version 30.6b4, there's no assembly code for factor64 on linux. There's an object file (factor64.o), and assembly code for other platforms, but not 64-bit linux.
[CODE]drkirkby@canary:/tmp/src$ find . -name 'factor64*'
./prime95/amd64/factor64.obj
./prime95/macosx64/factor64.o
./prime95/factor64.mac
./prime95/factor64.asm
./linux64/factor64.o
drkirkby@canary:/tmp/src$[/CODE]

factor64.o is built from factor64.asm

[QUOTE=Prime95;584568]Is it continuing from a savefile? If so, try renaming it.

If that fixes it, send me the savefile and worktodo.txt[/QUOTE]

I've tried deleting all save files too with no difference.
I've tried lower bounds, more or less workers ... .every attempt crashes the PC.

I tend to believe it is a conflict between my specific Windows 10 state and something in the pminus1 code.
I wish I could be more specific.

[QUOTE=petrw1;584582]I've tried deleting all save files too with no difference.
I've tried lower bounds, more or less workers ... .every attempt crashes the PC.

I tend to believe it is a conflict between my specific Windows 10 state and something in the pminus1 code.
I wish I could be more specific.[/QUOTE]The fact that running an unprivileged program leads to "the PC immediately shutdown (no blue screen...just boom)" is interesting [noparse];-)[/noparse] But it probably means there are no crash dump files [noparse]:-([/noparse]

But you should still check the dedicated folder : %UserProfile%\AppData\Local\CrashDumps (C:\Users\User\AppData\Local\CrashDumps for the user "User") for .dmp files. One way to do that is to open an elevated command prompt, "cd" to the root of your disk, and enter the "dir *.dmp /s /a" command, it will search the whole disk, including hidden and system folders and files. If there are files that seem relevant by their date, you can use the free program "WinDbg" that you can download from the MicrosoftStore, to show the content of dump files in a user "friendly" way. The files or the WinDbg output might interest George [noparse]:-)[/noparse]

Since the initial crash lead to loss or corruption of several files (prime.txt, local.txt ...) you could look for disk errors in the event viewer, do a CHKDSK /F from an elevated command prompt but most probably the storage is OK.

One thing you could do, is to install [url=ftp://mersenne.org/gimps/p95v306b4.win64.zip]the latest version of prime95[/url] in a NEW folder, NOT using ANY your old prime95 files (prime.txt, local.txt, worktodo.txt, ...) Enter computer and user name, set the maximum memory, stop prime95 and inject the P-1 assignment in your worktodo.txt file after checking its syntax or better get a P-1 assignment from PrimeNet.

If that leads to the same results a thorough check of Windows might be useful (dism and scansfc...)

Jacob

[QUOTE=Prime95;584572]factor64.o is built from factor64.asm[/QUOTE]Thank you. The linux64/makefile only contains
[CODE]FACTOROBJ = factor64.o[/CODE]so does not have enough information to build factor64.o from factor64.asm, which is in prime95/factor64.asm. I thought that file was for Windows only, since it was in the prime95 directory.

I could work out how to do it, but it's not necessary for me, as it was ecm.c that I wanted to recompile. I did manage to build the program, and achieved what I wanted to, but I believe the makefile is lacking the required information.

[QUOTE=drkirkby;584621]Thank you. The linux64/makefile only contains ... so does not have enough information to build factor64.o from factor64.asm, which is in prime95/factor64.asm[/QUOTE]

That raises an interesting point... The "make" system allows implicit build paths. Perhaps this particular target should be more explicitly and clearly defined.

Given a million idiots, occasionally a very small number of them will guess (and radiate) something worth thinking about...

[QUOTE=chalsall;584630]Given a million idiots, occasionally a very small number of them will guess (and radiate) something worth thinking about...[/QUOTE]Was that comment really necessary?

I've been on a large number of forums in my years on the internet, including two maths related
[LIST=1][*]I did a huge amount of work in porting the SageMath software to Solaris. I had few disagreements with anyone over the years.[*]Mathematica forums.[*]Keysight forum for professional test equipment.[*]Amateur radio forums.[*]Web design forums[*]Computer server forum.[*]Some on groups.io that I jointly own - i always share ownership, in case I die.[*]Many others.[/LIST][B]I've never come across any with such a toxic atmosphere as here.[/B] I had some PMs with someone who was getting abuse for asking too many questions. In a PM he wrote:

[I][B]"I have been around here for a long time, and the tone rarely gets as bad as it has been lately. It will get better, and more relaxed, like it always does."[/B][/I]

I point out an issue with a makefile, and get comments about a million idiots.

[QUOTE=drkirkby;584633]I point out an issue with a makefile, and get comments about a million idiots.[/QUOTE]

To be perfectly honest... You talk too much. You ask way too many questions which have already been answered. You are lazy, and like to see your words "in print".

The very patient amongst us say things like "don't scare off people".

The more serious say things along the lines of don't waste our very valuable time.

Read the prior art.

Please!!!

[QUOTE=drkirkby;584621]Thank you. The linux64/makefile only contains
[CODE]FACTOROBJ = factor64.o[/CODE]so does not have enough information to build factor64.o from factor64.asm, which is in prime95/factor64.asm.[/QUOTE]

The make process is a bit of a mess as you've discovered.

None of the make files deal with assembly code. Originally, only Microsoft MASM could assemble the source and MASM only ran under Windows. An object file converter by Agner Fog was used to create the Linux .o files. Recently, I switched to UASM, an open source MASM knockoff. In theory, UASM runs under Linux, but I've never tried it.

wide fluctuation in prime95 p-1 stage 2 update time
 

Running prime95 v30.6b4 on a laptop with Windows 10 Home version 21H1 build 19043.1110, stage 2 of a large exponent, 12GB allowed of 16GB system ram, power settings to never sleep or hibernate while plugged in, and observed drastic variation in time between updates of the same exponent's stage 2 progress of over 33:1.
It had earlier been running solidly at ~1200 seconds (20 minutes) between updates.

Any ideas on what caused it or how to stop the slowdowns from occurring?
I've tried dropping the allowed ram from 12GB to 11 but also see occasional high disk activity there.

While prime95 showed ~11GB being used, Task Manager showed ~4GB ram use for the prime95 process and sometimes ~350MB/sec of disk activity. Stop and restart of the app made no difference. Memory was ~97% in use, but no conspicuous memory hog in the process listing in Task Manager. Prime95 is the only app running.

A system restart seems to have cleared up the situation for now, with Task Manager showing prime95 using ~11GB ram now.

[QUOTE=petrw1;584582]I've tried deleting all save files too with no difference.
I've tried lower bounds, more or less workers ... .every attempt crashes the PC.

I tend to believe it is a conflict between my specific Windows 10 state and something in the pminus1 code.
I wish I could be more specific.[/QUOTE]

So now it also crashes doing PFactor.
A little more digging leads me to believe it may be the power supply.
I can run 3 (of 4) cores just fine but when I start the 4th.....bada BOOOM!!!

HOWEVER....it does NOT BOOM if I run the Benchmarks or Stress test using all 4 cores .... ummmm

disparity between iteration times
 

I am doing double checking on Mersennes in the trailing edge.
All those work units use the same FFT path :
AVX-512 FFT length 3M, Pass1=192, Pass2=16K, clm=2, 12 threads

What I don't understand is that sometimes the iteration times are about 10% higher for some exponents. It isn't linked to the exponent size, the workload on the computer, memory usage or the external and thus the internal temperature.
56606299 0,933
56713403 1,036
56713903 0,930
58008077 0,932
58011197 0,941
58157783 1,021
58203581 0,924
58238839 0,932
58238963 0,924
The slower runs are preceded and followed by "normal" runs.

[QUOTE=S485122;585746]sometimes the iteration times are about 10% higher for some exponents[/QUOTE]I have no answer for you, but just confirming for anyone else pondering the problem that the reported FFT length is indeed identical for "fast" and "slow" results: [c]3145728[/c]

[QUOTE=Prime95;584647]The make process is a bit of a mess as you've discovered.

None of the make files deal with assembly code. Originally, only Microsoft MASM could assemble the source and MASM only ran under Windows. An object file converter by Agner Fog was used to create the Linux .o files. Recently, I switched to UASM, an open source MASM knockoff. In theory, UASM runs under Linux, but I've never tried it.[/QUOTE]

Haven't managed to get UASM to compile from the repo yet and the linux binary is a dead link. Got as far as it erroring on compile with clang-10/gcc/g++ because it can't find direct.h, a windows header (not sure if it's something I should be supplying or if cross-platform support is broken). The makefile wants to use clang-3.8 by default which is 4 years old, doesn't inspire much confidence that cross-platform support remains functional.

Assuming UASM can be compiled for Linux there are few issues with compile and compil64 that mean the makefiles fail (make doesn't like spaces instead of tabs, backslash delimiters fail, calling a bat file fails, attrib doesn't exist on Linux). I've attached versions that are some way towards functional on Linux. Object files are generated at least for 32 bit (untested), 64 bit fails on amd64/factor64.obj which may or may not be a makefile issue (this is with v30.3b6):
[code]UASM v2.52, Apr 2 2021, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.

factor64.asm(1530) : Error A2049: Invalid instruction operands
factor64.asm: 6417 lines, 1 passes, 24 ms, 0 warnings, 1 errors
00f4:fixme:ver:GetCurrentPackageId (000000000021FDA0 0000000000000000): stub
make: *** [linuxcompil64:25: amd64/factor64.obj] Error 1[/code]objconv compiles for Linux but as uasm didn't I had to use a bash wrapper using wine for now:
[code]u20@u20:~$ cat bin/uasm64
#!/bin/bash
WINEPREFIX=~/.prefix64 wine ~/bin/uasm64.exe "$@"[/code]For the makefiles to have any chance of working objconv and uasm64 need to be in the PATH.

Technically uasm should be able to generate Linux-compatible object files directly but it's probably best that the object files are generated the same way regardless of the OS used during compilation.

[QUOTE=M344587487;585762]Haven't managed to get UASM to compile from the repo yet and the linux binary is a dead link. Got as far as it erroring on compile with clang-10/gcc/g++ because it can't find direct.h, a windows header (not sure if it's something I should be supplying or if cross-platform support is broken). [/QUOTE]According to

[URL]https://en.wikipedia.org/wiki/Direct.h[/URL]
direct.h in a Windows file, but POSIX versions of [B]some [/B]of the functions are in unistd.h. So something like the following has some chance of working in a C file, so it compiles both on Linux and Windoze.
[CODE]
#ifdef __WINDOWS // Or whatever gets defined on a Windoze system.
#include <direct.h>
#else
#include <unistd.h>
#endif
[/CODE]

generalization of p-1 and p+1
 

[QUOTE=Prime95;576305]Prime95 version 30.6 build 2 is available. You could be the first to find a new factor using P+1.[/QUOTE]

As you already have implemented both P-1 and P+1 methods in your software, have you looked into implementing a generalization of these two methods [url=https://en.wikipedia.org/wiki/Williams%27s_p_%2B_1_algorithm#Generalization]referred here[/url] (and paper is [url=https://www.ams.org/journals/mcom/1989-52-185/S0025-5718-1989-0947467-1/S0025-5718-1989-0947467-1.pdf]here[/url]), it allows to find factors for any B-smooth cyclotomic polynomial, like 1) p - 1, 2) p + 1, 3) p^2 + p + 1, 4) p^2 + 1, etc.

Of cause I expect that this generalization is much more difficult to implement, but allows to check more of B-smooth candidates. I don't know details of its mathematics, I just found this generalization reference in Wikipedia.

PauseWhileRunning vs CERT work
 

I make use of [c]PauseWhileRunning[/c] to pause Prime95 while other (sometimes long-running) jobs are active. One thing I have noticed is that Prime95 will still communicate with the server while it's paused and get Certification assignments which may not get worked on for hours/days/weeks. It's fine to communicate with the server while paused to send any queued results and update assignment ETA, but I don't think it should request certification (or any?) work while paused.

Shutting down during proof generation results in redoing iterations
 

An old problem, see: [URL]https://www.mersenneforum.org/showthread.php?t=26933[/URL]
AFAIK, writing a checkpoint file during proof generation is not so difficult, since only 500MB of RAM were used.
If that's not possible, We could still save the very last iteration of PRP, instead of resuming from 99.97%.

hello, a few questions.

is p95 30.3 v6 the latest builld?

I have built a new CAD box obviously for designing parts. The CAD software forces me to use windows.

It is based upon cheap cpu's on the internet from china. Maybe they produced cheap some years ago couple of hundreds of thousands of magnificent intel cpu's which are for cheap on aliexpress now at 389 dollar or so i bought 2.

Intel Xeon e5-2699 ES 2.1Ghz.

Under full load that gives me 44 cores at 2.0Ghz in practice is what taskmanager reports. hyperthreading turned off.

Now i run a tad older 64 bits version of cllr64 as the latest build just had been compiled for 32 bits.

I run those currently at 38 cores.
p95 of the above build i try give 4 cores. I see first of all it uses affinity to cores - now windows scheduler ain't as bad as linux one there (regrettably for linux) so in my experiments with my chessprog in past that isn't a great plan on windows - but well YMMV.

Anyway in taskmanager i see it eats 7.6% - 7.8% system time whereas cllr64.exe eats at 4 cores 8.4 - 8.6% system time with of course 100% * 4 / 44 = 9.0% being the ideal.

Updating to P95 GUI i have set at 100k iterations. So that reports each few minutes here. The iter time gives a timing of roughly 7700+ seconds, whereas cllr64 possibly with older woltman library crunched it at 6337 seconds. That was by the way with box under full 44 cores load.

And right now theoretically spoken load is at maximum 42 cores. As 38 + 4 = 42.

What do i do wrong here?

The worktodo.txt let me try type it over by hand as the box is not on internet, otherwise i would have no life.

[Worker #1]
PRP=32767,2,6062241,-1
PRP=32767,2,6064449,-1
PRP=32767,2,6069089,-1
PRP=32767,2,6069873,-1

Kind Regards,
Vincent

[QUOTE=diep;586599]hello, a few questions.
is p95 30.3 v6 the latest builld?
[/QUOTE]
No, 30.6 build 4 is more recent, look at this post
[URL="https://mersenneforum.org/showpost.php?p=577159&postcount=256"]https://mersenneforum.org/showpost.php?p=577159&postcount=256[/URL]

[QUOTE=Prime95;577159]30.6 build 4 is ready

Several bug fixes: Torture tests, AVX-512 P+1 on FFT lengths that are a multiple of 7, best 36M FFT selection

Download links:
[B][COLOR="Red"]
Before downloading, make sure prime.spl is uploaded to the server when upgrading from early versions of 30.6. There was a bug in spool file format for versions 30.6b1 and 30.6b2. Version 30.6b4 will have no trouble creating and reading spool files that are compatible with version 30.5 and earlier plus versions 30.6b3 and later.

[/COLOR][/B]
Windows 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v306b4.win64.zip[/URL]
Linux 64-bit: [URL]https://mersenne.org/ftp_root/gimps/p95v306b4.linux64.tar.gz[/URL]
Source code: [URL]https://mersenne.org/ftp_root/gimps/p95v306b4.source.tar.gz[/URL][/QUOTE]

thanks!
very good. other than source doesn't download the other 2 do. Will upgrade and test further.
also seems L3 cache bit overwhelmed here. Am going reduce number of processes cllr64 and give a few more threads to some that might be outside the 55MB L3 cache.

Note it is a v4 processor obviously with FMA3.

30.6 gives much better iteration times indeed! 1.13high to 1.14 ms / iteration.

If i do some math there it's however still whopping slower than cllr64.exe
Very obviously we can explain it by something that causes the system time to be too little it swallows.

It is 7.8 - 8.0% system time now.
That is far less than cllr64.exe shows.

If i see its output it says FFT size 512k. This would be at 8 bytes per double 4MB.
So if we have 2 arrays that's 8MB L3 cache needed possibly. Do i this math wrong?

Now i've got 55MB L3 for each cpu at 22 cores is 2.5MB /core.
This gets run at 4 cores so that's 10MB L3 theoretical seen available

All the other processes also got 4 cores roughly.

So only thing i could think of is priority it runs threads at. Where to modify this setting and to which?

Something is still wrong. Do not know what. Any thoughts?

Possible Error in p95 30.6 build 4?
 

The PRP proof interim resisdues files disapeared after several Test stop - Test continue operations from my m2.NVM SSD. Proof-File is lost unfortunately.
Isn't it better to write the new PRP proof interim resisdues files first (eventually under a other filename, and then rename it to the original filename) before deleting the old one? I don't know exact how the interim resisdues files are written to the filesystem with prime95.

Turning off Game Mode in win10 which i found somewhere in its settings and let's see what it results into...

[B]false alarm[/B] the resisdues files was still saved in the directory of the old version 30.3b6 , that I`ve deleted for a few hours. :sorry: I have recovered the resisdues files with EaseUS Data Recovery.

[QUOTE=moebius;586603]No, 30.6 build 4 is more recent, look at [URL="https://mersenneforum.org/showpost.php?p=577159&postcount=256"]this post[/URL]
[/QUOTE]Or in general, use the [URL="https://mersenneforum.org/showthread.php?t=24607"]reference info,[/URL] for [URL="https://www.mersenneforum.org/showthread.php?t=23900"]prime95[/URL], or [URL="http://www.mersenneforum.org/showpost.php?p=488291&postcount=2"]the list of available software[/URL].
New releases for software often get added to the [URL="https://www.mersenneforum.org/showpost.php?p=570035&postcount=1"]announcements[/URL] page I maintain.