Prime95 version 26.3

[otutusaus]

Originally Posted by joblack

It could be the enabled Turbo Core option (overclocks some of your cores temporarily if not all cores are used). Disable the TC option in the BIOS and try again.

I wouldn't think the Turbo Core is the reason behind it, since all worker times get better at the same time. If it was some of the cores would be temporarily overclocked, only one or two workers max would improve their timings.

[otutusaus]

Originally Posted by cheesehead

I think you'd find that with the next-lower FFT size, you'd get round-off errors in the not-so-safe range.

I suggested so because p64 v26.3 was reporting a fairly low average round-off error (0.044836) when testing 2400K FFT on M46080959 (maybe too low for a exponent so close to the FFT crossover point). I thought a lower FFT size (2240K) would be still safe. However, this version had a bug where FFT could not be manually set.
When moving to version 26.4, the error is now 0.2281 for 2400K FFT on M46080959 (makes more sense), so apparently v26.3 was reporting a wrong average round-off error.
Sure enough, when I tried a lower FFT, round-off error was unacceptable.

I would say v26.3 has a bug when calculating the average round-off error for exponents near the FFT crossover point.

Originally Posted by cheesehead

In GIMPS's case, the nature of the L-L computation means that we cannot afford to have even a single off-by-1 result in quadrillions of operations, so we have to be extremely cautious about roundoff errors.

I totally agree. Speed with safety.

Thanks for such the complete explanation!

[Prime95]

Originally Posted by otutusaus

I suggested so because p64 v26.3 was reporting a fairly low average round-off error (0.044836) when testing 2400K FFT on M46080959 (maybe too low for a exponent so close to the FFT crossover point). I thought a lower FFT size (2240K) would be still safe. However, this version had a bug where FFT could not be manually set.
When moving to version 26.4, the error is now 0.2281 for 2400K FFT on M46080959 (makes more sense), so apparently v26.3 was reporting a wrong average round-off error.
Sure enough, when I tried a lower FFT, round-off error was unacceptable.

Yes, the same bug that would not let you choose the smaller 2240K FFT also affected the code that tested the average roundoff error. In essence, 26.3 reported the average roundoff error for the larger 2400K FFT rather than the smaller 2240K FFT.

This could cause problems when you upgrade from version 26.2/26.3 to version 26.4 If your worktodo.txt file has any FFT2=xxxx values, you should delete that clause so that the FFT size is properly selected using the corrected average roundoff check in 26.4.

[sgrupp]

Same deal -
this wasnt happening on this system when i was running 25.11 and now I am getting these errors continuously, but only on this one worker. The other 3 are all fine.

[Nov 21 08:51] Waiting 10 seconds to stagger worker starts.
[Nov 21 08:52] Worker starting
[Nov 21 08:52] Setting affinity to run worker on logical CPUs 4,5
[Nov 21 08:52] Setting affinity to run helper thread 1 on logical CPUs 4,5
[Nov 21 08:52] Resuming primality test of M49040417 using Core2 type-3 FFT length 2560K, Pass1=640, Pass2=4K, 2 threads
[Nov 21 08:52] Iteration: 48810291 / 49040417 [99.53%].
[Nov 21 08:52] Possible hardware errors have occurred during the test!
[Nov 21 08:52] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Nov 21 08:52] Confidence in final result is fair.
[Nov 21 08:52] Iteration: 48811000 / 49040417 [99.53%]. Per iteration time: 0.058 sec.
[Nov 21 08:52] Possible hardware errors have occurred during the test!
[Nov 21 08:52] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Nov 21 08:52] Confidence in final result is fair.
[Nov 21 08:53] Iteration: 48812000 / 49040417 [99.53%]. Per iteration time: 0.059 sec.
[Nov 21 08:53] Possible hardware errors have occurred during the test!
[Nov 21 08:53] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Nov 21 08:53] Confidence in final result is fair.
[Nov 21 08:54] Iteration: 48813000 / 49040417 [99.53%]. Per iteration time: 0.059 sec.
[Nov 21 08:54] Possible hardware errors have occurred during the test!
[Nov 21 08:54] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Nov 21 08:54] Confidence in final result is fair.

[Prime95]

Originally Posted by sgrupp

Same deal -
this wasnt happening on this system when i was running 25.11 and now I am getting these errors continuously, but only on this one worker. The other 3 are all fine.

[Nov 21 08:52] Iteration: 48810291 / 49040417 [99.53%].
[Nov 21 08:52] Possible hardware errors have occurred during the test!
[Nov 21 08:52] 1 SUM(INPUTS) != SUM(OUTPUTS).
[Nov 21 08:52] Confidence in final result is fair.

This is normal -- a result of a new "feature" in v26. In v25, one would get a SUM(INPUTS) error or ROUNDOFF > 0.4 error and it would scroll off the screen unnoticed. You had to go to the effort of looking in results.txt to see that you had a problem.

In v26, every time prime95 does its regular screen update it prints out a summary of the total number of errors that occurred during the test. See undoc.txt for options on controlling this new feature.

So, one of your workers had an SUM(INPUTS) error sometime during the test. Since it only happened once there is a fair chance that your LL result will be OK.

[Rhyled]

In new thread: http://mersenneforum.org/showthread.php?t=14198

[Mr. P-1]

Originally Posted by petrw1

I don't have definitive research yet but I do know that (to a point) the more primes it processes in one pass the less overall time the P-1 takes.

So in my experience if a P-1 with enough memory allocated to do 10 primes in a pass takes 30 hours for stage 2 then it will take in the order of 25 hours if I increase the memory to process 20 primes in a pass, etc ... until at some point the we get to what was referred to in another related thread the "knee in the curve".

My understanding is that the fewer passes it makes, the less overall time, but increasing (or decreasing) the available memory makes no difference unless it changes the number of passes.

In your example, increasing the number of primes per pass from 10 to 20 would certainly reduce the number of passes.

[ckdo]

Originally Posted by Commaster

ckdo, at my place, they don't destroy save files, but use <>.bu, <>_2.bu, <>_3.bu and so on. (Checked while ECM-ing same exponent)

There's evidently still some confusion of assignments going on, client side or server side. From my assignments report:

tycho | 0 | 2097152 | ECM | C1S1, 34.70% | 2010-11-18 16:55
tycho | 1 | 2097152 | ECM | C1S1, 34.70% | 2010-11-18 16:55
tycho | 1 | 8388608 | ECM | C1S2, 2.60%  | 2010-11-10 13:05
tycho | 0 | 8388608 | ECM | C1S2, 2.60%  | 2010-11-10 13:20

The progress as reported is obviously correct for only one of each pair of assignments, but I can't say which...

tycho is "1 AMD Athlon 64 X2 Dual Core 5200+ Windows,Prime95,v26.3,build 3"

[Commaster]

ckdo, seems really weird to me as I expirienced proper reporting since "bad" old 25.x, not only 26.x... Could you please check the ammount of .bu files and their names?

[ckdo]

Will eventually get my hands on the machine around Xmas...

[ckdo]

The problem is seemingly caused by a single worker having multiple assignments for the same exponent:

[Worker #1 Dec 11 00:40] M5503 curve 3 stage 1 at prime 38188361 [86.79%]. Time: 227.844 sec.
[Worker #1 Dec 11 00:43] Stage 1 complete. 1152466613 transforms, 1 modular inverses. Time: 175.551 sec.
[Worker #1 Dec 11 00:43] Exceeded limit on number of workers that can use lots of memory.
[Worker #1 Dec 11 00:43] Looking for work that uses less memory.
[Worker #1 Dec 11 00:43] Using FFT length 256
[Worker #1 Dec 11 00:43] ECM on M5503: curve #3 with s=1468314190752564, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:43] Stage 1 complete. 41 transforms, 1 modular inverses. Time: 0.004 sec.
[Worker #1 Dec 11 00:43] Exceeded limit on number of workers that can use lots of memory.
[Worker #1 Dec 11 00:43] Looking for work that uses less memory.
[Worker #1 Dec 11 00:43] Using FFT length 256
[Worker #1 Dec 11 00:43] ECM on M5503: curve #3 with s=1468314190752564, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:43] Stage 1 complete. 41 transforms, 1 modular inverses. Time: 0.004 sec.
[Worker #1 Dec 11 00:43] Exceeded limit on number of workers that can use lots of memory.
[Worker #1 Dec 11 00:43] Looking for work that uses less memory.
[Worker #1 Dec 11 00:43] Using FFT length 256
[Worker #1 Dec 11 00:43] ECM on M5503: curve #3 with s=1468314190752564, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:43] Stage 1 complete. 41 transforms, 1 modular inverses. Time: 0.004 sec.
[Worker #1 Dec 11 00:43] Exceeded limit on number of workers that can use lots of memory.
[Worker #1 Dec 11 00:43] Looking for work that uses less memory.
[Worker #1 Dec 11 00:43] Using FFT length 256
[Worker #1 Dec 11 00:43] ECM on M5503: curve #3 with s=1468314190752564, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:43] Stage 1 complete. 41 transforms, 1 modular inverses. Time: 0.004 sec.
[Worker #1 Dec 11 00:43] Exceeded limit on number of workers that can use lots of memory.
[Worker #1 Dec 11 00:43] Looking for work that uses less memory.
[Worker #1 Dec 11 00:43] Using FFT length 320
[Worker #1 Dec 11 00:43] ECM on M5839: curve #1 with s=8803628047987717, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:47] M5839 curve 1 stage 1 at prime 7658491 [17.40%]. Time: 276.189 sec.
[Worker #1 Dec 11 00:49] Restarting worker with new memory settings.
[Worker #1 Dec 11 00:49] Using FFT length 256
[Worker #1 Dec 11 00:49] ECM on M5503: curve #3 with s=1468314190752564, B1=44000000, B2=4400000000
[Worker #1 Dec 11 00:49] Stage 1 complete. 41 transforms, 1 modular inverses. Time: 0.004 sec.
[Worker #1 Dec 11 00:49] Using 159MB of memory in stage 2.
[Worker #1 Dec 11 00:49] Stage 2 init complete. 545949 transforms, 1 modular inverses. Time: 0.639 sec.
[Worker #1 Dec 11 00:49] M5503 curve 3 stage 2 at prime 44111773 [0.00%].
[Worker #1 Dec 11 00:53] M5503 curve 3 stage 2 at prime 2390771531 [53.87%]. Time: 241.460 sec.
[Worker #1 Dec 11 00:56] Stage 2 complete. 363084988 transforms, 1 modular inverses. Time: 198.795 sec.
[Worker #1 Dec 11 00:56] Stage 2 GCD complete. Time: 0.001 sec.
[Worker #1 Dec 11 00:56] ECM on M5503: curve #4 with s=5172206416358876, B1=44000000, B2=4400000000
[Worker #1 Dec 11 01:00] M5503 curve 4 stage 1 at prime 7658473 [17.40%]. Time: 218.273 sec.

Worker #1 has 5 ECM assignments of 19 curves each on M5503. Progress reported on all but the first is wrong.