[QUOTE=tServo;507454]Does this mean that gpuowl shouldn't do any first-time PRP tests;
or only avoid using it to check previous PRP tests done with PRIME95 ?[/QUOTE]
I've done dozens of gpuowl runs, and all result lines indicate type 1, so it's fine.
(Perhaps you're confusing PRP residue type with primenet assignment type?)
As far as I know, gpuowl has been producing type 1 PRP residues since V1.5.
(see [URL]http://www.mersenneforum.org/showthread.php?t=22204[/URL] post 223
"- the final residue is now of "type-1" (the preferred standard).")

[QUOTE=kriesel;507478]I've done dozens of gpuowl runs, and all result lines indicate type 1, so it's fine.
(Perhaps you're confusing PRP residue type with primenet assignment type?)
As far as I know, gpuowl has been producing type 1 PRP residues since V1.5.
(see [URL]http://www.mersenneforum.org/showthread.php?t=22204[/URL] post 223
"- the final residue is now of "type-1" (the preferred standard).")[/QUOTE]

I must be missing something. Here are my latest results using gpuowl v5.0 dated 11-4-2018 which I downloaded. Is it just that the heading is wrong?
Also, why are the last 2 digits of the residue missing in the "exponent status" display?

{"exponent":"86810699", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-01-23 08:29:14 UTC", "aid":"5E5B0C8D38FF03361B123FA98191C9B2", "fft-length":5242880, "res64":"f4c12cd3eaa3be__", "residue-type":4}

{"exponent":"86810701", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-01-28 02:07:33 UTC", "aid":"B337AD3213BB3C0D5F9E51F1824CE842", "fft-length":5242880, "res64":"9484caaa125786__", "residue-type":4}

{"exponent":"87001021", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-02-01 20:03:18 UTC", "aid":"32F453E1D477C2DC78045759CF44FDA2", "fft-length":5242880, "res64":"9fd829308e4595__", "residue-type":4}

[QUOTE=R. Gerbicz;507449]Interesting, and have you used the error checking at PRP tests? At the non-triple checked exponents we can see that "Unverified (Reliable)", thought that you get this only when you have used the error checking.[/QUOTE]

I've been meaning to scrutinize the PRP code to reduce chances for a bad Gerbicz PRP result. We know Gerbicz error checking will catch all errors during the squaring process. However, there are intervals without robust error checking (reading / writing save files, transitions from one Gerbicz block to the next, processing the final residue, etc).

Nonetheless, this batch of bad PRP residues is disconcerting.

[QUOTE=tServo;507483]I must be missing something. Here are my latest results using gpuowl v5.0 dated 11-4-2018 which I downloaded. Is it just that the heading is wrong?
Also, why are the last 2 digits of the residue missing in the "exponent status" display?

{"exponent":"86810699", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-01-23 08:29:14 UTC", "aid":"5E5B0C8D38FF03361B123FA98191C9B2", "fft-length":5242880, "res64":"f4c12cd3eaa3be__", "residue-type":4}

{"exponent":"86810701", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-01-28 02:07:33 UTC", "aid":"B337AD3213BB3C0D5F9E51F1824CE842", "fft-length":5242880, "res64":"9484caaa125786__", "residue-type":4}

{"exponent":"87001021", "worktype":"PRP-3", "status":"C", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2019-02-01 20:03:18 UTC", "aid":"32F453E1D477C2DC78045759CF44FDA2", "fft-length":5242880, "res64":"9fd829308e4595__", "residue-type":4}[/QUOTE]You're right, PRP type varies by gpuowl version or run type. I run mostly v3.8 because it's faster on my hardware than v5.0 and nearly all other versions I've checked. (some 3.x are indistinguishable speed; haven't tried 6.x yet.) V3.8 is doing type 1; V4.3 and 5.0 are doing type 4 or PRP-1.
[CODE]{"exponent":1257787, "worktype":"PRP-3", "status":"P", "program":{"name":"gpuowl", "version":"3.8-91c52fa-OpenCL"}, "timestamp":"2018-11-01 22:18:22 UTC", "user":"kriesel", "computer":"condorella-rx480", "aid":"0", "residue-type":1, "fft-length":"512K", "res64":"0000000000000001", "errors":{"gerbicz":0}}
[/CODE] [CODE]{"exponent":"1257787", "worktype":"PRP-1", "status":"P", "program":{"name":"gpuowl", "version":"4.3-537c681"}, "timestamp":"2018-11-02 14:33:09 UTC", "aid":"0", "res64":"62dc0af77c7b5e45", "base":{"b1":"200", "bias":{"2":19}, "res64":"62dc0af77c7b5e45"}}
{"exponent":"1257787", "worktype":"PRP-3", "status":"[COLOR=Red][B]C[/B][/COLOR]", "program":{"name":"gpuowl", "version":"4.3-537c681"}, "timestamp":"2019-02-02 22:30:04 UTC", "res64":"fffffffffffffffc", "residue-type":4}
[/CODE][CODE]{"exponent":"82589933", "worktype":"PRP-3", "status":"P", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2018-12-26 20:15:41 UTC", "aid":"0", "fft-length":4718592, "res64":"fffffffffffffffc", "residue-type":4}
{"exponent":"6972593", "worktype":"PRP,P-1", "status":"P", "program":{"name":"gpuowl", "version":"5.0-9c13870"}, "timestamp":"2018-11-04 23:11:49 UTC", "aid":"0", "fft-length":393216, "res64":"bc16906ca9e08ff7", "b2":"1440000", "base":{"b1":"80000", "bias":{"2":19}, "res64":"bc16906ca9e08ff7"}}[/CODE]


[url]https://www.mersenneforum.org/showpost.php?p=496446&postcount=694[/url] says PRP-1 can only produce type 4 residues.
What I observed with a single run was V4.3 produced a type 4 residue even when P-1 is not involved.

See also [url]https://www.mersenneforum.org/showpost.php?p=468378&postcount=209[/url]
I don't know if V6 returns to the preferred standard type 1 residue.

[QUOTE=ATH;507404]Do you use the newest BIOS version for your system?

I can see the i7-8750H processor is from Q2 2018, long after the Skylake flaw that was found in January 2016 with M49, but just in case it is some similar issue?[/QUOTE]

Yes

[QUOTE=Prime95;507492]However, there are intervals without robust error checking (reading / writing save files, transitions from one Gerbicz block to the next, [B]processing the final residue[/B], etc).[/QUOTE]

I think the last one is the only one that really matters.

[QUOTE=tServo;507483]I must be missing something. Here are my latest results using gpuowl v5.0 dated 11-4-2018 which I downloaded. Is it just that the heading is wrong?
Also, why are the last 2 digits of the residue missing in the "exponent status" display?[/QUOTE]

Please edit your post to remove the full residues. It's because residues need to match to confirm the result, so they're masked publicly until confirmed. We want to make sure the test was actually run to completion, not just phonied up because someone copied/pasted. I thought everyone understood that but this is a good reminder to all.

Not that it's applicable in this case, but also make sure not to post the assignment IDs. Not really much someone could do with those but they might monkey around and check in a result using your assignment, or it would be possible to cancel your assignment using that if someone were determined (not trivial, but without the assignment ID itself it wouldn't even be possible).

[QUOTE=Madpoo;507527]Please edit your post to remove the full residues. It's because residues need to match to confirm the result, so they're masked publicly until confirmed. We want to make sure the test was actually run to completion, not just phonied up because someone copied/pasted. I thought everyone understood that but this is a good reminder to all.

Not that it's applicable in this case, but also make sure not to post the assignment IDs. [U]Not really much someone could do with those but they might monkey around and check in a result using your assignment, or it would be possible to cancel your assignment using that if someone were determined [/U](not trivial, but without the assignment ID itself it wouldn't even be possible).[/QUOTE]
Some folks must be really hard up for entertainment. It is sad, but true, that key identifiers should be withheld or truncated.

[QUOTE=tServo;507454]Does this mean that gpuowl shouldn't do any first-time PRP tests;
or only avoid using it to check previous PRP tests done with PRIME95 ?[/QUOTE]
gpuowl shouldn't do any PRP DC unless you are careful to match the PRP type by manually picking the exponents to suit whatever type your gpuowl build does.

[QUOTE=Madpoo;507527]Please edit your post to remove the full residues. It's because residues need to match to confirm the result, so they're masked publicly until confirmed. We want to make sure the test was actually run to completion, not just phonied up because someone copied/pasted. I thought everyone understood that but this is a good reminder to all.

Not that it's applicable in this case, but also make sure not to post the assignment IDs. Not really much someone could do with those but they might monkey around and check in a result using your assignment, or it would be possible to cancel your assignment using that if someone were determined (not trivial, but without the assignment ID itself it wouldn't even be possible).[/QUOTE]

My apologies. I shall follow your advice now that I know.

benchmark stall again after VNC remote desktop software update
 

Updated TIghtVNC to latest available v2.8.11, on i7-8750H laptop (VNC server) and on VNC client box. This is after a Win 10 update and restart, and a BIOS update and other laptop manufacturer updates to current, and a system restart. After that, again, prime95 v29.5b9 had a stall early in a user-initiated throughput benchmark, within 10 minutes of start.