Perhaps this one?

[code]You can skip the GCD in stage 1 of P-1 factoring with this prime.txt setting:
Stage1GCD=0[/code]

[QUOTE=ixfd64;569306]Perhaps this one?
[/QUOTE]

Ah!

Is stage 1 P-1 factoring now supposed to fit completely in the L3 cache? Is that where the speedup came from?

[CODE]top - 05:19:52 up 6:14, 1 user, load average: 63.25, 59.63, 50.47
Tasks: 588 total, 1 running, 587 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.3 sy, 96.6 ni, 3.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 128925.9 total, 127437.0 free, 803.2 used, 685.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 127236.8 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13527 james 30 10 4483612 134276 7880 S 1556 0.1 186:08.48 mprime
13680 james 30 10 4483616 134428 7988 S 1553 0.1 180:02.59 mprime
13834 james 30 10 4483480 133496 7496 S 1551 0.1 174:31.16 mprime
13377 james 30 10 4483480 134888 7636 S 1542 0.1 189:46.74 mprime [/CODE]The prime.log makes no reference to the new version yet.


This is my 4 CPU [URL="https://www.amd.com/en/products/cpu/6272"]Opteron[/URL] system running 4 separate instances (because mprime is not NUMA aware).


Having trouble verifying but I think the L3 cache on that chip is actually 2 8MB caches.


Edit:
Because I was only using half of my L3 cache, I doubled the number of workers per instance.
Got some reassuring messages in prime.log:


[CODE][Fri Jan 15 06:27:57 2021 - ver 30.4]
Exchanging program options with server
Getting assignment from server
PrimeNet success code with additional info:
Server assigned P-1 factoring work.
Got assignment 6914F714740D2AF13BE05BCE07ABA42D: P-1 M102220457
Sending expected completion date for M102220457: Jan 21 2021[/CODE]


Edit: or is the resource usage 135MB, not 135kB?

[QUOTE=phillipsjk;569345]Is stage 1 P-1 factoring now supposed to fit completely in the L3 cache? Is that where the speedup came from?
[/QUOTE]
I think I just got confused about kiB vs byte units. Disadvantage of only running the machine at night is that upgrades happen when I am tired.

I just installed build 6. After a couple of P-1 jobs done I had to cut the internet connectiion to do some rewiring of the electric system in my house. Meanwhile mprime tried to connect to the server every 2 minutes. This while it is set to retry a connection every 70 minutes. I used option 15 to set it to 71 minutes. To no avail, it continued to retry a connection every 2 minutes until the electric system was re-enabled and the internet connection was restored.

[QUOTE=tha;569403]I just installed build 6. After a couple of P-1 jobs done I had to cut the internet connectiion to do some rewiring of the electric system in my house. Meanwhile mprime tried to connect to the server every 2 minutes. This while it is set to retry a connection every 70 minutes. I used option 15 to set it to 71 minutes. To no avail, it continued to retry a connection every 2 minutes until the electric system was re-enabled and the internet connection was restored.[/QUOTE]

Look in prime.txt. You will see two lines:
[CODE]NetworkRetryTime=2
NetworkRetryTime2=70
[/CODE]
I suppose you need to change the first one.

[QUOTE=axn;569422]Look in prime.txt. You will see two lines:
[CODE]NetworkRetryTime=2
NetworkRetryTime2=70
[/CODE]
I suppose you need to change the first one.[/QUOTE]

Hmm. I must have missed the change in that functionality. Probably to be found somewhere in a file with changes from version to version.

What is the ratio behind having a menu option that has no apparent effect even though suggesting so and a hidden feature that requires to delve into the details to do what the menu option suggest to do?

I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.

Or something like that. I don't remember exactly. Maybe George knows.

Regardless, you can manually edit the entry and see if that takes care of things for the future.

[QUOTE=axn;569451]I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.
[/QUOTE]

Ah, that would make sense. Something though that should be documented in the readme or undoc.txt file.

[QUOTE=axn;569451]I believe they are both used, but for different purposes. If there is no internet connectivity, the first parameter is used. If there is internet connectivity, but mersenne.org is down, the second parameter is used.

Or something like that. I don't remember exactly. Maybe George knows.

Regardless, you can manually edit the entry and see if that takes care of things for the future.[/QUOTE]

It might be a good idea to rename the second parameter to [C]ServerRetryTime[/C] or something similar. George, any thoughts?

Using build 6, I'm running ECM on cofactor work on the 8 cores of my AMD 1700X, and since yesterday, every time I start it, it quietly quits after a few minutes of running with no visible error message. It had been running fine for a while so it may be due to the specific exponents it's trying to work on, or maybe the combination of stages they're each on.



This was also occurring on build 5.


The Windows event viewer does log it as an error with the following:
[CODE]Faulting application name: prime95.exe, version: 30.4.1.0, time stamp: 0x5ff269ce
Faulting module name: ntdll.dll, version: 10.0.19041.662, time stamp: 0x27bfa5f0
Exception code: 0xc0000374
Fault offset: 0x00000000000ff0f9
Faulting process ID: 0x4320
Faulting application start time: 0x01d6ecc8686d0967
Faulting application path: D:\Portable apps\Prime\prime95.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: a81e32ea-f964-4056-bbf0-7662f567fc9b
Faulting package full name:
Faulting package-relative application ID: [/CODE]