Prime95 v30.3

[Prime95]

@ath, @uncwilly: I'm trying to reproduce the problem. So far unsuccessfully. If you notice any of the "99"s in worktodo.txt changing let me know -- especially if it correlates with some other activity like a result reported or CERT assignment or whatever.

From uncwilly's description it looks like the corruption of worktodo.txt occurs in 29.8 also (he reported immediate TF work upon upgrading to 30.3). I've stared at the prime95 code and cannot see where it could be happening.

[kriesel]

Originally Posted by Uncwilly

The problem should be fixed, not catered too. We are beta testing. This is a bug. ATH is a big boy and can deal with some bonus TF. My bonus TF did not take to long. But, users should not have to fix the assignments that PrimeNet hands out.

The issue I responded on is not as I understood it with what PrimeNet hands out, but with what PrimeNet makes of what a user manually enters in worktodo.txt, taking the user's input literally, as computers have been known to do for, well, their entire history.
Period instead of a comma, one iteration of a for loop instead of 3, space mission lost, as one example. "For i=1.3" vs. "For i=1,3"

Fixed or catered to is a false dichotomy. George has accepted it as an issue. And subsequent to my post to which you responded as quoted above, it appears to have been a behavior present in 29.8 also, so present for about a year. (Longer?) Unfortunately we only have one George Woltman, and there's a lot to do. And a workaround is useful in the meantime.
It is not best practice to make manual cpu assignments without checking tf level first. Nor to operate with incomplete worktodo records, as that makes the system more fragile.
It's not cost me any cpu tf cycles, although I do a lot of insert PRP=1,2,exp,-1,tf,0 or DoubleCheck=exp,tf,0, to get an assignment/AID. Give the code what it needs, works well.
There are a lot of different cases.
PrimeNet issues the whole worktodo line is one; tries to make sense of what the user entered is another, more complex one.
Client reads incomplete worktodo line, and has worktype PRP, k 1, base 2, exponent exp, c -1, but nothing for tf so 0, tests-saved not entered so 0. No N/A, so client asks server for an assignment matching that during a manual communication.
Maybe the server is too trusting of the client?
Or the client doesn't accept a new tf level returned by the server with the AID, assuming the server goes and looks up the exponent in the database for that case?
George's recent message sounds like the latter. https://www.mersenneforum.org/showpo...2&postcount=55
PRP-CF is moot here since I don't run that, but some people do, and a fix will come eventually.

[Ensigm]

Default P-1/ECM stage 2 memory limit is 0.000000 GB for a fresh install, which will result in stage 2 being deferred (to see this, try testing M1277). Maybe keep the original 8MB as default?

[Uncwilly]

Originally Posted by kriesel

The issue I responded on is not as I understood it with what PrimeNet hands out, but with what PrimeNet makes of what a user manually enters in worktodo.txt,

ATH and I had what appears to be the same issue when upgrading from 29.8 to 30.3 (not 30.1 or 30.2) I had not manually entered those lines in the worktodo.txt. When I submitted the log, I included about a week's worth of data before the oops. This is when some or all of the assignments in question were handed out.

And subsequent to my post to which you responded as quoted above, it appears to have been a behavior present in 29.8 also, so present for about a year. (Longer?)

I never saw any TF work done on a PRP assignment while using 29.8. As noted elsewhere the code for PRP assignments changed to do needed TF. What is useful for the 100M digit range is causing issues with the PRP-CF. We are bug reporting in this thread (as we should be doing). Leaving things in the state that shows the anomalous behaviour can give the data to find the source. To bypass it gives us a less complete data set.

It is not best practice to make manual cpu assignments without checking tf level first. Nor to operate with incomplete worktodo records, as that makes the system more fragile.
It's not cost me any cpu tf cycles, although I do a lot of insert PRP=1,2,exp,-1,tf,0 or DoubleCheck=exp,tf,0, to get an assignment/AID. Give the code what it needs, works well.

Explain to me what I did that was ill advised. I let Prime95 fetch assignments from PrimeNet all normal, no self assignments.

PRP-CF is moot here since I don't run that, but some people do, and a fix will come eventually.

It is not moot. It is an issue. It may be a symptom of some other issue that is a really bad.

[Uncwilly]

Originally Posted by Ensigm

Default P-1/ECM stage 2 memory limit is 0.000000 GB for a fresh install, which will result in stage 2 being deferred (to see this, try testing M1277). Maybe keep the original 8MB as default?

8MB is currently a waste for P-1 or ECM. Unless you can devote ~100MB don't bother with ECM or P-1. 8MB is legacy from the dark ages. LL and PRP use way more than that now.

[Ensigm]

Originally Posted by Uncwilly

8MB is currently a waste for P-1 or ECM. Unless you can devote ~100MB don't bother with ECM or P-1. 8MB is legacy from the dark ages. LL and PRP use way more than that now.

Then there should be a minimum memory for having P-1/ECM as a work preference (manual testing is fine). Otherwise someone will receive the work unit, complete stage 1, and be stranded there.

[Ensigm]

Anyways, 0 MB should not be the default. I downloaded v30 on a testing machine and ran ECM for several hours, and was surprised that no work had been completed. It took me a while to find out that they were all stuck before stage two.

[Prime95]

Originally Posted by Ensigm

Default P-1/ECM stage 2 memory limit is 0.000000 GB for a fresh install, which will result in stage 2 being deferred (to see this, try testing M1277). Maybe keep the original 8MB as default?

I'm increasing the default to 256MB. Perhaps it should be higher (like 512MB or 1/8th of RAM, whichever is less).

[storm5510]

Originally Posted by Uncwilly

8MB is currently a waste for P-1 or ECM. Unless you can devote ~100MB don't bother with ECM or P-1. 8MB is legacy from the dark ages. LL and PRP use way more than that now.

8 MB is not necessarily a waste on ECM's if you want to run small exponents on an old machine. I do it. The memory allocation determines the size of the exponents assigned. 512 MB is the long-standing minimum for P-1. I usually use 1024 (1 GB) or 1536 (1.5 GB). A few times to 3072 (3 GB). Never higher.

[chalsall]

Originally Posted by Prime95

Perhaps it should be higher (like 512MB or 1/8th of RAM, whichever is less).

"What do you need?" - Steven Wright

You already have P-1 specialists, so how much RAM is optimal (but not excessive without explicit authorization) for other work?

[pinhodecarlos]

Think I've joined the PRP-DC-CF party...1 core two threads.