gpuOwL: an OpenCL program for Mersenne primality testing

[ATH]

How do you specify PRP type in gpuOwL ?

Just finished my first gpuowl test using Google Colab, but it was a PRP DC and forgot to think of the PRP type, so it finished the wrong type:
https://mersenne.org/M87000929

I found a type 1 result to DC for the next one, so that should be ok, but how do I choose the type? It is fixed in the different versions which type it uses?

Could I continue from the last savefile of 87000929 and finish it as a type 4 if the difference
between types is only at the end?
According to undoc.txt from Prime95:
type 1: a^(n-1)
type 4: a^((n+1)/2)

[kracker]

Originally Posted by ATH

How do you specify PRP type in gpuOwL ?

Just finished my first gpuowl test using Google Colab, but it was a PRP DC and forgot to think of the PRP type, so it finished the wrong type:
https://mersenne.org/M87000929

I found a type 1 result to DC for the next one, so that should be ok, but how do I choose the type? It is fixed in the different versions which type it uses?

Could I continue from the last savefile of 87000929 and finish it as a type 4 if the difference
between types is only at the end?
According to undoc.txt from Prime95:
type 1: a^(n-1)
type 4: a^((n+1)/2)

Pretty sure the prp type is hard fixed, but gpuowl has changed types several times in the past... Savefiles, I'm not sure.

Originally Posted by storm5510

I have two caveats:

#1: The screen writes could to be more frequent. It appears to be 10,000 iterations, or 10,000 something. With my vision being what it is, I walk by the screen and wonder if it is still running, or if it has frozen. Allow the user to decide by making this a config.txt option. Being an antique programmer, I understand there may be some effort involved.

#2: For every exponent ran, a folder containing checkpoint information is created, but not deleted after completion of the test. The housekeeping could be better.

Other than these, I feel gpuOwl does a really good job. I have only ran P-1's with it. Stage 2 is far faster than any of the other programs I have used.

#1- You can use -log... but it's the opposite to what you want, it slows down the output to a multiple of 10000(last i recall)... If you use windows, you can get something like GPU-Z to see gpu usage percentages- to see if it's actually working the gpu...

#2- So much yes... I run gpuowl from google drive and running P-1 I run out of space so fast and have to manually delete them.... I realize I can make a script... whenever I feel like it

[storm5510]

Originally Posted by kracker

#1- You can use -log... but it's the opposite to what you want, it slows down the output to a multiple of 10000(last i recall)... If you use windows, you can get something like GPU-Z to see gpu usage percentages- to see if it's actually working the gpu...

The output is in multiples of 10,000 now so there is not much point of messing with that.

It is working the GPU, to a point. I have an gadget, image snip below, that sits in the upper-right corner of the screen. It displays the GPU temperature, among other things. Idle is around 30°C. GPU-Z says a 100% load. The GPU temperature shown in the gadget is with gpuOwl running on a large P-1.

[LaurV]

Originally Posted by R. Gerbicz

And have you ever found a mismatch in the residues?

Not with the new Gerbicz/PRP tests. I will let you know for sure! hehe.... But currently, I still use the ol'good cudaLucas with no such improvements, and with residue as part of the file name, and use a batch to check, and yes, sometimes cosmic rays have bad habit of nesting exactly inside of my computers! In that case, both instances will retry from the last good checkpoint. See my posts about M666666667 here around, which had to resume few times during the test.

[preda]

Originally Posted by ATH

How do you specify PRP type in gpuOwL ?

It's not settable, it depends on the version. The current version is type-1, and there aren't plans to change that anymore.

Could I continue from the last savefile of 87000929 and finish it as a type 4 if the difference
between types is only at the end?
According to undoc.txt from Prime95:
type 1: a^(n-1)
type 4: a^((n+1)/2)

They may be compatible. You're right the change between types is only at the end, but there are small differences between savefile (unrelated to type). Anyway, if gpuowl can't load the savefile it won't (i.e. it's safe to try); it may also be possible to manually "massage" the savefiles carefully, but probably not worth the effort. Not too risky for data corruption in the process as it is validated on load.

PS: all GpuOwl's savefile have a text header of *one line*, followed by binary. E.g. on Linux you can see the header like this:
head -1 savefile.owl
If the binary part is perfectly preserved, the text header could be altered, but the editor would need to not mess around with the binary.

[ATH]

Which version was the last to use type 4 ?

This is a problem for future PRP DC, that people need specific knowledge to be able to DC them.
I should have been experienced enough to think about this, but I forgot. Many other users will not even know about the different types.

I assume Prime95/mprime can DC gpuowl results if the type is the same? Hopefully primenet sets type 4 automatically when needed.

[ATH]

Anyone with an old working gpuowl version that uses type 4 PRP tests want to try and finish this test as a type 4?
http://mersenne.org/M87000929

I have the savefiles after 86750000 and 87000000 iterations.

[Prime95]

@preda: Any particular reason the -block command line argument is no longer available?

[Prime95]

@preda; ./gpuowl -pm1 2000003

fails

[preda]

Originally Posted by Prime95

@preda; ./gpuowl -pm1 2000003

fails

Thanks, I just fixed a problem with a timer, which was causing too frequent saves (in P-1). Other than that (rather severe problem), it seems to run correctly. How was it failing for you? is it still failing?

[preda]

Originally Posted by Prime95

@preda: Any particular reason the -block command line argument is no longer available?

I re-enabled it for now, as I think I don't have a very strong reason to disable it yet.

I think that a block-size of 400 is a rather nice and overall good value (note, this is a bit smaller than the old default of 500). Why do you need a custom block-size, and to what value do you usually set it to?

As I have 2 GPUs (an XFX and an Asrock) that sometimes generate errors (about 1-2 per day), I come to appreciate a smaller block size, and I added a bit of logic to adaptivelly vary the default check-step depending on the number of errors up to now, by starting with a check-step of 200'000, and roughly halving it for each additional error up to 20'000.

And there is one more reason for the smallish block-size: relative to the PRP-proof (future), the plan right now is to have the proof cover (for exponent E) a region from beginning up to an iteration that is a multiple of 1024 * block-size (such that any halving step in this region hits a block-size boundary and can be checked). This leaves a "tail" of up to 1024 * blockSize iterations at the end that are not covered by the proof, and that will need to be re-run by the checker, thus it's good for the tail to not be too large.