[QUOTE=James Heinrich;587668]Perhaps the better question is why the [url=https://www.mersenne.org/download/]download page[/url] still points to v30.3b6?[/QUOTE]

Good question! I would think that the home page should point to the latest stable version, whether 30.6b4 or a different version.:smile:

[QUOTE=Glenn;587666]though I'm now reading about 30.7 in this thread.[/QUOTE]
IIUC, 30.7 is still WIP with no ETA.

Supposedly with a better stage 2, and possibly integrated P-1 stage 1 with PRP.

Even if it dropped tomorrow, it will be a while before people had a chance to test and find out all the bugs. So we're ways away from 30.7 becoming "official".

I join James H in asking why 30.6 is still not official.

[QUOTE=axn;587672]I join James H in asking why 30.6 is still not official.[/QUOTE]

Several reasons:
1) The benefits are not too great for the average user. A PRP tester will see somewhat faster P-1 stage 2.
2) Upgrading to 30.6b4 will restart P-1 stage 2 from scratch. Let's face it, prior to upgrading most users won't read the fine print that this will happen. Upgrading from 30.6 to 30.7 has the same problem -- let's pay this upgrade frustration only once.
3) On my Linux boxes with no swap area I get occasional crashes during stage 2. The OS gives me the informative error message of "Killed". I suspect mprime is out of memory, but I've no idea why this happens during stage 2 rather than stage 2 init when gobs of memory is allocated.

30.7 is almost ready for some testing. The only feature remaining is Alder Lake support.

[QUOTE=Prime95;587675]Several reasons:
1) The benefits are not too great for the average user. A PRP tester will see somewhat faster P-1 stage 2.
2) Upgrading to 30.6b4 will restart P-1 stage 2 from scratch. Let's face it, prior to upgrading most users won't read the fine print that this will happen. Upgrading from 30.6 to 30.7 has the same problem -- let's pay this upgrade frustration only once.
...
30.7 is almost ready for some testing. The only feature remaining is Alder Lake support.
[/quote]
Fair enough.

[QUOTE=Prime95;587675]I suspect mprime is out of memory, but I've no idea why this happens during stage 2 rather than stage 2 init when gobs of memory is allocated.[/QUOTE]
I have observed this a few times myself. It happens when I fire up something (typically more tabs in my Firefox) which asks for more memory. I don't see any reason why this wouldn't happen with previous versions, except for the fact that the new stage 2 actually can use all available memory across the exponent range.

Prime95 v30.6 b4 Out of Memory crashes
 

Hi,

Want to report that the latter beta 30.6 crashes with Out of Memory which does not happen with 30.3. Have reported this before and I confirm it occurs randomly.

I have 24GB of RAM, and Prime95 30.3 can use 20GB.

For 30.6, I have to set the limit at 16GB and even then it gives an Out of Memory message sometimes. Problem is half the time, Prime95 gets killed - hence I would have to look out when Stage 2 runs. Hope this does not happen in 30.7. Can test if needed.

Kind Regards.

[QUOTE=azhad;588210]I have 24GB of RAM, and Prime95 30.3 can use 20GB.[/QUOTE]

This is very likely a misconfiguration. You are "pushing the edge case" too close to the edge; leave some margin.

How much virtual memory do you have available? Are *any* other programs running which might require unswappable RAM (note: some OSs launch CPU and memory hungry tasks at times)?

And, just for clarity for diagnosing your particular use-case...

Is this Prime95 (WinBlows) or mprime (Linux)? In either/both case(s), please always give the full underlying version of the distribution to assist with the analysis matrix.

On: i7-8750H laptop, 16GB ram, Win10 x64 Home 20H2 build 19042.1165,
with prime95 V30.6b4, I'm running a large-exponent P-1 stage 2. On launch it happily updates progress at about 1 hour intervals. Over time the update interval increases. I've seen it up to about a day. Generally it is a case of heavy swapping to SSD. A full prime95 stop, exit, restart generally clears it up, and it reappears later.
Originally I was running that with 12GB allowed in resource limits, with no such issue. I've cut it back to 10 and it's still happening.
Other loads on the system are a multitab Firefox session (3 Google Colab, and a bunch of other stuff, total 16 tabs);
Task Manager; mfaktc on the discrete GTX 1050 Ti; nothing on the IGP;
Ubuntu 18.04 LTS on WSL1 and Mlucas using nominally 2 cores +HT, but really wildly core-hopping 4 cores as it goes. Also have top running at a slow update rate.

I just pared prime95 back from 10GB allowed to 9, to see if that behaves better.
Something has 27G committed of a 39GB dynamically sized virtual memory, and 15G ram in use per Windows Task Manager.
Ubuntu top indicates Mlucas using only 1% of ram.
Windows Task Manager indicates top ram users are
prime95 8.5 GB
Firefox 0.7 GB
Mlucas 0.15 GB
The rest combined shown in Task Manager does not add up to the other 5+GB; maybe ~1. Firefox fluctuates up to 1GB without me touching it, and prime95's usage varies too.
Windows has a limit of page file size = 3 x ram size, so this system could go to ~60-64GB total virtual size before hitting a hard limit.

On another system with 16GB, multiple GPUs, and Win10 also, I've seen trouble (system crashes upon running out of virtual memory) when pushing above 60GB virtual. Gpuowl can push it over the edge if too many P-1 stage 2 or GCD coincide, even though the stage 2 are happening mostly on the GPUs.

[QUOTE=kriesel;588247]I just pared prime95 back from 10GB allowed to 9, to see if that behaves better.
[/QUOTE]
Try turning off the swapfile.sys and allocating 8GB for your Prime95 (If there are no other applications running on your computer) and see if this happens again.

[QUOTE=Zhangrc;588298]If there are no other applications running on your computer)[/QUOTE]Re-read the post before yours. Firefox Mfaktc WSL Ubuntu Mlucas top Task Manager

prime95 idles lots of cores on a worker during P-1 GCD
 

See attachment. Same will apply to dual-manycore-Xeons and some other configurations.
P-1 during GCD idles all but 1 core of a worker. On a Xeon Phi this may be 64/n -1 or 68/n -1 cores, where n is number of workers. Depending on exponent the duration may be considerable.
Gpuowl handled this situation by running parallel threads, speculatively executing the next P-1 stage or the following PRP while the GCD ran in a separate thread. The factor finding probabilities with normal bounds are such that ~98% of the time the same exponent is involved, it pays off. And if it is a succession of P-1 on different exponents, or following is other type work on different exponents, whatever payoff there is occurs 100% of the time. Perhaps this approach would be productive on hyperthreaded CPUs in prime95 / mprime also. (And Mlucas?)
In the M880M case I was running, it took an hour for a GCD.

Similarly, during preallocation of disk space for the proof residues of an M500M PRP, it took a few minutes while nearly all cores of the worker were idle.

[QUOTE=kriesel;588492]Similarly, during preallocation of disk space for the proof residues of an M500M PRP, it took a few minutes while nearly all cores of the worker were idle.[/QUOTE]

Coordination of the concurrency of processes is a non-trivial problem space.

There are cases where it simply makes sense to go single-threaded. Particularly when IOPS are involved.

Computers are cheap. Talented humans are ***very*** expensive... :smile: