Prime95 30.8 (big P-1 changes, see post #551)

[tha]

I added this line to the worktodo file again and this time it did the B2 part. I have no idea if I somehow misspelled the previous entry or not, and if so, what is was that was entered.

PMinus1=1,2,325133,-1,1000000000,40000000,68

[Mark Rose]

Originally Posted by LOBES

There are never any requests made to retrieve CERT work.

First, I don't understand why it makes the request when using the -m parameter and not the -d. Second, I don't know why my terminal screen is flooded with those Comm thread messages.

In the end, I just want my client to be able to request CERT work, even if none is available.

For what it's worth, I'm able to process and submit CERT work using v308b17 of mprime. I've not seen any of my v308b17 machines request CERT work, though I'm also keeping them stocked with P-1 work at the moment.

[James Heinrich]

Originally Posted by Mark Rose

I've not seen any of my v308b17 machines request CERT work

As discussed in my thread, I've also been having this problem. On a whim I downgraded to v30.8b7 (random earlier version). Clumsily I clobbered my v30.8b15 install, but when I started up b5 it happily requested CERT work, which b15 appears not to do. I'm not sure exactly when, but it seems that the bit of code that requests CERT work stopped working properly sometime between b7 and b15. [edit: later analysis suspects around b13]

[harlee]

James, you're probably already doing this, but have you looked CERT results being returned to see which version is the highest that are returning CERT work?

[James Heinrich]

Originally Posted by harlee

James, you're probably already doing this, but have you looked CERT results being returned to see which version is the highest that are returning CERT work?

I have, see my post here (and perhaps continue relevant discussion in that thread to avoid cross-posting).

[kracker]

A quick read of the documentation didn't result in any answers, so...
I've noticed that the best way for me to run P-1 is by running a worker per core for stage 1, then multithread stage two. Is there a way to automate that somehow? Right now, I just change the worker settings/worktodo when stage one finishes, then switch back when stage two finishes etc... a bit tedious.

[Prime95]

Originally Posted by kracker

A quick read of the documentation didn't result in any answers, so...
I've noticed that the best way for me to run P-1 is by running a worker per core for stage 1, then multithread stage two. Is there a way to automate that somehow? Right now, I just change the worker settings/worktodo when stage one finishes, then switch back when stage two finishes etc... a bit tedious.

No way to do that now. I'm contemplating a new feature that would do this.

[James Heinrich]

A more flexible assignment system would be revolutionary. On my 7950X I need to run 2 workers, and I'm doing mostly P-1, but if I just let them run then I end up with a stage-2 backlog. So I need to throw in some PRP or other not-RAM-using work every now and then, or let both workers fight for stage2 RAM. Also there's the situation where one worker has done all the stage1 work it can while waiting for stage2 RAM to become available, the other worker has some stage1 work (or PRP or whatever) that hasn't been done yet, but the first worker sits idle. A unified work queue for all workers would be amazing. And if a worker runs out of things to do for lack of stage2 RAM it could grab some what-makes-sense-without-RAM worktype (e.g. PRP/DC)

I know this could become complex, but any improvements in this area would be much appreciated.

[nordi]

Originally Posted by kracker

I've noticed that the best way for me to run P-1 is by running a worker per core for stage 1, then multithread stage two.

To make matters worse, this approach is best for small exponents (e.g. for 30k), but not for larger exponents (e.g. 14M).

Originally Posted by Prime95

No way to do that now. I'm contemplating a new feature that would do this.

It would be interesting to hear your thoughts on that topic.

My idea would be to configure Core Groups instead of individual Workers. Each Group is assigned some CPU cores and a Config like this:

[Group #1]
total_cores = 16
stage_1_cores = 1
stage_2_cores = 4

Initially, 16 Stage-1 workers run on 1 core each. They share a common section in worktodo.txt from where they get their jobs.

When a Stage-1 worker in the Group has a result, 4 of the Stage-1 workers are paused. The 4 available CPU cores are now used by another worker doing the Stage-2 work.

Notes:

• When pausing Stage-1 workers, they should be chosen round-robin to avoid starvation.
• The stage_2_cores should not be hard coded to "all cores in the group" to accommodate CPUs with separate chiplets, like current AMD CPUs (or separate core-complexes, like my Zen2 chip).
• I also considered having 1 Group per chiplet, so the stage_2_cores setting wouldn't be needed. But the setup above has the advantage that the Stage-1 workers can provide a steady stream of work to the Stage-2 workers, thus maximizing RAM utilization.

Maybe it would even make sense to have a similar mechanism for ECM and P+1?

[kriesel]

Originally Posted by James Heinrich

A more flexible assignment system would be revolutionary. On my 7950X I need to run 2 workers, and I'm doing mostly P-1, but if I just let them run then I end up with a stage-2 backlog. So I need to throw in some PRP or other not-RAM-using work every now and then, or let both workers fight for stage2 RAM. Also there's the situation where one worker has done all the stage1 work it can while waiting for stage2 RAM to become available, the other worker has some stage1 work (or PRP or whatever) that hasn't been done yet, but the first worker sits idle. A unified work queue for all workers would be amazing. And if a worker runs out of things to do for lack of stage2 RAM it could grab some what-makes-sense-without-RAM worktype (e.g. PRP/DC)

As a stopgap, set days of work to get to something comfortable, like 3-7 days, let it fill that up with PrimeNet-API-obtained P-1 assignments, then append manually obtained PRP/proof as DC for LL, to each worker, which won't expire for weeks or months. If a worker exhausts its stage 1 work, it can do useful work on a DC until big memory becomes available. More manually obtained P-1 can be added in front of the DC from time to time.

[James Heinrich]

Originally Posted by kriesel

As a stopgap

Naturally I can (and do) manage it all manually, but it would be nice to be able to set a machine to "do P-1 unless you run out things to do, then go automatically find something else useful to do" rather than micromanaging. On my other machines I tend to just run one worker and "waste" the available RAM maybe 25% of realtime (stage2 takes a bit longer than stage1, and sometimes Real Work takes RAM precedence via LowMemWhileRunning) rather than micromanage. On my 7950X I need to run 2 workers for chiplet reasons, and when I can't micromanage I just let them fight it out (MaxHighMemWorkers=2) if they both want RAM. Sometimes they're lucky and get all the RAM to themselves, sometimes not.