I don't know if this is a server problem or not. Just now, 0220 UTC, 5/20/20, I called a manual communication in P95, and got a flood of "Cannot connect to host" and "no such assignment key" messages, followed by a bunch of get assignment action. I have the Com thread from before and during this episode, but it has a lot of things that should not be broadcast.

[QUOTE=kriesel;545872]That's a long way from current (2017; V29.8b6 is from 2019 and current). Why the old version?
Also you've already reported a 0-shift LL result for that same exponent, perhaps from gpuowl. And the bits of unmasked residue do not match.[/QUOTE]
If it works, don't fix it. The version is the latest (and fastest) for my CPU (i7-6950X). All further updates address newer stuff, and the reply (from George and co) on the forum when I asked long time ago if I should upgrade or not, was along the same lines. Anyhow, I tested some of the newer versions, and they are marginally slower (as they do more sanity checks, cache optimization, or whatever). This CPU has A LOT of cache and it feels fine with the version I have.

For the second part, yes, I finished a gpuowl test few days ago, but did not report until the P95 run ended too, which came 5 days after, to make sure I have a match. The number you see is not the residue (which matches!) but the checksum calculation (the thief-deterring part P95 employs, so called We4 value).

Anyhow, I think James/George is/are on the way to discover, respective fix, a long time standing bug in P95, uncovered till now: we are in a very rare case when the We4 calculus overflows the 4 bytes, or at least this is my understanding from reading the PM exchange. My life's drama... If there is a stone in the rice pot, the stone will always end in my bowl, and between my teeth (no joke here, haha, this is very true, confirmed many times, and a running joke in our family for years).

Beans can be hazardous, too. Pebbles can simulate [I]dry[/I] beans enough to get past the filters.

I'm getting the same "does not match" checksum error. I am manually submitting results from an off-line machine. All of the double check results error out, but all of the P-1 results are OK. This system has worked reliably for years.

[QUOTE=1997rj7;545977]I'm getting the same "does not match" checksum error[/QUOTE]We're not yet sure where the problem lies, but it is being investigated. The 5 additional examples you just submitted will probably be useful in debugging.

If it helps, I am using a really old version, 26.4 build 1.

[QUOTE=James Heinrich;545981]We're not yet sure where the problem lies, but it is being investigated.[/QUOTE]I think manual results should be correctly accepting LL results again. You can blame me for breaking it while investigating LaurV's report of it not working.

Except for LaurV, your result does appear to contain an actual invalid checksum, for reasons I can't explain.[QUOTE=LaurV;545910]Grrrr.... I want my candies! This is V29.1 build 15
If it works, don't fix it... the reply (from George and co) on the forum when I asked long time ago if I should upgrade or not, was along the same lines[/QUOTE]The official recommendation is now that you upgrade, please.
If you want to re-run that exponent on the same system but with v29.8b6 we'll give you [b]two[/b] candies when it completes. :smile:

[QUOTE=James Heinrich;546030]
Except for LaurV, your result does appear to contain an actual invalid checksum, for reasons I can't explain.The official recommendation is now that you upgrade, please.
If you want to re-run that exponent on the same system but with v29.8b6 we'll give you [b]two[/b] candies when it completes. :smile:[/QUOTE]

The result line of yours that I saw had only 2 of the checksum,shift count,#errors values

[QUOTE=Prime95;546032]The result line of yours that I saw had only 2 of the checksum,shift count,#errors values[/QUOTE]That, I think, is normal in versions older than v29.4 (at least according to my notes) -- the shift_count wasn't recorded in the result line of earlier versions. Presumably the actual computation was also always performed with a shift of zero.

[QUOTE=James Heinrich;546033]That, I think, is normal in versions older than v29.4 (at least according to my notes) -- the shift_count wasn't recorded in the result line of earlier versions. Presumably the actual computation was also always performed with a shift of zero.[/QUOTE]

I checked the source for 25.9 and it spits out 3 values. I suspect it has been that way since version 18. I'll check if you'd like.

My notes say: "Prime95 v29.3 and earlier report two sets of numbers after the versionID: checksum and error_code, omitting the shift_count. George says he plans to add it in future versions. Added in v29.4"