Things that make you go hmm, concerning gpuowl runs

[ATH]

Originally Posted by storm5510

Having a factor, I don't understand how this could be considered a "first-time" test. The more I think about all of this, the more my head hurts.

First-time test on cofactors after a new factors is found, compared to double checking the same results afterwards (which is not needed anymore if proof files are used).

But PRP-CF and PRP-CF-DC tests are not part of GIMPS main project of finding Mersenne Primes. It is a side project to test if the cofactors are PRP or if there are more factors to be found on those Mersenne numbers, like the side projects ECM on Fermat numbers or ECM on small Mersenne numbers.

[storm5510]

Originally Posted by kriesel

https://www.mersenne.ca/exponent/10516021 shows the factor has k=15. That was found so easily that it was probably found very long ago, and it may predate GIMPS and record keeping of trial factoring levels completed per exponent, or any organized system of assignments / reservations.

Another way the situation may occur, is that old factoring gets removed from the database to manage the database size. See the note about that at the bottom of any https://www.mersenne.org/results/ output:

*Count does not include any results reported to the old v4  server. Also, to keep the database size down, some TF-LMH result lines  are deleted before 365 days pass. Any factors found, trial factoring  limits, and CPU credits are remembered, but the result lines will not  appear in the table above or appear in the count of total results for  the last 365 days.

(Some people mistakenly believe that the absence of listing a bit level of TF such as in an exponent report means it was skipped, and redo it. Please everyone, don't do that. Duplication of TF already completed is not productive.)

As to why PRP-CF is called a first-time test, it's the first time the cofactor is primality tested. This is the same terminology and similar sequence as for an exponent with no factor found. The usual order when searching for Mersenne primes is TF up to a stopping point, if no factor found yet, run a P-1, if no factor found yet, then a first primality test, then eventually a double check of the primality test, or now a Cert of the proof.

The cofactor being tested for primality in PRP-CF is whatever is left after dividing the Mersenne number by the known factors. See for example https://www.mersenne.org/report_expo...0516361&full=1 (the only PRP-CF I've run.)
Or definition of cofactor, #11 of https://www.mersenneforum.org/showpo...65&postcount=3
PRP of a cofactor does not help find new Mersenne primes. It may aid in further factoring of composite Mersenne numbers, which some people like. See https://www.mersenneforum.org/showth...810#post555810

I thank you for your patience.

As much TF data as there is flowing into Primenet every hour, keeping it for a year has to be a challenge. I try to stay away from it if I can. The older data being removed is why I didn't see anything on that particular exponent.

Something I noticed. The PRP assignments Prime95 reserves as it runs have a shorter format than manual reservations. A manual I got has ",99,0,3,0," where the automatics do not. I looked at assignment element breakdown you posted. Prime95 must not need these things as they are automatic for it.

So, I am running PRP-CF's with v30.3 Build 5, and P-1's with the latest gpuOwl. Why CF's one might ask? Many users do not like to run them, and I feel I do not have the CPU horsepower to run the large ones.

[preda]

Originally Posted by storm5510

If gpuOwl is not built to run CF tests then it needs to be plainly stated in the "readme" document included with each build archive. A person should not have to go digging around on the web to find such information.

I will ignore the "barbs" above and say that I will not belabor this any longer. I will stick with P-1, while it lasts. Once P-1 is gone, then I do not know what will come after. Perhaps nothing.

Sorry I'm a bit late to this discussion, but yes I confirm GpuOwl does not handle PRP-CF. It's a mishap that the assignment form for a PRP-CF is accepted instead of being clearly rejected outright, something I plan to fix.

On the positive side, did you consider doing first-time PRP? arguably they are more useful than PRP-CF.

[storm5510]

Originally Posted by preda

Sorry I'm a bit late to this discussion, but yes I confirm GpuOwl does not handle PRP-CF. It's a mishap that the assignment form for a PRP-CF is accepted instead of being clearly rejected outright, something I plan to fix.

On the positive side, did you consider doing first-time PRP? arguably they are more useful than PRP-CF.

I wondered where you were. I suppose you could simply filter by exponent size. Nothing smaller than 50-million, for example. The Exponent Status Distribution map on mersenne.org shows a lot of DC work at, and above, 53-million.

Have I considered doing first-time PRP? Not really. I do not want to spend a week, or more running a single exponent. If I could snag something at the bottom end of what is available, I might as a DC. Primenet lists them two different ways on the manual reservation page. "Double-check LL tests" and "Double-check PRP tests."

========

I just reserved a LL-DC which is just above 57-million. gpuOwl indicates it will take 39 hour to complete. I can live with that.

While you're reading this, I want you to know that I have a really big peeve with gpuOwl, the screen update interval. It is way too long, for my suit anyway. Having an entry in "config.txt" where a user could set the interval, like Prime95, this would be really nice...

[preda]

Originally Posted by kriesel

This was a power 8 proof PRP run on Radeon 5700XT and Windows 10 that went awry. Aside from the reported checksum error, I see a few additional issues with this run sequence.

Still the core problem above is *why* did the write of the residue fail (and produce a checksum mismatch), thus not allowing to use the power=8. The "fallback" of proof power, with its imperfections, was not really designed as a fallback but more as a way to discover what power did the user specify in case it was different from 8.

We are considering an evolution of the proof format (v2), and I'll think about it in that context; but I don't plan to change the existing format.

[preda]

Originally Posted by storm5510

While you're reading this, I want you to know that I have a really big peeve with gpuOwl, the screen update interval. It is way too long, for my suit anyway. Having an entry in "config.txt" where a user could set the interval, like Prime95, this would be really nice...

try

-log <N>

can be put in config.txt

[kriesel]

Originally Posted by storm5510

I just reserved a LL-DC which is just above 57-million. gpuOwl indicates it will take 39 hour to complete. I can live with that.

the screen update interval. It is way too long, for my suit anyway. Having an entry in "config.txt" where a user could set the interval, like Prime95, this would be really nice.

gupowl -h generates help output. It includes the following

-log <step>        : log every <step> iterations. Multiple of 10'000.

help output is included in every Windows build .7z file I post, since I don't remember when. I put a copy in every working folder, for ready reference.

As I recall, Preda has been working on making P-1 more efficient.

LLDC is always welcome, especially below ~57.885M.

[storm5510]

Originally Posted by kriesel

gupowl -h generates help output. It includes the following

-log <step>        : log every <step> iterations. Multiple of 10'000.

help output is included in every Windows build .7z file I post, since I don't remember when. I put a copy in every working folder, for ready reference.

As I recall, Preda has been working on making P-1 more efficient.

LLDC is always welcome, especially below ~57.885M.

Outputs are now < 30 seconds apart at 10,000. Much better than 5 minutes. I look at all the documents with each release. I don't recall seeing this in any of them. Most of the other GPU programs have the "-h" help option. I should have known, or tried, at least.

I've always felt gpuOwl did a good job with P-1. Stage 2 seems a bit sluggish, but I know why. VRAM. 1080's have 8GB. If I go above 6.5, I start getting screen artifacts. Some elements, like buttons on web pages, lose their transparency. They appear as square blocks when they should appear rounded on the corners. I imagine the designers never thought these cards would be used for anything other than gaming.

[kriesel]

Gpuowl-win v6.11-340-g41d435f on gtx1050Ti and Intel I7-8750H, M139000019 PRP with proof, approx 37 days run with no GEC errors.

2020-09-11 05:57:39 peregine/gtx1050Ti 139000019 OK 138990000  99.99%; 22954 us/it; ETA 0d 00:04; 7ab69061f3c26263 (check 9.86s)
2020-09-11 06:01:38 peregine/gtx1050Ti 139000019 OK 139000000 100.00%; 22952 us/it; ETA 0d 00:00; a6a3abfc4762a2bd (check 9.69s)
2020-09-11 06:01:39 peregine/gtx1050Ti CC 139000019 / 139000019, fd86019f31e6____
2020-09-11 06:01:39 peregine/gtx1050Ti proof: save residue @ 139000064
2020-09-11 06:01:58 peregine/gtx1050Ti 139000019 OK 139000400 100.00%; 26920 us/it; ETA 0d 00:00; c535b7cebd01e5da (check 9.78s)
2020-09-11 06:01:58 peregine/gtx1050Ti {"status":"C", "exponent":"139000019", "worktype":"PRP-3", "res64":"fd86019f31e6____", "residue-type":"1", "errors":{"gerbicz":"0"}, "fft-length":"7864320", "program":{"name":"gpuowl", "version":"v6.11-340-g41d435f"}, "user":"kriesel", "computer":"peregine/gtx1050Ti", "aid":"3061FC342941433195EA4620C419____", "timestamp":"2020-09-11 11:01:58 UTC"}
2020-09-11 06:03:26 peregine/gtx1050Ti proof: building level 1, hash 1e0f6510e0f731__
2020-09-11 06:03:28 peregine/gtx1050Ti proof: building level 2, hash 1be18d2eee5f67__
2020-09-11 06:03:32 peregine/gtx1050Ti proof: building level 3, hash 7c9434d64e1f1e__
2020-09-11 06:03:41 peregine/gtx1050Ti proof: building level 4, hash 51a1ee7f9d309d__
2020-09-11 06:03:59 peregine/gtx1050Ti proof: building level 5, hash 5393da0317b2f8__
2020-09-11 06:04:38 peregine/gtx1050Ti proof: building level 6, hash 7122dda94e1162__
2020-09-11 06:05:57 peregine/gtx1050Ti proof: building level 7, hash ed1da1557f99bb__
2020-09-11 06:08:41 peregine/gtx1050Ti proof: building level 8, hash 620c5ba7ec0fe4__
2020-09-11 06:14:05 peregine/gtx1050Ti PRP-Proof 'C:\Users\kkrie\Documents\gpuowl-v6.11-340\139000019\139000019-8.proof' generated
2020-09-11 06:14:06 peregine/gtx1050Ti worktodo.txt line ignored: "Doublecheck=181000033"
2020-09-11 06:14:06 peregine/gtx1050Ti Bye

Doublecheck should have been DoubleCheck.
Result line lacked an MD5 value, and has been reported. Log result line above also lacks it.
It looks like it did not record an MD5 when generating the proof, perhaps getting derailed by the error with the following worktodo line.
So then the PrimeNet server refuses the proof file upload for M139000019. Its MD5 does not match the null value the server has.
Using the standalone uploader:

MD5 of 139000019-8.proof is 837e4c2e3dbd438f2cbc44f6ed0e____
Proof file exponent is 139000019
Filesize of 139000019-8.proof is 156375085
Server response missing URLToUse: {"error_status":401,"error_message":"Unauthorized","error_description":"JSON result not yet submitted by your user ID or proof file MD5 mismatch"}

Remove the proof file from the worker's directory tree (it's saved on the uploader system). Reconstruct the worktodo entry. Stop LLDC (takes 5.5 minutes for Jacobi check). Retry from last saved M139M files, going up to 139000000.
Rebuilding the proof takes another 13.5 minutes.
There's still no md5 value in the results.txt line.
Is this a known issue with gpuowl-v6.11-340? Note that it outputs a result line before beginning to build the proof, so would not have an MD5 value to attach yet. And does not go back and attach or insert or log one later.
If I update to a later version and coax out an MD5 value during proof reconstruction, I won't be able to get the server to accept it, because there's already a zero offset result logged without an MD5. I doubt it would accept two result submissions for the same AID either. And I would not want it to double credit GhzDays. Nor have a proof go to waste.

[kriesel]

Originally Posted by kriesel

If I update to a later version and coax out an MD5 value during proof reconstruction, I won't be able to get the server to accept it, because there's already a zero offset result logged without an MD5. I doubt it would accept two result submissions for the same AID either. And I would not want it to double credit GhzDays. Nor have a proof go to waste.

Well, it turns out the server is not quite that discriminating. It accepted a result line generated from v6.11-380 during a retry complete with MD5, gave prp computing credit again, per my results summary, and then accepted the upload of the proof produced from v6.11-340. Madpoo or George are welcome to remove the initial report and one of the two PRP test computing credits from M139000019; it's the same run, except for the last few hundred iterations and modest proof computations. (Sort of a two-headed snake.)
Ben Delo is on the case with a PRP proof certification.

[Prime95]

The server was recently modified to accept two results with the same shift count if one was without proof and one was with proof.

The server was also recently modified to reject proof uploads where the JSON result does not report an MD5 proof value. I believed those early July gpuowl executable runs were all completed.