[QUOTE=nordi;570074]I got a crash with build 7 doing ECM work on Linux:
[/quote]

I have not been able to replicate the problem.

[quote]D: 420, relative primes: 48, stage 2 primes: 40421, pair%=182.86[/QUOTE]

I did fix a bug that caused the pairing % to exceed 100.

I use Prime95 for years on my personal, and CRUS search. I like all extra checks ,but can I disable generating proof file, since it will use disk space for nothing,and I dont need to upload proff file to no one.
Thanks

[QUOTE=pepi37;570301]I use Prime95 for years on my personal, and CRUS search. I like all extra checks ,but can I disable generating proof file, since it will use disk space for nothing,and I dont need to upload proff file to no one.
Thanks[/QUOTE]

Try setting the disk space prime95 is allowed to use to zero.

I think it might be better to change prime pairing format from [c]pair%=xx.xx[/c] to [c]pair: xx.xx%[/c] so that it's consistent with the rest of the output line.

There seems to be a problem with fetching work in some cases. I have one of my cores set to get P-1 work, while the others do PRP. When one or more of the PRP tests also want to do a P-1 test before starting, only one stage 2 can run at a time. If the P-1 core is blocked from doing stage 2 it will do stage 1 work on the exponents it has, but if it finishes all of them and still cannot start a stage 2 because of another core, it will stop and wait instead of getting some new work to do.

[QUOTE=1997rj7;570585]it will stop and wait instead of getting some new work to do.[/QUOTE]You can increase [c]DaysOfWork[/c] in prime.txt (or the equivalent GUI setting).

But looking at the broader picture, it might not be a bad idea in a situation like this, if Prime95 can't find anything else to do while waiting for RAM availability, it could start working on the PRP, on the 95% probability that the P-1 test will not find a factor, rather than leaving idle cycles.

Are the ECM B1 and B2 bounds not allowed to be changed from their nominal settings?

I ´ve been using Build 8, and didn´t have a single problem so far. Today I fetched some manual ECM assignments in the 500k range, and the worktodo lines came with the expected values of 250000 / 25000000 for B1 and B2. I changed them to 500000 and 50000000 and restarted Prime95.The program rejected those lines, giving out the message:"Illegal line in worktodo.txt file: ECM2=blablabla". The lines were not deleted from worktodo.txt, though.

Is this the expected behaviour? I /think/ in previous versions one were able to change the bounds at will.

[QUOTE=James Heinrich;570587]But looking at the broader picture, it might not be a bad idea in a situation like this, if Prime95 can't find anything else to do while waiting for RAM availability, it could start working on the PRP, on the 95% probability that the P-1 test will not find a factor, rather than leaving idle cycles.[/QUOTE]

PRP (and LL) are already coded to do this. I'll see if I can replicate the problem.

[QUOTE=lycorn;570601]Is this the expected behaviour? I /think/ in previous versions one were able to change the bounds at will.[/QUOTE]

This is not the expected behavior.

Stable mprime version for the next GPU72 Colab build?
 

Hey.

So, I've had a few requests to upgrade the mprime build sent out in the Payload.

Since several of us are now being given at least a few hours of compute each day, I'd like to program a day for me to do this (along with some other change requests).

George, your counsel? It will be solely doing P-1'ing; and yes, I know about the non-backward compatibility for stage 2... :smile:

I'm modeling next weekend.

[QUOTE=chalsall;570858]
So, I've had a few requests to upgrade the mprime build sent out in the Payload.

Since several of us are now being given at least a few hours of compute each day, I'd like to program a day for me to do this (along with some other change requests).

George, your counsel? [/QUOTE]

30.4 seems stable enough to make the transition. The improved P-1 bounds is worth the effort.