Prime95 dropping manual assignments from worktodo.txt without completing them?

[pepi37]

Originally Posted by ixfd64

I've noticed a possibly related issue: Pminus1 assignments are being duplicated to other workers. A few months ago, I was going through the logs when I saw some repeated results. At first I thought I made a copy and paste error when adding assignments to my worktodo.txt file, but then I noticed that this is still happening from time to time. In some cases, the duplicated exponent will replace another worker's current exponent.

Anyone else seen this?

I use Prime95 for CRUS bases and other prime search and found similar problem: sometimes Prime95 doesnot process candidate,but it must be connected with next thing: when Prime95 try to write temp file, and if fail twice it will abandon candidate and go to the next, but will also remove unfinished candidate from worktodo.txt

[storm5510]

Is there a hard-coded ceiling in Prime95 which prohibits the number of assignments from going beyond that point?

The reason I ask: I am working on some exponents from James Heinrich's project. I run them with gpuOwl. However, they must first be loaded into the Prime95 'worktodo' file so they will be assigned ID's. Then, the contents can be moved to gpuOwl.

Each runs in seven minutes, more or less. It would take a bit over 200 assignments to run for 24 hours. I have MaxExponents set to 500. The most I have presented to Prime95 for ID's is 40. Would it be safe to say that I could get ID's for 100 which would last for 12 hours? This would prevent the machine from sitting idle during the wee hours of the morning.

[ATH]

You should be able to get hundreds of exponents, but you might need to add this line to prime.txt as well if Prime95 thinks the list of exponents will take a very long time:

UnreserveDays=9999

Normally, the program will unreserve an exponent if it is scheduled to start
thirty days after the Test/Primenet Days of work to get value and there are more
than four exponents queued up for the worker. You can adjust the days interval
by setting in prime.txt:
UnreserveDays=n (default 30)
where n is the number of days. You can also adjust the number of protected
exponents in each worker with this setting in prime.txt:
UnreserveExponents=m (default 4)
where m is the number of protected exponents. You should increase one or both of
these values if you are loading up worktodo.txt with a large amount of work and
do not want any of the work to be unreserved.
WARNING: There have been several reports of a bug in prime95's calculations for
UnreserveDays. Thus, we recommend using UnreserveExponents to prevent unexpected
unreserving of work,

[storm5510]

Originally Posted by ATH

You should be able to get hundreds of exponents, but you might need to add this line to prime.txt as well if Prime95 thinks the list of exponents will take a very long time:

UnreserveDays=9999

Thank you for the reply. I recognize part of the quoted text. It is from undoc.txt.

In the distant past, a somewhat earlier version of Prime95 would refuse to assign ID's to exponent tests at a certain point. Looking back, I probably exceeded the default settings.

[ATH]

Are you running "PRPCF" cofactor tests with gpuowl?

I did not realize gpuowl could do that. Does it accept the work lines directly from Prime95 ?

[petrw1]

Originally Posted by ATH

You should be able to get hundreds of exponents, but you might need to add this line to prime.txt as well if Prime95 thinks the list of exponents will take a very long time:

UnreserveDays=9999

And MaxExponents=999.
I've had several hundred per worker.

[storm5510]

Originally Posted by ATH

Are you running "PRPCF" cofactor tests with gpuowl?

I did not realize gpuowl could do that. Does it accept the work lines directly from Prime95 ?

No, P-1. It can accept P-1 work lines which will run in Prime95. Previous versions were case sensitive regarding "PFactor" vs. "Pfactor" It may run the alternate form, "Pminus1," as well. I cannot remember at the moment, but it should as this is a k*2*n-1 type. "+1" I don't know. Perhaps some experimentation is needed.

The documentation goes over PRP extensively. There saw no mention of cofactor.

[Uncwilly]

Originally Posted by storm5510

The documentation goes over PRP extensively. There saw no mention of cofactor.

PRP-CF is an assignment type that is a good task for old slow machines. No reason to waste the power of a GPU on them. It is a very low priority, because it does nothing to advance the finding of a new MP. It is a short assignment (PRP on exponents under 10,000,000 [less their known factors]). And the turn around time for DC's is quick.

[storm5510]

Originally Posted by Uncwilly

PRP-CF is an assignment type that is a good task for old slow machines. No reason to waste the power of a GPU on them. It is a very low priority, because it does nothing to advance the finding of a new MP. It is a short assignment (PRP on exponents under 10,000,000 [less their known factors]). And the turn around time for DC's is quick.

Old slow machines. I have a Core2Duo on my kitchen table. I have used it for sieving Riesel candidates and it does fairly well with that as the program(s) do not demand much CPU power, basically idle priority. Naturally, I have Prme95 on it and ran some ECM co-factors not so long ago. I will have to try PRP-CF. This machine sat in my bedroom closet wrapped in a black plastic bag so long that forgot what it was, Rediscovering it brought my machine count up to four.