Prime95 version 27.7 / 27.9
 

Prime95 version 27.7 build 2 is available. My second attempt at a release candidate. If no major problems are reported this will become the official GIMPS client.

This version also fixes a few rare bugs in 27.6 (see [url]http://mersenneforum.org/showpost.php?p=297258&postcount=2[/url]). It also fixes a bug partly responsible for the rare false positive reports GIMPS has seen in recent years. As part of this fix, a save file that cannot be read will be renamed with a .bad extension in hopes that the file can be successfully read at a later time (yes, this can happen).

Also, note the new naming scheme for downloads.

Download links:
Windows 64-bit: [url]ftp://mersenne.org/gimps/p95v277.win64.zip[/url]
Windows 32-bit: [url]ftp://mersenne.org/gimps/p95v277.win32.zip[/url]
Linux 64-bit: [url]ftp://mersenne.org/gimps/p95v277.linux64.tar.gz[/url]
Linux 32-bit: [url]ftp://mersenne.org/gimps/p95v277.linux32.tar.gz[/url]
Mac OS X: [url]ftp://mersenne.org/gimps/p95v277.MacOSX.zip[/url]
FreeBSD 64-bit: [url]ftp://mersenne.org/gimps/p95v277.FreeBSD64.tar.gz[/url]
Source code: [url]ftp://mersenne.org/gimps/p95v277.source.zip[/url]
Windows 64-bit service: [url]ftp://mersenne.org/gimps/p95v277.win64.service.zip[/url]
Windows 32-bit service: [url]ftp://mersenne.org/gimps/p95v277.win32.service.zip[/url]

1. SoB cannot package a default prime.txt with the Mac OS X version because the Mac version changes the working directory to ~/Prime95. Mac version changed to copy a prime.txt file from the application bundle to ~/Prime95. Fixed in version 27.7 build 2.
2. Root cause of several false prime reports in recent years found. Fixed in version 27.7 build 2.
3. AffinityScramble has a bug when more than 36 cores are present. Fixed in version 27.7 build 3.
4. Modern Linux seems to use /sys/class/power_supply/ instead of /proc/acpi/battery/. Both will be supported in 27.7 build 3.
5. Adding FFT2=32M to worktodo.ini lines does not work for exponents above 595,800,000. Fixed in 27.7 build 4.
6. Small one-pass AVX FFTs have a data-dependent bug that can cause an infinite loop -- most likely to occur in the very smallest FFT sizes. Fixed in 27.8.
7. Using more than 16 threads in an SSE2 8K FFT caused a crash. Fixed in 27.9.
8. Mac OS X version crashes when merging worker window's output. Fixed in 27.9.
9. Prime95 may get roundoff errors testing numbers with a large base such as PRP of 2*25735^25735-1. In 27.9, prime95 will be somewhat less aggressive in choosing FFT sizes when the base is above 5800.
10. Multi-threaded FFTs sometimes get spurious very large roundoff errors. Fixed in 27.9.
11. On some systems (depends on the implementation of strcpy) the GMPECMHook=1 option will output incorrect values. Fixed in 27.10.
12. On some systems (depends on the implementation of memcpy) the GCD code could return an incorrect value. Fortunately, only Alex Kruppa seems to get this error and the last error. Fixed in 27.10.
13. Small one-pass AVX FFTs have a data-dependent bug in the carry propagation code. This bug mainly affects length 32 FFTs, but could affect FFTs up to length 256. Fixed in 27.11.
14. If P-1 stage 1 backtracks due to an excessive roundoff error then there is a 50% chance the P-1 result will be corrupted. Fixed in 28.2.
15. PRP of the number one (can accidentally occur as in PRP=1,2,101,-1,"7432339208719,341117531003194129") crashed. Fixed in Windows 28.3 and Linux 28.4.

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

P-1 memory allocation error
 

[QUOTE=Prime95;298383]<placeholder for known bugs and fixes>[/QUOTE]
[CODE][May 4 08:03] Waiting 10 seconds to stagger worker starts.
[May 4 08:03] Worker starting
[May 4 08:03] Setting affinity to run worker on any logical CPU.
[May 4 08:03] Optimal P-1 factoring of M56320727 using up to 8000MB of memory.
[May 4 08:03] Assuming no factors below 2^72 and 2 primality tests saved if a factor is found.
[May 4 08:03] Optimal bounds are B1=565000, B2=12147500
[May 4 08:03] Chance of finding a factor is an estimated 4.2%
[May 4 08:03] Using FFT length 3M, Pass1=768, Pass2=4K
[May 4 08:03] Available memory is 7938MB.
[May 4 08:03] Using 7391MB of memory. Processing 288 relative primes (0 of 288 already processed).
[May 4 08:07] Memory allocation error. Trying again using less memory.
[May 4 08:07] Using FFT length 3M, Pass1=768, Pass2=4K
[May 4 08:07] Available memory is 6350MB.
[May 4 08:07] Using 6344MB of memory. Processing 245 relative primes (0 of 288 already processed).
[May 4 08:11] Memory allocation error. Trying again using less memory.
[May 4 08:11] Using FFT length 3M, Pass1=768, Pass2=4K
[May 4 08:11] Available memory is 5080MB.
[May 4 08:11] Using 5077MB of memory. Processing 193 relative primes (0 of 288 already processed).
[/CODE]

I started getting this memory error as soon as I installed the new 27.1 version. I have not had a memory error on this computer since it was new 1 1/2 years ago.

I fell back to 27.6 build 3 and the problem went away. Using Windows 7 64 bit with Core-i7 970 12 Mb memory

Chuck

27.7 good small FTT no error.

[QUOTE=Chuck;298424]I fell back to 27.6 build 3 and the problem went away. Using Windows 7 64 bit with Core-i7 970 12 Mb memory[/QUOTE]

There is no difference between 27.6 and 27.7 with respect to allocating P-1 memory.

[QUOTE=Prime95;298437]There is no difference between 27.6 and 27.7 with respect to allocating P-1 memory.[/QUOTE]

Nuts — my error — I went to Xyzzy's mirror site to get the software and mistakenly picked up the 32 bit version instead of the 64 bit. Sorry for the false report.

Chuck

[QUOTE=Chuck;298448]Nuts — my error — I went to Xyzzy's mirror site to get the software and mistakenly picked up the 32 bit version instead of the 64 bit. Sorry for the false report.

Chuck[/QUOTE]
At least it's not your RAM ;)

[QUOTE=Chuck;298448].....mistakenly picked up the 32 bit version instead of the 64 bit.....

Chuck[/QUOTE]

Been there. Done that.:redface:

[QUOTE=Chuck;298448]Nuts — my error — I went to Xyzzy's mirror site to get the software and mistakenly picked up the 32 bit version instead of the 64 bit. Sorry for the false report.

Chuck[/QUOTE]
Maybe there should be a warning that 32-bit is the problem.

[QUOTE=henryzz;298530]Maybe there should be a warning that 32-bit is the problem.[/QUOTE]

No I just shouldn't be STUPID and not paying attention.

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.

[QUOTE=NBtarheel_33;299878]Just a heads-up: The GIMPS home page is still advertising version 26 as the current release build.[/QUOTE]Yes, it is supposed to be that way until it is finalized that version 27.x is stable and doesn't need any further changes or enhancements and its creators say so.

Possible bug?
 

[code]bill@Gravemind:~/MPrime∰∂ mprime -d
[Main thread May 22 04:52] Mersenne number primality test program version 27.7
[Main thread May 22 04:52:35] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 256 KB, L3 cache size: 8 MB
[Main thread May 22 04:52:35][U] Logical CPUs 1,5 form one physical CPU.[/U]
[Main thread May 22 04:52:35] [U]Logical CPUs 2,6 form one physical CPU.[/U]
[Main thread May 22 04:52:35] [U]Logical CPUs 3,7 form one physical CPU.[/U]
[Main thread May 22 04:52:35] [U]Logical CPUs 4,8 form one physical CPU.[/U]
[Main thread May 22 04:52:35] Starting workers.
[Comm thread May 22 04:52:35] Exchanging program options with server
[Worker #1 May 22 04:52:35] Worker starting
[Worker #1 May 22 04:52:35] [U]Setting affinity to run worker on logical CPU #1[/U]
[Worker #2 May 22 04:52:35] Waiting 5 seconds to stagger worker starts.
[Worker #3 May 22 04:52:35] Waiting 10 seconds to stagger worker starts.
[Worker #4 May 22 04:52:35] Waiting 15 seconds to stagger worker starts.
[Comm thread May 22 04:52:35] Done communicating with server.
[Worker #1 May 22 04:52:36] [U]Setting affinity to run helper thread 1 on logical CPU #5[/U]
[Worker #1 May 22 04:52:36] Resuming primality test of M54197029 using AVX FFT length 2880K, Pass1=384, Pass2=7680, 2 threads
[Worker #1 May 22 04:52:36] Iteration: 44942274 / 54197029 [82.9238%].
[Worker #2 May 22 04:52:40] Worker starting
[Worker #2 May 22 04:52:40] [U]Setting affinity to run worker on logical CPU #5[/U]
[Worker #2 May 22 04:52:41] [U]Setting affinity to run helper thread 1 on logical CPU #2[/U]
[Worker #2 May 22 04:52:41] Resuming primality test of M25318487 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #2 May 22 04:52:41] Iteration: 175637 / 25318487 [0.6937%].
[Worker #3 May 22 04:52:45] Worker starting
[Worker #3 May 22 04:52:45] [U]Setting affinity to run worker on logical CPU #2[/U]
[Worker #3 May 22 04:52:45] [U]Setting affinity to run helper thread 1 on logical CPU #6[/U]
[Worker #3 May 22 04:52:46] Resuming primality test of M25572683 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #3 May 22 04:52:46] Iteration: 14725704 / 25572683 [57.5837%].
[Worker #4 May 22 04:52:50] Worker starting
[Worker #4 May 22 04:52:50] [U]Setting affinity to run worker on logical CPU #6[/U]
[Worker #4 May 22 04:52:50] [U]Setting affinity to run helper thread 1 on logical CPU #3[/U]
[Worker #4 May 22 04:52:51] Resuming primality test of M25353589 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #4 May 22 04:52:51] Iteration: 11108729 / 25353589 [43.8152%].[/code]
I have no idea why in the world it does this. It doesn't matter whether or not I use AffinityScramble2 override or not -- same result.
[code]bill@Gravemind:~/MPrime∰∂ cat local.txt
<snip>
WorkerThreads=4
NumCPUs=4
ThreadsPerTest=2
<snip>

[Worker #1]
Affinity=0

[Worker #2]
Affinity=1

[Worker #3]
Affinity=2

[Worker #4]
Affinity=3[/code]
It gets neither the affinity nor the hyperthreading correct for workers 2-4.

I remember this once happened when I first installed MPrime (v27) on my laptop, and it was very frustrating; however, I also recall figuring out some stupid user error after which it started working again, so I never said anything. But, this is exactly the same sort of symptoms, and I can't figure out for the life of me what I'm doing wrong this time.

Edit: Another example:
[code]bill@Gravemind:~/MPrime∰∂ cat local.txt
<snip>
WorkerThreads=4
NumCPUs=4
ThreadsPerTest=2
<snip>

[Worker #1]
[U]Affinity=1[/U]

[Worker #2]
[U]Affinity=2[/U]

[Worker #3]
[U]Affinity=3[/U]

[Worker #4]
[U]Affinity=4[/U]
bill@Gravemind:~/MPrime∰∂ mprime -d
[Main thread May 22 04:58] Mersenne number primality test program version 27.7
[Main thread May 22 04:58:44] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 256 KB, L3 cache size: 8 MB
[Main thread May 22 04:58:44] Unable to detect some of the hyperthreaded logical CPUs.
[Main thread May 22 04:58:44] Enough information obtained to make a reasonable guess.
[Main thread May 22 04:58:44] [U]Logical CPUs 1,5 form one physical CPU.[/U]
[Main thread May 22 04:58:44] [U]Logical CPUs 2,6 form one physical CPU.[/U]
[Main thread May 22 04:58:44] [U]Logical CPUs 3,7 form one physical CPU.[/U]
[Main thread May 22 04:58:44] [U]Logical CPUs 4,8 form one physical CPU.[/U]
[Main thread May 22 04:58:44] Starting workers.
[Worker #1 May 22 04:58:44] Worker starting
[Worker #3 May 22 04:58:44] Waiting 10 seconds to stagger worker starts.
[Worker #1 May 22 04:58:44] [U]Setting affinity to run worker on logical CPU #5[/U]
[Worker #2 May 22 04:58:44] Waiting 5 seconds to stagger worker starts.
[Worker #4 May 22 04:58:44] Waiting 15 seconds to stagger worker starts.
[Worker #1 May 22 04:58:45] [U]Setting affinity to run helper thread 1 on logical CPU #2[/U]
[Worker #1 May 22 04:58:45] Resuming primality test of M54197029 using AVX FFT length 2880K, Pass1=384, Pass2=7680, 2 threads
[Worker #1 May 22 04:58:45] Iteration: 44947544 / 54197029 [82.9335%].
[Worker #2 May 22 04:58:49] Worker starting
[Worker #2 May 22 04:58:49] [U]Setting affinity to run worker on logical CPU #2[/U]
[Worker #2 May 22 04:58:50] [U]Setting affinity to run helper thread 1 on logical CPU #6[/U]
[Worker #2 May 22 04:58:50] Resuming primality test of M25318487 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #2 May 22 04:58:50] Iteration: 183276 / 25318487 [0.7238%].
[Worker #3 May 22 04:58:54] Worker starting
[Worker #3 May 22 04:58:54] [U]Setting affinity to run worker on logical CPU #6[/U]
[Worker #3 May 22 04:58:55] [U]Setting affinity to run helper thread 1 on logical CPU #3[/U]
[Worker #3 May 22 04:58:55] Resuming primality test of M25572683 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #3 May 22 04:58:55] Iteration: 14733012 / 25572683 [57.6123%].
[Worker #4 May 22 04:58:59] Worker starting
[Worker #4 May 22 04:58:59] [U]Setting affinity to run worker on logical CPU #3[/U]
[Worker #4 May 22 04:59:00] [U]Setting affinity to run helper thread 1 on logical CPU #7[/U]
[Worker #4 May 22 04:59:00] Resuming primality test of M25353589 using AVX FFT length 1344K, Pass1=448, Pass2=3K, 2 threads
[Worker #4 May 22 04:59:00] Iteration: 11123987 / 25353589 [43.8753%].[/code]
Notice that it screws up with the same pattern, though this time Worker 1 isn't even set properly.

If I set Affinity(1)=0, Affinity(2)=5, Affinity(3)=2, Affinity(4)=7, then what I wind up getting is 04 (correct), 62 (should be 51), 15 (should be 26), 8* (should be 73) respectively, where * is "[Worker #4 May 22 05:03:04] Setting affinity to run helper thread 1 on any logical CPU." I'll leave it like this overnight, since at least there are no overlaps as in the first two examples.

[QUOTE=Dubslow;300029]
I have no idea why in the world it does this.
[/QUOTE]

Here is what is happening. First, consider a CPU with 8 physical cores and no hyperthreading. These cores are numbered from 1 to 8. If you use two threads for your four workers, worker 1 gets assigned CPUs 1&2, worker 2 gets assigned CPUs 3&4, etc.

Now assume you have 4 cores with hyperthreading and logical CPUs 1 & 2 form physical CPU 1. Again, using two threads for your four workers, worker 1 gets assigned logical CPUs 1&2, worker 2 gets assigned logical CPUs 3&4, etc.

Now assume you have 4 cores with hyperthreading and logical CPUs 1 & 5 form physical CPU 1. An affinity scramble mask of "05162738" is generated. Again, using two threads for your four workers, worker 1 gets assigned scrambled CPUs 1&2 which maps to logical CPUs 0&5, worker 2 gets assigned scrambled CPUs 3&4 which maps to logical CPUs 1&6, etc.

Now look at your case. An affinity scramble mask of "05162738" was generated. You specifically told prime95 to have worker 1 used scrambled CPU 1 (add 1 to the Affinity= setting) and 2 (hyperthreading always uses the next scrambled CPU number). Worker 2 was told to use scrambled CPUs 2 & 3, etc. This explains the assignments you are seeing.

In local.txt, remove all the Affinity= settings. Things should get better.

[QUOTE=Prime95;300052]
Now look at your case. An affinity scramble mask of "04152637" was generated. You specifically told prime95 to have worker 1 used scrambled CPU 1 (add 1 to the Affinity= setting) and 2 (hyperthreading always uses the next scrambled CPU number). Worker 2 was told to use scrambled CPUs 2 & 3, etc. This explains the assignments you are seeing.[/quote]I don't understand this. If I have Affinity=0 under Worker #1, shouldn't that mean it sets one thread to CPU0, and the helper thread to the next number = CPU4? Then if Worker 2 has Affinity=1, then it gets assigned CPU1, looks at the mask and sees the matching 5 so the helper goes on CPU5, etc.?

The thing is, I've had it exactly like this before and it worked just fine.
[QUOTE=Prime95;300052]
In local.txt, remove all the Affinity= settings. Things should get better.[/QUOTE]
I did this, and got things like "Setting affinity to run worker on logical CPUs 3,7" and "Setting affinity to run helper thread 1 on logical CPUs 3,7" with each worker getting a different physical core; however CPU usage is not quite at 100% anymore, presumably because threads are occasionally still switching between each of the pair they're assigned. That's why I used Affinity= for each thread before. As I said above, it worked fine like that before.

[QUOTE=Dubslow;300057]I did this, and got things like "Setting affinity to run worker on logical CPUs 3,7" and "Setting affinity to run helper thread 1 on logical CPUs 3,7" with each worker getting a different physical core; however CPU usage is not quite at 100% anymore, presumably because threads are occasionally still switching between each of the pair they're assigned.[/quote]

Switching threads between logical CPUs 3 and 7 should not impact performance. The two share the same L1 and L2 cache.

Any use of multithreading may well cause CPU usage to drop below 100% as occasionally one thread must wait on the other to finish up. BTW, if you are doing P-1, prime95 will do both big multiplies and big adds. The multiplies are multithreaded, the adds are not (further degrading the CPU utilization figure).

[quote]That's why I used Affinity= for each thread before. As I said above, it worked fine like that before.[/QUOTE]

You can test setting each worker affinity with Affinity=0 (use scrambled CPUs 1&2), Affinity=2 (use scrambled CPUs 3&4), Affinity=4 (use scrambled CPUs 5&6), etc.

You'll probably get best throughput by not using multithreading at all.

I would agree with George. For me the best is 4 workers in 4 threads, no helpers (in a 8-HT-cores machine). Hyper-threading is generally generating too much heat and it takes too much energy for the plus of performance it brings, especially when we are talking about programs so cache-optimized as p95. Running 8 workers (or 4 workers in 8 cores, one main plus one helper thread for each worker) generally brings about 20% more performance, for a 50-80% more energy (and heat!). Additionally, running 4 single-threaded workers lets some free firing-power for other daily working stuff (no, I don't talk about writing/sending mails and browsing the forum).

I figured out (thanks to fivemack) for the other stuff to do "south of here", they're generally not optimized like P95, so HT for them does help. I realized though that ATM I'm not running any of those, so I did turn off HT for now. (My statement about it working before (some months ago) still stands though.)

Windows is not 100% consistent in enumerating cores. For example, I have a dual Opteron 6128 box (16 physical cores). Prime64 runs 16 individual worker threads, each assigned to a unique core. Windows/Prime64 cores correlate like this under the current Win7Pro install: 1-8 match, Windows 9-12 => Prime 13-16, Windows 13-16 => Prime 9-12.
On different OS (Win2k3 server, Win7Pro without SP1, and W2K8R2 [IIRC, might have been plain W2K8]) but EXACT same hardware and BIOS settings, they correlate exactly. Another Win7 install swapped 5-8 and 1-4.

With hyperthreading, the permutations get even weirder. Luckily, the enumerations appear to remain consistent once established; once you figure out the particular setup it doesn't change until a new OS is installed.

Ubuntu 10.4(? LTS) enumeration matched Mprime numbering the one time I installed it.

CPU affinity gone wild
 

Some affinity "fun" on some big iron...
prime95 v27.7 x86-64, Linux

Wrong usage of Affinity + AffinityScramble2 or bug? There seems to be an issue with the AffinityScramble2 and small letters, capital letters work fine!

local.txt
[CODE]
WorkerThreads=1
ThreadsPerTest=10
Affinity=0
AffinityScramble2=0123456789
[...]
Pid=30642
[/CODE]

[CODE]pid 30642's current affinity mask: ffffffffffffffffffff # main thread
pid 30806's current affinity mask: ffffffffffffffffffff # communication thread
pid 30807's current affinity mask: 1
pid 30869's current affinity mask: 2
pid 30870's current affinity mask: 4
pid 30871's current affinity mask: 8
pid 30872's current affinity mask: 10
pid 30873's current affinity mask: 20
pid 30874's current affinity mask: 40
pid 30875's current affinity mask: 80
pid 30876's current affinity mask: 100
pid 30877's current affinity mask: 200
[/CODE]


local.txt
[CODE]
WorkerThreads=1
ThreadsPerTest=10
Affinity=0
AffinityScramble2=UVWXYZabcd
[...]
Pid=31147
[/CODE]

[CODE]pid 31147's current affinity mask: ffffffffffffffffffff # main thread
pid 31238's current affinity mask: ffffffffffffffffffff # communication thread
pid 31239's current affinity mask: 40000000
pid 31382's current affinity mask: 80000000
pid 31383's current affinity mask: 100000000 # not limited to 32 cores anymore!
pid 31384's current affinity mask: 200000000 # not limited to 32 cores anymore!
pid 31385's current affinity mask: 400000000 # not limited to 32 cores anymore!
pid 31386's current affinity mask: 800000000 # not limited to 32 cores anymore!
[COLOR="Red"]pid 31387's current affinity mask: 40000000
pid 31388's current affinity mask: 40000000
pid 31389's current affinity mask: 40000000
pid 31390's current affinity mask: 40000000[/COLOR]
[/CODE]


local.txt
[CODE]
WorkerThreads=1
ThreadsPerTest=10
Affinity=0
AffinityScramble2=efghijklmn
[...]
Pid=31317
[/CODE]

[CODE]
pid 31317's current affinity mask: ffffffffffffffffffff # main thread
pid 31408's current affinity mask: ffffffffffffffffffff # communication thread
[COLOR="Red"]pid 31409's current affinity mask: ffffffffffffffffffff
pid 31552's current affinity mask: ffffffffffffffffffff
pid 31553's current affinity mask: ffffffffffffffffffff
pid 31554's current affinity mask: ffffffffffffffffffff
pid 31555's current affinity mask: ffffffffffffffffffff
pid 31556's current affinity mask: ffffffffffffffffffff
pid 31557's current affinity mask: ffffffffffffffffffff
pid 31558's current affinity mask: ffffffffffffffffffff
pid 31559's current affinity mask: ffffffffffffffffffff
pid 31560's current affinity mask: ffffffffffffffffffff[/COLOR]
[/CODE]

in commonb.c line 576 to 589:
[CODE]
for (i = 0; i < MAX_NUM_WORKER_THREADS; i++) {
if (scramble[i] >= '0' && scramble[i] <= '9')
AFFINITY_SCRAMBLE[i] = scramble[i] - '0';
else if (scramble[i] >= 'A' && scramble[i] <= 'Z')
AFFINITY_SCRAMBLE[i] = scramble[i] - 'A' + 10;
else if (scramble[i] >= 'a' && scramble[i] <= 'z')
AFFINITY_SCRAMBLE[i] = scramble[i] - '[B][COLOR="Red"]A[/COLOR][/B]' + 36;
else if (scramble[i] == '(')
AFFINITY_SCRAMBLE[i] = 62;
else if (scramble[i] == ')')
AFFINITY_SCRAMBLE[i] = 63;
else
AFFINITY_SCRAMBLE[i] = i; /* Illegal entry = no mapping */
}
[/CODE]

I guess the red [B][COLOR="Red"]A[/COLOR][/B] should be lowercase, right?

Oliver

[QUOTE=TheJudger;300397]

I guess the red [B][COLOR="Red"]A[/COLOR][/B] should be lowercase, right?

[/QUOTE]


Good catch. The bug effectively limits AffinityScramble's usefulness to 36 cores.

The code would also have "interesting" behavior on a system using EBCDIC. But that's not very likely to occur in the real world. But I could believe some unicode variant doing strange things.

Chris

Modern Linux seems to use /sys/class/power_supply/ instead of /proc/acpi/battery/ -- is there any chance we can have support for Linux battery detection updated?

Looks like you could either examine /sys/class/power_supply/BAT0/status or just /sys/class/power_supply/AC/online ... instead of parsing the old /proc/acpi/battery/BAT0/state, it looks like /sys/class/power_supply/AC/online returns a 0 (battery) or 1 (AC). So this should actually simplify the code a bit, and it will stop us from using a deprecated interface. Anyone using a later 2.6 or any 3.x kernel without the deprecated CONFIG_ACPI_PROCFS_POWER option enabled will not have a /proc/acpi/battery/BAT0/state at all!

I had always wondered why battery detection wasn't working right, and now I know. :) Hopefully it's an easy fix. Let me know if I can be of any assistance in testing. I would be happy to unset that kernel option and check a new build.

[QUOTE=KingKurly;300861]Modern Linux seems to use /sys/class/power_supply/ instead of /proc/acpi/battery/ -- is there any chance we can have support for Linux battery detection updated?

Looks like you could either examine /sys/class/power_supply/BAT0/status or just /sys/class/power_supply/AC/online ... instead of parsing the old /proc/acpi/battery/BAT0/state, it looks like /sys/class/power_supply/AC/online returns a 0 (battery) or 1 (AC). So this should actually simplify the code a bit, and it will stop us from using a deprecated interface. Anyone using a later 2.6 or any 3.x kernel without the deprecated CONFIG_ACPI_PROCFS_POWER option enabled will not have a /proc/acpi/battery/BAT0/state at all!

I had always wondered why battery detection wasn't working right, and now I know. :) Hopefully it's an easy fix. Let me know if I can be of any assistance in testing. I would be happy to unset that kernel option and check a new build.[/QUOTE]Huh, Ubuntu 12.04 (Linux 3.2.x) worked out of the box with the battery detection. I have on idea whether or not Ubuntu sets that option or not though.

[QUOTE=Dubslow;300862]Huh, Ubuntu 12.04 (Linux 3.2.x) worked out of the box with the battery detection. I have on idea whether or not Ubuntu sets that option or not though.[/QUOTE]
Any kernel compiled with the CONFIG_ACPI_PROCFS_POWER option that enables deprecated interfaces will work. I'm proposing that we go ahead and use the proper non-deprecated interface, when available. Ubuntu seems to provide both interfaces (/proc and /sys). To confirm, check: grep ACPI_PROCFS_POWER /boot/config-`uname -r` (Note: those are backticks.)

I don't know why Ubuntu chose to keep that interface around, but I just checked a 10.10 VM that I have and yes, it is enabled there too. On my personal machine, it is not enabled. I am a little surprised that Ubuntu would keep that deprecated code active in a 2012 release, but I guess they would have to support people who don't understand why things that used the old interface suddenly stopped working. :wink: I am reluctant to enable such an option when it is clear that the way forward is through /sys rather than /proc.

[URL]http://cateee.net/lkddb/web-lkddb/ACPI_PROCFS_POWER.html[/URL]

Perhaps we should read from /sys, if that fails then we read from /proc, and if that fails then we assume AC. (Today, we already do exactly that except we don't check /sys first...) The changes to the software should be limited to just a few lines of the OnBattery function in linux/os_routines.c and linux64/os_routines.c (which seem to be identical).

[QUOTE=KingKurly;300880]Ubuntu seems to provide both interfaces (/proc and /sys). To confirm, check: grep ACPI_PROCFS_POWER /boot/config-`uname -r` (Note: those are backticks.)[/quote]
[code]CONFIG_ACPI_PROCFS_POWER=y[/code]
That's Ubuntu 11.04, kernel 2.6; note that 11.04 and 10.10 are old releases, and don't represent 12.04. The laptop I mentioned is now borked, so I can't test 12.04 myself right now.
[/QUOTE]

[QUOTE=KingKurly;300861]Modern Linux seems to use /sys/class/power_supply/ instead of /proc/acpi/battery/ -- is there any chance we can have support for Linux battery detection updated?[/QUOTE]

If anyone can provide updated code for me to include that would be great. The new code should handle both the old and new standards.

12.04 LTS

[CODE]$ grep ACPI_PROCFS_POWER /boot/config-`uname -r`
CONFIG_ACPI_PROCFS_POWER=y
$ uname -a
Linux m 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux[/CODE]

[QUOTE=Prime95;300890]If anyone can provide updated code for me to include that would be great. The new code should handle both the old and new standards.[/QUOTE]
I apologize for any formatting/tabbing/spacing issues in this post. Please ask if any clarification is required. I have tested this solution only on my own machine, so please do not unleash it on an unsuspecting public until you are comfortable with it! :smile:

As part of this section of code in linux/os_routines.c and linux64/os_routines.c:
[CODE]
#elif defined (__linux__)
FILE *fd;
char buf[180];
int ac_state;

ac_state = -1;
fd = fopen ("/proc/acpi/battery/BAT0/state", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
char *p;
p = strstr (buf, "charging state:");
if (p == NULL) continue;
if (strstr (p+14, "discharging") != NULL) ac_state = 0;
else if (strstr (p+14, "charging") != NULL) ac_state = 1;
else if (strstr (p+14, "charged") != NULL) ac_state = 1;
}
fclose (fd);
} ####### NEW CODE GOES HERE ########
return (ac_state == 0);
#else
[/CODE]Insert this:
[CODE] else {
fd = fopen ("/sys/class/power_supply/AC/online", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
ac_state = atoi(buf);
}
}
}
[/CODE]So the final product should look like:

[CODE]
#elif defined (__linux__)
FILE *fd;
char buf[180];
int ac_state;

ac_state = -1;
fd = fopen ("/proc/acpi/battery/BAT0/state", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
char *p;
p = strstr (buf, "charging state:");
if (p == NULL) continue;
if (strstr (p+14, "discharging") != NULL) ac_state = 0;
else if (strstr (p+14, "charging") != NULL) ac_state = 1;
else if (strstr (p+14, "charged") != NULL) ac_state = 1;
}
fclose (fd);
} else {
fd = fopen ("/sys/class/power_supply/AC/online", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
ac_state = atoi(buf);
}
}
}
return (ac_state == 0);
#else
[/CODE]...If you want a quick standalone app to test my changes (and please, do test them on an Ubuntu machine at least!)

[CODE]
/* actest.c, no warranty, etc */

#include <stdio.h>
#define TRUE 1
#define FALSE 0

int onBattery(void);

int main()
{
int battery;
battery = onBattery();
if (battery == TRUE)
printf("BATTERY\n");
else if (battery == FALSE)
printf("AC\n");
else
printf("Uh oh\n");

return 0;
}

int onBattery(void)
{
FILE *fd;
char buf[180];
int ac_state;

ac_state = -1;
fd = fopen ("/proc/acpi/battery/BAT0/state", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
char *p;
p = strstr (buf, "charging state:");
if (p == NULL) continue;
if (strstr (p+14, "discharging") != NULL) ac_state = 0;
else if (strstr (p+14, "charging") != NULL) ac_state = 1;
else if (strstr (p+14, "charged") != NULL) ac_state = 1;
}
fclose (fd);
} else {
fd = fopen ("/sys/class/power_supply/AC/online", "r");
if (fd != NULL) {
while (fgets (buf, sizeof (buf), fd) != NULL) {
ac_state = atoi(buf);
}
}
}
return (ac_state == 0);
}

[/CODE]... I'd have provided a diff of the code instead of putting it out how I did, but I don't know what formats you prefer, and the code should be pretty easy to plug in. I hope. :geek: And if the call to atoi is too slow, there are other ways to do it. The file is simply a 1 or a 0.

I am too used to coding in Ruby; I forgot how picky C is in certain situations...!

[QUOTE=Prime95;300890]If anyone can provide updated code for me to include that would be great. The new code should handle both the old and new standards.[/QUOTE]

Add the red below to os_routines.c, in OnBattery():

[code] FILE *fd;
char buf[180];
int ac_state;

ac_state = -1;
[COLOR="Red"] fd = fopen ("/sys/class/power_supply/AC/online", "r");
if (fd != NULL) {
fscanf(fd, "%d", &ac_state);
fclose (fd);
return (ac_state == 0);
}
[/COLOR] fd = fopen ("/proc/acpi/battery/BAT0/state", "r");
[/CODE]

Note: not tested. But it should be correct.

Prime95: In case it's not obvious from the code, this will attempt the old way first, and then if that didn't work, it will try the new way. You might decide to flip it around. I didn't check how often this gets called, so I don't know how tight it needs to be. Maybe it is worth caching which one exists and using it every time? Or maybe that is overkill.

Everyone: If anyone wants to help out, copy/paste the contents of the last code block (the one labeled actest.c) into a file called actest.c. Change into the directory containing that file and type 'make actest'. Then type './actest' both while on battery and on AC. Results from Ubuntu would be especially appreciated, or perhaps I can convince my stepfather to let me borrow his Ubuntu laptop for a few minutes...

[QUOTE=chalsall;300896]Note: not tested. But it should be correct.[/QUOTE]
Works on my box. I think I like your solution better because it's less code and avoids the call to atoi. You win this round...! :bow:

[QUOTE=KingKurly;300898]You win this round...![/QUOTE]

LOL... You have to love cross posting...

This just shows that in software, like mathematics and life, there is usually more than one way to do something.... :smile:

@KingKurly: :tu:

12.04 LTS:

[CODE]$ gcc -ansi -Wall test.c
test.c: In function ‘onBattery’:
test.c:40:25: warning: implicit declaration of function ‘strstr’ [-Wimplicit-function-declaration]
test.c:40:29: warning: incompatible implicit declaration of built-in function ‘strstr’ [enabled by default]
test.c:51:17: warning: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration]
$ ./a.out
AC[/CODE]We merged in chalsall's code. Unfortunately, we do not have a laptop so we have no way of testing if the battery part works. Sorry!

A note on chalsall's code
 

If the file in /sys/ is opened, then his function is guaranteed to return and not check /proc/. This isn't normally an issue, but as chalsall himself told me, handling the errors is the hard part :smile:

(You never know if you might open a corrupted file or something silly :razz:)

[QUOTE=Dubslow;300909](You never know if you might open a corrupted file or something silly :razz:)[/QUOTE]

Sigh... The code is sane.

Since /sys/ is a virtual file system, opening a "corrupted" file in such a situation would mean you've got much bigger issues on your hands than possibly mis-detecting if you're on AC or battery....

Odd observations from my stepfather's laptop... it was upgraded to Ubuntu 12.04 LTS not too long ago. For /sys/class/power_supply/AC/online it uses ACAD instead of AC. And for /proc/acpi/battery/BAT0/state it has BAT1 instead of BAT0.

A few problems here. First, the old code wouldn't work on his laptop. Second, the new code wouldn't work either. Hrmm... what the heck?

The kernel was 3.2.0-24-generic.

Can anyone else confirm these findings? (Look in /sys/class/power_supply and /proc/acpi/battery)

Edit: I don't think it's a safe assumption that the contents of /proc/acpi/battery/BAT0/state are smaller than 180 bytes. Is the code not making that assumption? (I'm mildly rusty on my C.)

A feature request. I like the newer version of throttle where you specify the percent of time you want to be running. In Multi core systems where memory may be a bottleneck is it possible to stagger the periods of rest between cores? So if I am running 50 throttle I want one core to be running Prime95 half the time and the other core for the rest. Right now both cores run together and rest together.

A friend of mine took a look at the battery detection code and came up with this rendition: [url]https://gist.github.com/60de973a828979a17253#gistcomment-338482[/url]

I haven't yet checked how often the battery gets polled... that makes quite a difference in how this should be done.

To sleep, for me.

[QUOTE=KingKurly;300928]A friend of mine took a look at the battery detection code and came up with this rendition: [url]https://gist.github.com/60de973a828979a17253#gistcomment-338482[/url]

I haven't yet checked how often the battery gets polled... that makes quite a difference in how this should be done.

To sleep, for me.[/QUOTE]

On my laptop, "a few minutes" would be a perfect description of about how long it took to recognize changes. A decent guess would then be that it checks every five minutes.

[QUOTE]So if I am running 50 throttle I want one core to be running Prime95 half the time and the other core for the rest. Right now both cores run together and rest together.[/QUOTE][url]http://www.mersenneforum.org/showthread.php?t=12286[/url]

[QUOTE=Dubslow;300930]On my laptop, "a few minutes" would be a perfect description of about how long it took to recognize changes. A decent guess would then be that it checks every five minutes.[/QUOTE]
I decided to look at the code. Looks like every 15 seconds.
[CODE]
./commonc.h:#define TE_BATTERY_CHECK_FREQ 15 /* Check battery every 15 sec. */
./commonb.c: add_timed_event (TE_BATTERY_CHECK, TE_BATTERY_CHECK_FREQ);
[/CODE]

Limits for p in v 27.7
 

what are the limits for p in 2^p - 1 = Mersenne prime? What is the highest number that I can test?

[QUOTE=antimaths;301201]what are the limits for p in 2^p - 1 = Mersenne prime?[/quote]From the source, /gwnum/gwnum.h:[code]/* Some mis-named #defines that describe the maximum Mersenne number */
/* exponent that the gwnum routines can process. */

#define MAX_PRIME 79300000L /* Maximum number of x87 bits */
#define MAX_PRIME_SSE2 595800000L /* SSE2 bit limit */
#define MAX_PRIME_AVX 595800000L /* AVX bit limit */
#define MAX_FFTLEN 4194304L /* 4M FFT max for x87 */
#define MAX_FFTLEN_SSE2 33554432L /* 32M FFT max for SSE2 */
#define MAX_FFTLEN_AVX 33554432L /* 32M FFT max for AVX */[/code]

[QUOTE=antimaths;301201]What is the highest number that I can test?[/QUOTE]Assuming you have a CPU capable of SSE2/AVX, [url=http://mersenne-aries.sili.net/M595799999]M595,799,999[/url], but since that's already got 2 known factors [url=http://mersenne-aries.sili.net/M595799947]M595,799,947[/url] would make more sense. Of course, it takes 16THz-days to do a single L-L test on that exponent (anywhere from 2-5+ years on a modern CPU).

Hi everyone. I'm seeing some strange behaviour, at least v26 used to work fine with this. If I have a worktodo.ini file that looks like this:

[CODE]Pminus1=1,2,8700011,1,150000,"3"
Pminus1=1,2,8700031,1,150000,"3"[/CODE]

v27.7 using an AVX core will process the exponent with P-1, it ignores the "3" at the end telling Prime95 it has a factor of 3 and reports:

[CODE]P-1 found a factor in stage #2, B1=150000, B2=15000000, E=12.
UID: ANONYMOUS, 2^8700011+1 has a factor: 3
[/CODE]

I'm pretty sure this used to work in v26. The other thing that happens is that the worktodo.ini file gets re-written and I lose the "3" on everything:

[QUOTE]Pminus1=1,2,8700031,1,150000,0[/QUOTE]

What am I doing wrong. Did things change in v27.7, how do I complete what I used to be able to do? The readme.txt file still shows that a comma separated list of known factors is between quotes.

[QUOTE=Jeff Gilchrist;301700]What am I doing wrong. Did things change in v27.7, how do I complete what I used to be able to do? The readme.txt file still shows that a comma separated list of known factors is between quotes.[/QUOTE]The readme.txt version appears to be wrong:[quote]Pminus1=k,b,n,c[,"comma-separated-list-of-known-factors"][/quote]The correct version appears in whatsnew.txt under v26.5:[quote]Pminus1=k,b,n,c,B1,B2[,how_far_factored][,B2_start][,"factors"][/quote]

FFT tables?
 

I was looking through the AVX yjmp tables for the FFT lengths you use, and I didn't realize until just now that there are [i]two[/i] yjmp tables, each with slightly different information. The first is "yjmptable DD 0", and the second is "yjmptablep DD 0"; is the second for P-1 or something?

The major difference I noticed is that some lengths appear to be missing from the second; the first has 2000K, 2016K, 2016K, lots of 2M, 2240K, 2240K, lots of 2304K, while the second skips 2000K, 2016K, and 2240K completely, and has a lot fewer entries under 2304K. I didn't check the other lengths, though I'd guess there are similar differences throughout the tables. Why?

Edit: It seems from a perfunctory glance the the lengths missing from the second table are those which are not 7-smooth. What would that change?

One table for k*b^n-c calculations, the other for k*b^n+c calculations.

I don't know whether I should be worried or not, but it ran a few iterations just now to check the roundoff error before starting a new P-1 on my machine and the roundoff error it was usin as a base was 0.24275. It said if it was higher than that, a bigger FFT would be used. All the 1,000 iterations had a roundoff error of over 0.25xxx. Should I be worried alot? The exponent in question was 55288637.

No, that's perfectly normal.

That just means that the FFT selection was risky, so that's why Prime95 ran the test; when the test finished, it decided that the small/aggressive length was too risky.

That's the so called "soft crossover" -- between all FFT lengths is a range of a few thousand exponents which try the smaller FFT, but which might need use the larger FFT depending on hardware.

Without such a test, George would have to use a "hard crossover" which is a clear line between two lengths, but that line would have to be pretty low to guarantee it would work for all hardware, which means some hardware might not use the most efficient length.

(PS Thanks George :smile:)

Thank you for the fast response. I think that, and I know i've not been doing this long even including all the time put together leaving out the times I temporarily quit, this may be the first time i saw that happen, or at least caught it being on my screen.

prime 95 problem
 

after two minutes i start prime 95 blend test, my cpu usage still stay at 100% but my multiplyer start to go up and down.... just wanna ask is that normal.

for your info i have a overcloked 2500k ...cpu voltage was set at 1.245v ..

Yes, that's normal. Almost all CPUs have a function called Turbo Boost, where if your CPU hasn't been doing anything but then jumps to 100% usage, it will increase the multiplier past the usual point; after a few minutes at 100%, there's too much heat, and Turbo Boost deactivates and the multiplier drops back to the base line.

For a non-overclocked 2500K, the baseline multiplier is 33, so speed = 3.3 GHz. This may or may not be your baseline, depending on how you did the overclock.

I'm not sure if this is a bug, but stopping all workers will cause those running to display a superfluous "Resuming worker at user request" line:

[QUOTE][Jul 13 14:47] M56479121 stage 1 is 10.02% complete. Time: 17.976 sec.
[Jul 13 14:47] M56479121 stage 1 is 10.08% complete. Time: 18.237 sec.
[Jul 13 14:48] M56479121 stage 1 is 10.15% complete. Time: 18.213 sec.
[Jul 13 14:48] M56479121 stage 1 is 10.21% complete. Time: 20.183 sec.
[Jul 13 14:48] Stopping worker at user request.
[Jul 13 14:57] Resuming worker at user request.
[Jul 13 14:57] Worker stopped.[/QUOTE]

[QUOTE=ixfd64;304673]I'm not sure if this is a bug, but stopping all workers will cause those running to display a superfluous "Resuming worker at user request" line:[/QUOTE]

It isn't a bug but certainly qualifies as an ugliness. It results from prime95 originally being designed to run without multi-threading in mind (one worker window). After multi-threading was wedged in, the "i'd like to stop and start specific windows" feature was added as a wart on top of a wart.

I can probably find a way to bypass the offending output. However, the equally ugly wart where start just one worker outputs starting and stopping messages in all other worker windows will be a bit harder.

How do I change (increase) the default FFT size for LL?
 

I have troubles with 4 expos in the 45M area, p95 is trying to LL them with 2400k and always fail somewhere between 35% and 50% of the work, telling me that "some error" appeared, which is "not hardware" because is "reproducible" (:P) and the "confidence is low". As I don't feel confident myself with such stuff on screen, killed everything, deleted all temp files, started again. Same story. I think I need to increase the FFT. So, how can I teach p95 to use a larger FFT in this area?

(edit: CL selects 2480k for this range, which works fine, but is slower then the "manual tuned" one, 2592k, which is about 15% faster on gtx580. I would like to "play" with this selection for p95 too, if it is possible)

Test=N/A,FFT2=2480K,45xxxxxx,72,1

[QUOTE=Dubslow;304818]Test=N/A,FFT2=2480K,45xxxxxx,72,1[/QUOTE]
Thanks. Unfortunately, the problem is not there. It seems that old bug of p95 is still not solved:
[CODE][Thu Jul 19 18:10:31 2012]
Iteration 9000000 / 45487279
M45487279 interim We4 residue DC2998592C8F8E27 at iteration 9000000
M45487279 interim We4 residue B7FE9F1B55C2199D at iteration 9000001
M45487279 interim We4 residue 2E2CEE049ED14D2C at iteration 9000002
[Thu Jul 19 18:17:07 2012]
Iteration 9000000 / 45502937
M45502937 interim We4 residue 44D0C96A87C14E92 at iteration 9000000
M45502937 interim We4 residue 5788E205D7003EED at iteration 9000001
M45502937 interim We4 residue 3E3E082E7D85BF02 at iteration 9000002
[Thu Jul 19 19:45:51 2012]
Iteration 9000000 / 45463799
M45463799 interim We4 residue 26F03738AA9A4E88 at iteration 9000000
M45463799 interim We4 residue 3C14C10E7396B46B at iteration 9000001
M45463799 interim We4 residue 1C163E6C41506F5D at iteration 9000002
[Fri Jul 20 07:46:29 2012]
Iteration: 9076902/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Iteration: 9076902/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076903/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076904/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076905/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076906/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076907/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076908/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076909/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076910/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076911/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076912/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076913/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076914/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076915/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076916/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076917/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076918/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076919/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076920/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076921/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
Continuing from last save file.
Iteration: 9076922/45487279, ERROR: ROUND OFF (244419.1983) > 0.40
Continuing from last save file.
Disregard last error. Result is reproducible and thus not a hardware problem.
For added safety, redoing iteration using a slower, more reliable method.
[/CODE]

then about 8-9 MegaBytes of this same crap follows, rendering one of the 4 workers completely unprofitable for all the day (last 13-14 hours since I left the kbd).

Any clue?

[QUOTE=LaurV;305245]ERROR: ROUND OFF (244419.1983) > 0.40[/QUOTE]That seems very suspicious: It's not slightly too large as would normally be the case (e.g. "0.45 > 0.40"), it's half a million times too large.

One other user reported the same symptoms. A stable computer one day starts spitting out massive roundoff errors. He deleted the save files restarted and has had no trouble since.

All signs point to a bug in prime95 but I could not reproduce it from his save files.

Do you remember if you did anything unusual before this started happening?

[QUOTE=Prime95;305260]One other user reported the same symptoms. A stable computer one day starts spitting out massive roundoff errors. He deleted the save files restarted and has had no trouble since.

All signs point to a bug in prime95 but I could not reproduce it from his save files.

Do you remember if you did anything unusual before this started happening?[/QUOTE]
I remember that discussion but I can't find the thread. There was something with the initialization of the variables, and this symptom I have is certainly related to restarts. I am still digging on it. If P95 is not stopped/resumed, it runs. After stop+continue, or exit+restart, one or two of the workers start to display the "low confidence" story. If I kick it out with task manager, it may start correctly after many retries. If I stop it with test/stop or test/exit (so it rewrites the temp files) it will continue to display the "confidence" message. Now I did the mistake to use "stop" and I lost all the work for the worker 4, every restart came with 3 workers working, and one cycling through the story in the code tags above. I deleted the temp files of the 4th worker. Restart P95. 4th worker works fine (but from scratch!) and... now the third worker starts displaying the "confidence" shit. Trying to use debug switches.

The confidence crap is normal. It just says that sometime during the LL test some bad errors were happening.

What I need to know is did you do anything unusual right before it started giving you those big roundoff errors. One more thing are these multi-threaded workers?

[QUOTE=LaurV;305262]I remember that discussion but I can't find the [URL="http://mersenneforum.org/showthread.php?t=16751&page=2"]thread[/URL].[/QUOTE]

That roundoff bug was apparently only for really small FFTs, though this evidence suggests otherwise.

@Dubslow: exactly, that was, thanks. I am reading into it.

@George: yes, I know the "crap" is normal, just telling the story FYI.
I don't remember doing anything unusual. I will watch for it more careful next time. Now I had to restart from scratch the workers 3 and 4. First two workers still survive. Of course, I lost the behavior and can't reconstruct it anymore, but be at easy, it will come back! :sad: Usually at 35-50% (the workers which survived are now are about 28-30%).

Something is wrong since I switched the version, looking back I have these 45M expos assigned from GPU272 about the same period (March-April) and never been able to finish them. I did plenty of other things meantime, but the 45M expos never finished, they always returned with errors, I always had to restart them, and I always (incorrectly) blamed the "bad FF size", even asked the forum for help about it.

Yes, [B]these were multi-threaded workers[/B], 4 workers on i7-2600K, each having 2 threads, and using a full physical core with helper (HT enabled). Also, the "roundoff" and "sum(inputs)" error checking were enabled ("checked" on the P95 menu). According with the log, the error appeared few minutes after a p95 restart. I later tried with or without the "error check" options (both, combination) and with or without multi-threading, the errors still appeared, but maybe that was because the files were already corrupted. Interesting is that the test was somehow progressing, P95 used the "slow method" every time, and the iteration number was still increasing, snail-speed.

Anyhow, I will bother you next time, I would like to hope that you got rid of me, but the realistic part of me says the error will be back. If I can do something to help you diagnose the cause, please tell me. I still don't get it what the debug switch is doing exactly. I expected a more verbose message/log, but it wasn't the case.

[QUOTE=Prime95;305260]One other user reported the same symptoms. A stable computer one day starts spitting out massive roundoff errors. He deleted the save files restarted and has had no trouble since.

All signs point to a bug in prime95 but I could not reproduce it from his save files.

Do you remember if you did anything unusual before this started happening?[/QUOTE]

I had this issue too on MacOS X. I was doing a transcode of MP3's to AAC of a large batch of podcasts with iTunes (before tagging the AAC files a bookmark-able). It caused the errors, but I was only like 20% in, so I deleted the save files and it hasn't returned. But I also haven't done any more transcodes and the log files I have I can't find the errors in.

I'm on an i7, 1 worker, smart affinity, 4 threads.

[OT] what is the prefered work for CPU ? LL, p-1, ecm .....?
MT work or only 1 thread because of performance reasons ?[OT]



Norman

NormanRKN, it all depends on your specific system.

[QUOTE=NormanRKN;306916][OT] what is the prefered work for CPU ? LL, p-1, ecm .....?[/QUOTE]TF runs very well on a GPU; LL can also run on a GPU. P-1 and ECM are both currently CPU-only. Note that ECM doesn't contribute directly to GIMPS throughput (since it's only run on candidates that have already been proved not-prime with LL tests). From that perspective, it's most efficient not to use CPUs for TF, and to restrict them to P-1 and/or LL. P-1 requires at least a modest allocation of RAM (1GB or more is good) whereas LL does not.

It's probably not version-specific, but can't you do something about how the program terminates? I only use it for stress-testing, but sometimes it simply disappears instead of giving out an error. There are never any entries in Event Log either, so I don't even know what happened.


OR possibly shorten the minimal time interval for logging. I noticed minimum is 10 minutes - unless this option is completely unrelated to results.txt of course.

Just to make sure: has anyone else had Prime crash (disappear instantly) without any apparent reason on Ivy Bridge class CPU? Namely 3770K.
I am this close to blame the program, because it doesn't seem possible it's unstable at this point (Turbo off and overvolted a bit).

Before blaming the software try reading the "possible hardware failure" from the "readme.txt" and the last "Q"s from the FAQ section in "stress.txt".

[QUOTE]FREQUENTLY ASKED QUESTIONS
--------------------------

Q) My machine is not overclocked. If I'm getting an error, then there must
be a bug in the program, right?

A) The torture test is comparing your machines results against
KNOWN CORRECT RESULTS. If your machine cannot generate correct
results, you have a hardware problem. HOWEVER, if you are failing
the torture test in the SAME SPOT with the SAME ERROR MESSAGE
every time, then ask for help at [url]http://mersenneforum.org[/url] - it is
possible that a recent change to the torture test code may have
introduced a software bug.

Q) How long should I run the torture test?

A) I recommend running it for somewhere between 6 and 24 hours.
The program has been known to fail only after several hours and in
some cases several weeks of operation. In most cases though, it will
fail within a few minutes on a flaky machine.

Q) Prime95 reports errors during the torture test, but other stability
tests don't. Do I have a problem?

A) Yes, you've reached the point where your machine has been
pushed just beyond its limits. Follow the recommendations above
to make your machine 100% stable or decide to live with a
machine that could have problems in rare circumstances.

Q) A forum member said "Don't bother with prime95, it always pukes on me,
and my system is stable!. What do you make of that?"

or

"We had a server at work that ran for 2 MONTHS straight, without a reboot
I installed Prime95 on it and ran it - a couple minutes later I get an error.
You are going to tell me that the server wasn't stable?"

A) These users obviously do not subscribe to the 100% rock solid
school of thought. THEIR MACHINES DO HAVE HARDWARE PROBLEMS.
But since they are not presently running any programs that reveal
the hardware problem, the machines are quite stable. As long as
these machines never run a program that uncovers the hardware problem,
then the machines will continue to be stable.
[/QUOTE]

I would blame the hardware first. Do you overclock? Do you have a temperature monitoring software? What does it say? Try using "throttle=80" (or about) in prime.txt, etc. Try to insulate the problem, if it is a software bug it should be "regular" or easier to spot. That is why is better to do "real assignments", even if you are only interested in stress testing. I do a lot of stress testing (making a living working for a hardware developer) and I use real assignments for that. With "torture test" from the menu you do not help the project, it is not so much fun, and you have no chance to get any money. With real assignments is more fun, you help GIMPS, and if you are tremendous lucky, then you can get some money too... Moreover, real assignments "bugs" are "repeatable". You save often and when the bug occur, you restart from the last save. If there is a software bug it should be highly reproducible.

[QUOTE=LaurV;307205]You save often and when the bug occur, you restart from the last save. If there is a software bug it should be highly reproducible.[/QUOTE]
Keep in mind that you and someone else have reported (non-fatal) errors, as well as [URL="http://www.mersenneforum.org/showthread.php?t=17036"]this thread[/URL] (which is probably in the wrong forum). (Btw, the thread I linked is looking for someone else to reproduce a crash -- it seems to be Windows specific, so I can't help, but maybe you can, LaurV?)

[QUOTE=Dubslow;307206] but maybe you can, LaurV?)[/QUOTE]
I don't know how other people do, but for me the applications do not crash :razz:
The bug you linked is definitely related to the one I reported few posts above in this thread, where P95 was generated rounding errors on the order of magnitude into millions (and not 0.5 or so). After George asked me if I hyperthread (multithread) I started to pay more attention to it. The reproducibility of those errors involve a mixture of: AVX, multithreading, "special" overclocking, restarting of P95 (or stop/resume), range of the exponent in LL test. I am still not clear what's going on, and now my efforts are concentrated on a different exponent range, where it seems the error does not appear. Certainly the problem is related to AVX, as using SSE does not show the "confidence" error, no matter what I do in rest, including HT. Certainly is related to HT too: if I use single threads, the error does not appear, no matter what I do in rest, including use AVX. It is also related to overclocking, but only a range of clocks can reproduce the error. Lower or higher (!?) clocks have a LOWER error rate (that is why I said "special" above). Also, it seems that the rounding error appears only when I play with start/stop. If I let it running and do not touch the P95 program, then no error appears. It also seems to appear more on the 45M range of the exponents, but this is not relevant because the only comparison term is 26-30M (i.e. I did not get assignments higher then 45M yet and it may be directly dependent on size, I don't know the behavior for higher sizes).

I don't have time to dig for it until weekend. Quite busy here around. I moved the LL exponents to the end of the worktodo and I am now doing DC with that computer, no HT, overclocked to 4.2G (from stock 3.4G). The DCs seem to go smooth, no errors, and I have a way to check at the end, by comparing with the original residues. Up to now I did not get any P95 DC mismatch from this computer with v27 (about 20-30 runs times 4 cores).

You know what? I feel stupid now.
I realized I was using version 27.6 which I did not know! I always update my tools as new versions become available, and somehow this slipped through my fingers. Checking changelog, boom - it WAS buggged!
I should have guessed and payed more attention to the crashes - they happened almost after the same time, a bit under 3 hours.

[QUOTE=LaurV;307211]I don't know how other people do, but for me the applications do not crash :razz:
The bug you linked is definitely related to the one I reported few posts above in this thread, where P95 was generated rounding errors on the order of magnitude into millions (and not 0.5 or so)... [/QUOTE]

That thread indicates a specific FFT length (3200K) to be the problem.

We noticed, while setting up a few boxes, that Mprime embeds a weird "^F" character into prime.txt if you use a proxy.

We do not know if this causes any problems or anything. It is easy to delete with vim.

:featurebug:

Hm... didn't do that for me.

[QUOTE=Xyzzy;307260]We do not know if this causes any problems or anything. It is easy to delete with vim.[/QUOTE]

I've seen that myself in the past. Don't know why. It won't cause any problems.

As an aside, it's a good thing the proxy is smart about handling the case where a user isn't known yet.... :wink:

[QUOTE]As an aside, it's a good thing the proxy is smart about handling the case where a user isn't known yet.... :wink:[/QUOTE]We edited our username out of the image.

Would it have worked without a username? If so, that is cool!

[QUOTE=Xyzzy;307280]Would it have worked without a username? If so, that is cool![/QUOTE]

No... The Primenet username is needed. However, the GPU72 proxy isn't supposed to be publicly known yet.... :wink:

[QUOTE]No... The Primenet username is needed. However, the GPU72 proxy isn't supposed to be publicly known yet.... :wink:[/QUOTE]:kitten:

Hi,

I have some specific problems with the 3200K FFT test running on my Sandy Bridge Core i7 2600K.
I think it is Hyper-threading related on Windows XP (32-bit) platform ([URL]http://www.mersenneforum.org/showthread.php?t=17036[/URL]).

Memory is OK (8 GB physical tested with Memtest > 48h)
CPU temperature is OK : about 60°C running Prime with a Noctua NH-U12P SE2

Other Self-tests (other than 3200K FFT) can run for hours. 3200K test crashes within some minutes: No rounding error in Prime95 console but OS memory access error.

Running my SB 2600K with Hyper-threading enabled overclocked at 4400 or 4500MHz on Linux 64-bit gives a similar error :

[CODE]/var/log/kern.log:Aug 6 21:09:47 Gigabyte-linux kernel: [ 1549.289956] mprime[2877] general protection ip:9db289 sp:7fe3f32506d0 error:0 in mprime[400000+1d0b000]
/var/log/kern.log:Aug 6 23:32:46 Gigabyte-linux kernel: [ 4804.983166] mprime[2525] general protection ip:99c28c sp:7f342f949270 error:0 in mprime[400000+1d0b000]
/var/log/kern.log:Aug 7 06:54:40 Gigabyte-linux kernel: [31293.049624] mprime[2857] general protection ip:99a80c sp:7f7293b296c0 error:0 in mprime[400000+1d0b000]
/var/log/kern.log:Aug 7 22:29:36 Gigabyte-linux kernel: [ 415.393643] mprime[2542] general protection ip:99c28c sp:7fe9c6edd6c0 error:0 in mprime[400000+1d0b000][/CODE]It is as if Prime95 tries to use an invalid pointer variable (memory not in process pool or invalid R/W rights).


Today I am benching Hyper-threading at 4300MHz on Linux 64-bit to see if 3200K test is stable…
[FONT=&quot]
[/FONT]

[QUOTE=Laurent;307331]

Other Self-tests (other than 3200K FFT) can run for hours. 3200K test crashes within some minutes: [/QUOTE]

Does it also crash if you use less memory or in-place 3200K FFTs?

I mande some new tests (Sandy Bridge i7 2600K, Hyper-threading enabled) :

CPU overclocked @ 4300MHz, Linux 64-bit, Prime95 4224MB tested -> Pass (running > 11h)

CPU base clock, Windows XP 32-bit, Prime95 In-place large FFT -> Pass (running > 3h)
CPU base clock, Windows XP 32-bit, Prime95 1600MB tested -> Pass
CPU base clock, Windows XP 32-bit, Prime95 2926MB tested -> Crash after 2 min