[QUOTE=GP2;493261]Do you have a recent version of gpuOwL? I think recent versions have non-zero shift counts, but the earliest versions didn't.[/QUOTE]


Of course, I mean that it is operational right now, version 3.5

[QUOTE=SELROC;493223]If one computes the same number twice the second time is wasted.[/QUOTE]

Wait, are you yourself reporting the same exponent twice? A self-doublecheck?

[QUOTE=GP2;493267]Wait, are you yourself reporting the same exponent twice? A self-doublecheck?[/QUOTE]


No. It happened to me to report an exponent which I had already reported, but that was by negligence as I didn't clear the results.txt file.

[QUOTE=Prime95;493254]The server is picky. It will not accept as a DC any result that is performed with the same software and same shift count.[/QUOTE]

OK, makes sense, that's an occasionally inconvenient but intended feature for sound reason. Although if there was an fft length difference, or other transform difference it might still be valid as a double check. (GpuOwL has offered -fft M61 integer transform and -fft DP floating transform and others, and with differing ways of handling carries.)

Some versions of software, including gpuOwL not so long ago, only offer zero shift.
Primenet exponent summaries eg [URL]https://www.mersenne.org/report_exponent/?exp_lo=153000031&exp_hi=&full=1[/URL] do not indicate what software was used.
One can guess by user, shift, etc, what software was used. But that info is only available after the other user's run is completed and reported. It was not available back in early February when my gpuOwL run to test fft transform limits with 153000031 was first launched.

Gpu assignments (and unassigned runs) are frequently done manually, not via primenet.
This is required for some software, since there's no primenet support in them and no available helper application to do the equivalent.

If primenet indicated software used on completed primality test assignments, it would be helpful.

A manual reservation would leave primenet with no way of knowing what software will be used or is being used. Someone seeking to select a test exponent and manually reserve a double check, and checking the exponent for any other pending assignments, may have no way of knowing if there will be a software match and shift count match.

Oh well. Certainly a line must be drawn somewhere, about accommodating special cases.

[QUOTE=kriesel;493281]OK, makes sense, that's an occasionally inconvenient but intended feature for sound reason. Although if there was an fft length difference, or other transform difference it might still be valid as a double check. (GpuOwL has offered -fft M61 integer transform and -fft DP floating transform and others, and with differing ways of handling carries.)

Some versions of software, including gpuOwL not so long ago, only offer zero shift.
Primenet exponent summaries eg [URL]https://www.mersenne.org/report_exponent/?exp_lo=153000031&exp_hi=&full=1[/URL] do not indicate what software was used.
One can guess by user, shift, etc, what software was used. But that info is only available after the other user's run is completed and reported. It was not available back in early February when my gpuOwL run to test fft transform limits with 153000031 was first launched.

Gpu assignments (and unassigned runs) are frequently done manually, not via primenet.
This is required for some software, since there's no primenet support in them and no available helper application to do the equivalent.

If primenet indicated software used on completed primality test assignments, it would be helpful.

A manual reservation would leave primenet with no way of knowing what software will be used or is being used. Someone seeking to select a test exponent and manually reserve a double check, and checking the exponent for any other pending assignments, may have no way of knowing if there will be a software match and shift count match.

Oh well. Certainly a line must be drawn somewhere, about accommodating special cases.[/QUOTE]




Absolutely. Doing manual testing with gpuOwl. I heard there are plans to include primenet automatic assignment in gpuOwl, but for now only manual work of reporting results is available. At this time gpuOwl falls under the "untrusted software" category for primenet.

[QUOTE=SELROC;493287]Absolutely. Doing manual testing with gpuOwl. I heard there are plans to include primenet automatic assignment in gpuOwl, but for now only manual work of reporting results is available. At this time gpuOwl falls under the "untrusted software" category for primenet.[/QUOTE]
I'm not sure what you mean by untrusted software, but if it has to do with the prime95/mprime style security module, all gpu applications fall in that untrusted category.

I've looked at the primenet API, and it seems to me well suited to cpu-based applications, and less well suited to gpu applications. When describing the processing capability, which of a system's collection of heterogenous gpus' properties should be given to the primenet server? Which of the attributes of the several kinds of memory for a given gpu?

These questions and trusted vs. untrusted arise, whether implementing integral Primenet support in any given gpu application, or in a single helper application that could connect the several popular gpu applications.

I have such a helper app in development, and am using it continuously on one of my systems, for several running gpu apps. It does periodic status checks on the apps, results gathering, and error screening. (Adding more log file parsers, worktodo parsers, and results file format support, one each per application type, was straightforward.) Currently it concentrates results from multiple gpu applications into a single newresults file that can be more quickly manually reported. It might get an interface to the manual reporting page instead of or before primenet. (But progress updates of gpu apps to primenet would be ideal.) The next thing I want to add is queued work run time estimation. That's particularly not simple for CUDAPm1 (even for exponents that don't crash it). It's also a necessary piece of knowing when to add more to the worktodo. Some apps implement worktodoadd, and some don't. Some provide date and time stamps, and some don't. One of these months...

[QUOTE=kriesel;493322]I'm not sure what you mean by untrusted software, but if it has to do with the prime95/mprime style security module, all gpu applications fall in that untrusted category.

I've looked at the primenet API, and it seems to me well suited to cpu-based applications, and less well suited to gpu applications. When describing the processing capability, which of a system's collection of heterogenous gpus' properties should be given to the primenet server? Which of the attributes of the several kinds of memory for a given gpu?

These questions and trusted vs. untrusted arise, whether implementing integral Primenet support in any given gpu application, or in a single helper application that could connect the several popular gpu applications.

I have such a helper app in development, and am using it continuously on one of my systems, for several running gpu apps. It does periodic status checks on the apps, results gathering, and error screening. (Adding more log file parsers, worktodo parsers, and results file format support, one each per application type, was straightforward.) Currently it concentrates results from multiple gpu applications into a single newresults file that can be more quickly manually reported. It might get an interface to the manual reporting page instead of or before primenet. (But progress updates of gpu apps to primenet would be ideal.) The next thing I want to add is queued work run time estimation. That's particularly not simple for CUDAPm1 (even for exponents that don't crash it). It's also a necessary piece of knowing when to add more to the worktodo. Some apps implement worktodoadd, and some don't. Some provide date and time stamps, and some don't. One of these months...[/QUOTE]




I refer to the Status field in the "View your CPUs" page. It shows U for manual testing, this means the software for manual testing is untrusted.

[QUOTE=SELROC;493287]Absolutely. Doing manual testing with gpuOwl. I heard there are plans to include primenet automatic assignment in gpuOwl, but for now only manual work of reporting results is available. At this time gpuOwl falls under the "untrusted software" category for primenet.[/QUOTE]

And: if there is an existing LL result, a PRP assignment can not (in a test just now) be reserved for the same exponent. A separate algorithm (PRP vs LL), particularly run on a separate architecture (gpu vs cpu), and implemented by separate software (gpuOwL vs prime95 or CUDALucas), seems to me a stronger double check of primality than same software, same architecture, same algorithm, even ignoring the stronger error checking in the PRP.

[QUOTE=kriesel;493329]And: if there is an existing LL result, a PRP assignment can not (in a test just now) be reserved for the same exponent. A separate algorithm (PRP vs LL), particularly run on a separate architecture (gpu vs cpu), and implemented by separate software (gpuOwL vs prime95 or CUDALucas), seems to me a stronger double check of primality than same software, same architecture, same algorithm, even ignoring the stronger error checking in the PRP.[/QUOTE]

Your argument is correct if we're verifying a prime. For verifying a composite, it is not. Because, now you don't have two results that match. Both could be wrong, and you wouldn't know it [Granted PRP w/ GEC is strong enough all on its own, but the principle still stands]

[QUOTE=SELROC;493325]I refer to the Status field in the "View your CPUs" page. It shows U for manual testing, this means the software for manual testing is untrusted.[/QUOTE]


And manual testing does not show which software is being used. This, can be very easy to resolve with a drop-down menu list of allowed software for the user to select each time an exponent is assigned for manual testing.


The history of all software used for an exponent (if the user changes software in mid computation) should be written in the results file or in checkpoint files.

[QUOTE=SELROC;493350]
The history of all software used for an exponent (if the user changes software in mid computation) should be written in the results file or in checkpoint files.[/QUOTE]That is included in the Mersenne Neutral Exchange format draft standard.