Well, mistakes resulting from inattention or whatever else do happen, to all of us :smile:

+1 for henryzz's suggestion of indicating that the 32-bit address space is the problem.

[QUOTE=debrouxl;298600]Well, mistakes resulting from inattention or whatever else do happen, to all of us :smile:

+1 for henryzz's suggestion of indicating that the 32-bit address space is the problem.[/QUOTE]

I would suggest naming the zip file differently (I was caught also) I couldn't figure out why I kept getting memory error in result.txt

P95v277.win64.zip
P95v277.win32.zip

[QUOTE=diamonddave;298606]I would suggest naming the zip file differently (I was caught also) I couldn't figure out why I kept getting memory error in result.txt

P95v277.win64.zip
P95v277.win32.zip[/QUOTE]
Luckily I was ok with the old style (p95.zip and p64.zip) and never installed the wrong version before checking it, but despite of it, [B]I would give a +1 for diamonddave's suggestion[/B]. Shit could happen to anyone (including me!).

Feature request for MPrime
 

What I would like for MPrime is the ability to pause individual workers without having to stop MPrime and change WorkerThreads= each time. To that end, here's the best idea I (meaning msft) have had how to do that:

CUDALucas has this nice -k option, where you can change the status of other options on the fly by pressing a letter that corresponds to the option.
[code]∰∂ CUDALucas -c 10000 -f 1474560 -polite 64 -k worktodo.txt

continuing work from a partial result M25786547 fft length = 1474560 iteration = 12136257
p -polite 0
p -polite 64
p -polite 0
p -polite 64
Iteration 12140000 M( 25786547 )C, 0xa04ade062b1d3458, n = 1474560, CUDALucas v2.00a err = 0.06268 (0:21 real, 2.0380 ms/iter, ETA 7:43:18)
p -polite 0
Iteration 12150000 M( 25786547 )C, 0x646fe55ad6fd8f11, n = 1474560, CUDALucas v2.00a err = 0.06543 (0:54 real, 5.4282 ms/iter, ETA 20:33:06)[/code]The change happens right when the key is pressed. Here's the source code implementing it: (Edit: This is inside the main LL loop, so the getchar() happens once per iteration.)
[code]if (k_f && !quitting && !expectedResidue && (!(j & 15))
&& _kbhit ())
{
int c = getchar ();
if (c == 'p')
if (polite_f)
{
polite_f = 0;
printf (" -polite 0\n");
}
else
{
polite_f = 1;
printf (" -polite %d\n", polite);
}
if (c == 't')
{
t_f = 0;
printf (" disable -t\n");
}
if (c == 's')
if (s_f == 1)
{
s_f = 2;
printf (" disable -s\n");
}
else if (s_f == 2)
{
s_f = 1;
printf (" enable -s\n");
}
fflush (stdin);
}[/code]

What I'm thinking of for MPrime is to instead check if the char is a number, and if so, then un/pause that worker thread. It would be easy enough to pause multiple workers by pausing them each sequentially, considering pausing a worker would only require a key press. In theory, it might look something like this:
[code][Worker #1 May 15 18:26:01] Iteration: 39650000 / 54197029 [73.1589%]. Per iteration time: 22.197 ms.
[Worker #2 May 15 18:26:23] Iteration: 13480000 / 25572683 [52.7124%]. Per iteration time: 9.995 ms.
[Worker #3 May 15 18:26:23] Iteration: 25160000 / 25560541 [98.4329%]. Per iteration time: 9.762 ms.
3 [Worker #3 May 15 18:26:34] Stopping primality test of M25560541 at iteration 25161213 [98.4377%]
[Worker #3 May 15 18:26:34] Worker stopped.
[Worker #2 May 15 18:33:11] Iteration: 13520000 / 25572683 [52.8689%]. Per iteration time: 9.619 ms.
[Worker #1 May 15 18:33:41] Iteration: 39670000 / 54197029 [73.1958%]. Per iteration time: 22.102 ms.
[Worker #2 May 15 18:34:46] Iteration: 13530000 / 25572683 [52.9080%]. Per iteration time: 9.511 ms.
[Worker #2 May 15 18:36:22] Iteration: 13540000 / 25572683 [52.9471%]. Per iteration time: 9.548 ms.
[Worker #1 May 15 18:37:28] Iteration: 39680000 / 54197029 [73.2143%]. Per iteration time: 22.698 ms.
[Worker #2 May 15 18:37:57] Iteration: 13550000 / 25572683 [52.9862%]. Per iteration time: 9.515 ms.
3 [Worker #3 May 15 18:38:04] Worker starting
[Worker #3 May 15 18:38:04] Setting affinity to run worker on logical CPU #3
[Worker #3 May 15 18:38:05] Resuming primality test of M25560541 using AVX FFT length 1344K, Pass1=448, Pass2=3K
[Worker #3 May 15 18:38:05] Iteration: 25161214 / 25560541 [98.4377%].
[Worker #2 May 15 18:39:33] Iteration: 13560000 / 25572683 [53.0253%]. Per iteration time: 9.665 ms.
[Worker #3 May 15 18:40:06] Iteration: 25240000 / 25560541 [98.7459%]. Per iteration time: 9.815 ms.
[Worker #2 May 15 18:41:11] Iteration: 13570000 / 25572683 [53.0644%]. Per iteration time: 9.757 ms.
[Worker #1 May 15 18:41:12] Iteration: 39690000 / 54197029 [73.2327%]. Per iteration time: 22.391 ms.
[Worker #3 May 15 18:41:43] Iteration: 25250000 / 25560541 [98.7850%]. Per iteration time: 9.749 ms.
[Worker #2 May 15 18:42:49] Iteration: 13580000 / 25572683 [53.1035%]. Per iteration time: 9.749 ms.
[Worker #3 May 15 18:43:21] Iteration: 25260000 / 25560541 [98.8241%]. Per iteration time: 9.759 ms.
[Worker #2 May 15 18:44:26] Iteration: 13590000 / 25572683 [53.1426%]. Per iteration time: 9.693 ms.
[Worker #1 May 15 18:44:55] Iteration: 39700000 / 54197029 [73.2512%]. Per iteration time: 22.317 ms.[/code]

Build 2 is now available.

[url]http://mersenneforum.org/gimps/[/url]

[QUOTE=Prime95;298383]
2. Root cause of several false prime reports in recent years found. Fixed in version 27.7 build 2.[/QUOTE]
Does this possibly affect stress testing at all?

[QUOTE=Octopuss;299637]Does this possibly affect stress testing at all?[/QUOTE]
No. The problem was not with the mathematical part of the program, but rather with the routines to read save files.

[QUOTE=Prime95;298383]2. Root cause of several false prime reports in recent years found. Fixed in version 27.7 build 2.[/QUOTE]

Was this the save file thing? Or something more? How did you fix it?

[QUOTE=ATH;299642]Was this the save file thing? Or something more? How did you fix it?[/QUOTE]

What would happen is that if none of the save files were read, it was possible to fall into the main LL loop with uninitialized FFT data; now, if I'm reading this correctly, when the program sees a save file but cannot read it or any of the backups, then it outputs a warning: "All intermediate files bad. Temporarily abandoning work unit."; and then it does just that, exiting the LL function, where presumably Prime95 behaves as before and moves onto the next work unit. (It seems like there's a lot of new code; perhaps it should be 27.8?)

The primary code in question is commonb.c, starting at line 5260 for anyone else who's interested.

Just a heads-up: The GIMPS home page is still advertising version 26 as the current release build.