Prime95 version 29.4

[ixfd64]

I don't recall doing anything prior to entering the number of workers. I'll try again the next time I install Prime95 on a new machine.

[Prime95]

Originally Posted by ATH

From undoc.txt in 29.4b8:

If I use this on AWS EC2 instance on startup it still says "CPU identity mismatch" and "ComputerGUID=" in local.txt changes and it creates another CPU on my account. That way you get tons of CPUs on your account, a new one every time you loose your session and it automatically starts a new one.

I'm also wondering what is "HardwareGUID=" in prime.txt compared to "ComputerGUID=" in local.txt? There is also a "WindowsGUID=" in prime.txt but it has no value.

I think I have a fix for you in 29.5 build 8 (not out yet). To sync up, you *may* need to delete FixedHardwareUID from prime.txt, sync up with primenet, then add FixedHardwareUID back to prime.txt.

[ric]

I've configured an instance of Prime95 service v29.4.7 on a Win2016 server with

PauseWhileRunning=* during 1-5/8:00-18:00

in prime.txt, with the intention of having P95 to stop during work hours Mon-Fri, and resume crunching at night and on weekends.

If I stop/start the service during "off" hours (=in the middle of a workday), everything is fine: a few seconds for Jacobi testing, then it becomes idle until requested - and it also respects my intended schedule for weekends.

When, on the other side, I happen to stop/start the service during "on" hours (=at night, or during weekends - that is, when server reboots typically happen), its schedule is no longer respected: the service keeps on crunching all day long, even in its "off" hours - until stopped.

A minor annoyance, indeed, now that I've understood its rationale - though I'm not sure whether this is its intended behaviour. Did anyone else experience something similar?

[Prime95]

Originally Posted by ric

I happen to stop/start the service during "on" hours (=at night, or during weekends - that is, when server reboots typically happen), its schedule is no longer respected: the service keeps on crunching all day long, even in its "off" hours - until stopped.

A minor annoyance, indeed, now that I've understood its rationale - though I'm not sure whether this is its intended behaviour. Did anyone else experience something similar?

I can fix that. Try again in version 29.6.

[ixfd64]

Another suggested change: the "Visit Mersenne Wiki" option under the Help menu should be removed as the wiki has been shut down.

[James Heinrich]

Originally Posted by ixfd64

the "Visit Mersenne Wiki" option under the Help menu should be removed as the wiki has been shut down.

Although it is apparently coming back, eventually, at mersennewiki.com (once Chris finds some spare time).

[Uncwilly]

Originally Posted by James Heinrich

Although it is apparently coming back, eventually, at mersennewiki.com (once Chris finds some spare time).

Primewiki is currently much further along and dealing with several issues that had come up.

[James Heinrich]

Originally Posted by Uncwilly

Primewiki is currently much further along and dealing with several issues that had come up.

Ooh, didn't know of that. I have updated relevant links to point there, thanks.

[kriesel]

In Prime95 V29.4b8, set InterimResidues=1 in prime.txt and let run.
Stop and continue. It will skip one iteration's interim residue output.
There's no output for iteration 32 below.

...
[Feb 10 17:39:31] Iteration: 30 / 82589933 [0.00%], ms/iter: 114.376, ETA: 109d 07:58
[Feb 10 17:39:32] M82589933 interim Wg4 residue E5F364AA0E27B1E5 at iteration 30
[Feb 10 17:39:38] Iteration: 31 / 82589933 [0.00%], ms/iter: 116.014, ETA: 110d 21:32
[Feb 10 17:39:40] M82589933 interim Wg4 residue 9008B9C355C8F005 at iteration 31
[Feb 10 17:39:40] Iteration: 32 / 82589933 [0.00%], ms/iter: 113.969, ETA: 108d 22:37
[Feb 10 17:39:41] Stopping primality test of M82589933 at iteration 32 [0.00%]
[Feb 10 17:39:41] Worker stopped.
[Feb 10 17:58:21] Worker starting
[Feb 10 17:58:21] Setting affinity to run worker on CPU core #2
[Feb 10 17:58:25] Running Jacobi error check.  Passed.  Time: 73.089 sec.
[Feb 10 17:59:37] Resuming primality test of M82589933 using FFT length 4480K, Pass1=896, Pass2=5K, clm=4
[Feb 10 17:59:43] Iteration: 33 / 82589933 [0.00%].
[Feb 10 17:59:44] M82589933 interim Wg4 residue A211573CE86B5929 at iteration 33
[Feb 10 17:59:50] Iteration: 34 / 82589933 [0.00%], ms/iter: 54.171, ETA: 51d 18:46
[Feb 10 17:59:51] M82589933 interim Wg4 residue 24ED4C62B86E20DA at iteration 34
[Feb 10 17:59:51] Iteration: 35 / 82589933 [0.00%], ms/iter: 112.100, ETA: 107d 03:45
[Feb 10 17:59:52] M82589933 interim Wg4 residue C5657DF459CC3CD5 at iteration 35

I don't know if it also skips for larger interimresidues values if it happens to get the stop signal at the iteration for which an output should occur. Haven't tried it on any other versions.

[kriesel]

There's a one-iteration stagger in residue output on Prime95 PRP.

[Feb 10 18:54:24] Worker starting
[Feb 10 18:54:24] Setting affinity to run worker on CPU core #2
[Feb 10 18:54:25] Starting Gerbicz error-checking PRP test of M82589933 using FFT length 4480K, Pass1=896, Pass2=5K, clm=4
[Feb 10 18:54:27] Iteration: 1 / 82589933 [0.00%], ms/iter: 1431.427, ETA: 1368d 07:17
[Feb 10 18:54:27] Iteration: 2 / 82589933 [0.00%], ms/iter: 335.534, ETA: 320d 17:42
[Feb 10 18:54:28] M82589933 interim Wg4 residue 000000000000001B at iteration 1
[Feb 10 18:54:29] Iteration: 3 / 82589933 [0.00%], ms/iter: 346.241, ETA: 330d 23:20
[Feb 10 18:54:30] M82589933 interim Wg4 residue 000000000000088B at iteration 2
[Feb 10 18:54:36] Iteration: 4 / 82589933 [0.00%], ms/iter: 334.144, ETA: 319d 09:48
[Feb 10 18:54:38] M82589933 interim Wg4 residue 0000000000DAF26B at iteration 3
[Feb 10 18:54:38] Iteration: 5 / 82589933 [0.00%], ms/iter: 358.347, ETA: 342d 13:04
[Feb 10 18:54:39] M82589933 interim Wg4 residue 000231C54B5F6A2B at iteration 4
[Feb 10 18:54:40] Iteration: 6 / 82589933 [0.00%], ms/iter: 330.110, ETA: 315d 13:16
[Feb 10 18:54:41] M82589933 interim Wg4 residue D310B7D97DD4E9AB at iteration 5
[Feb 10 18:54:47] Iteration: 7 / 82589933 [0.00%], ms/iter: 342.891, ETA: 327d 18:28
[Feb 10 18:54:48] M82589933 interim Wg4 residue 2AC0B180838228AB at iteration 6
[Feb 10 18:54:49] Iteration: 8 / 82589933 [0.00%], ms/iter: 336.957, ETA: 322d 02:20
[Feb 10 18:54:50] M82589933 interim Wg4 residue 9B5ACA650265A6AB at iteration 7
[Feb 10 18:54:50] Iteration: 9 / 82589933 [0.00%], ms/iter: 335.743, ETA: 320d 22:30
[Feb 10 18:54:52] M82589933 interim Wg4 residue B47759B0D250A2AB at iteration 8
[Feb 10 18:54:58] Iteration: 10 / 82589933 [0.00%], ms/iter: 348.099, ETA: 332d 17:58
[Feb 10 18:54:59] M82589933 interim Wg4 residue DF36E033DAB69AAB at iteration 9

[PhilF]

In version 29.4 build 8, I rebooted a machine that had interim residue waiting to send. After the reboot, the residue was sent and the test then resumed immediately, meaning the default BootDelay of 90 seconds was not honored.