interim residue sent to server twice?

[ixfd64]

I'm using Prime95 version 29.8 on my new laptop to finish up some partially complete LL tests (from computers I no longer have access to) before switching to 30.3 for PRP. As this is a new computer, I'm running LL double checks first to make sure the system is stable. It has a six-core processor, and one worker is assigned to each core.

I was checking prime.log when I noticed an interim residue was sent twice:

[Wed Oct 28 20:03:46 2020 - ver 29.8]
Sending interim residue 35000000 for M58797119
Sending interim residue 35000000 for M58797331
Sending interim residue 35000000 for M58797103
[Thu Oct 29 09:05:13 2020 - ver 29.8]
Sending interim residue 35000000 for M58797043
Sending interim residue 35000000 for M58797367
[Thu Oct 29 12:56:09 2020 - ver 29.8]
Updating computer information on the server
Sending interim residue 35000000 for M58797367
Sending interim residue 35000000 for M58794581
Sending expected completion date for M58794581: Nov 09 2020

Is this supposed to happen under certain circumstances?

Assuming this is not the case, here's the sequence of events that might be useful in reproducing the issue:

1. Prime95 sends interim residues for three exponents that had passed 35 million iterations
2. Two more exponents pass 35 million iterations and a prime.spl file is created
3. To conserve power, I put the computer to sleep in the evening
4. The computer reboots in the early morning due to a system update
5. Prime95 sends interim residues for those two exponents after starting back up
6. The remaining exponent passes 35 million iterations and a new prime.spl file is created
7. Prime95 sends estimated completion times and what is supposed to be one remaining interim residue

[ixfd64]

I may have found the cause. It's possible that the worker had just passed 35 million iterations when the system rebooted. Windows is supposed to politely ask processes to terminate, but it's been reported that this doesn't always happen.

Prime95 stores interim residues in a prime.spl file and only sends them at certain intervals. So when Prime95 started back up, the data in prime.spl was sent to the server, but the worker's progress was rolled back to a point before 35 million iterations. After crossing the threshold again, the interim residue was sent a second time.

[ixfd64]

It turns out my new laptop sometimes reboots when waking up from sleep. This is apparently an issue with some Windows 10 devices. I should probably open a new thread as this is not a Prime95 issue.

[LaurV]

The "Prime95 issue" is why do you put your computer in sleeping mode during P95 is running? (these two situations are a bit antagonistic, aren't they? hihi - do you intend your computer to sleep during it's idle, or to crunch some numbers?)

[ixfd64]

Originally Posted by LaurV

The "Prime95 issue" is why do you put your computer in sleeping mode during P95 is running? (these two situations are a bit antagonistic, aren't they? hihi - do you intend your computer to sleep during it's idle, or to crunch some numbers?)

Our electricity costs are already a little high due to heaters.

[LaurV]

Yuck!
1. Replace heaters with vees (i.e. Radeon Vii).
2. Profit!

[nicksonqueiroz]

How to interpret the obtained residue?

For example:

I finished a test and 01DAFC26AD7410__ appeared as residue. What does that mean?

[Uncwilly]

Originally Posted by nicksonqueiroz

I finished a test and 01DAFC26AD7410__ appeared as residue. What does that mean?

It means that the number that you tested was not prime. If it was prime the final residue would be all zeros. Other than that, the residue of an LL test has little meaning. If it matches a previous test's LL residue, then we know that the number is for sure not a prime (the double check verified the result).

[kriesel]

Originally Posted by nicksonqueiroz

I finished a test and 01DAFC26AD7410__ appeared as residue. What does that mean?

It meant the least 64 bits (res64) of your completed PRP test of M114550507 indicated composite, with the least significant 8 bits masked until the PRPDC or Cert completed. https://www.mersenne.org/report_expo...4550507&full=1 now shows all the least significant 64 bits since the run generated and uploaded a proof file, and the subsequent Cert was successfully completed.

What Unwilly wrote is correct for LL tests. (A correct run yielding 0 residue at the end indicating a prime, otherwise a nonzero hexadecimal value. But first time LL tests are not being issued by the server any more. First time tests are issued as PRP assignments.)
An ordinary prime95 LLDC confirming composite such as for M58738283 would yield a result line in results.txt like

UID: Kriesel/martin, M58738283 is not prime. Res64: B926E1B477C99A04. Wh4: B3CF740C,12511397,00000000, AID: 3B770C316C8E9CC178A445A6D5D75D7F

or in results.json.txt,

{"status":"C", "exponent":58738283, "worktype":"LL", "res64":"B926E1B477C99A04", "fft-length":3145728, "shift-count":12511397, "error-code":"00000000", "security-code":"B3CF740C", "program":{"name":"Prime95", "version":"30.4", "build":9, "port":4}, "timestamp":"2021-02-27 04:50:43", "user":"Kriesel", "computer":"martin", "aid":"3B770C316C8E9CC178A445A6D5D75D7F"}

The PRP test residue for a probable-prime varies by PRP computation type. Most common is PRP type one, for which final res64 of a probable-prime would be 1. See https://www.mersenneforum.org/showpo...32&postcount=8 for the list of PRP test types etc.
In a gpuowl result, a PRP test indicating probably-prime would look like this:

{"status":"P", "exponent":"1257787", "worktype":"PRP-3", "res64":"0000000000000001", "residue-type":"1", "errors":{"gerbicz":"0"}, "fft-length":"131072", "proof":{"version":"1", "power":"10", "hashsize":"64", "md5":"18a41533a69c9f149bedb038b3dae6f5"}, "program":{"name":"gpuowl", "version":"v6.11-380-g79ea0cc"}, "user":"kriesel", "computer":"asr2/radeonvii-w2", "timestamp":"2022-02-07 18:43:30 UTC"}

while an LLDC prime result for the same exponent would look like this:

{"status":"P", "exponent":"1257787", "worktype":"LL", "res64":"0000000000000000", "fft-length":"131072", "shift-count":"0", "program":{"name":"gpuowl", "version":"v6.11-380-g79ea0cc"}, "user":"kriesel", "computer":"asr2/radeonvii2", "timestamp":"2022-08-17 00:14:19 UTC"}

See also result formats for the commonly used GIMPS applications, with examples, in the reference info collection.