[QUOTE=pepi37;350562]Every result of Prime95 is in format ( using Prime95 for PRP test)

x*xx^xxxxxxx-1 is not prime. RES64: E57D7936A6CAACCC. We4: 9A9ABA99,00000000

Can output be without [U]We4: 9A9ABA99,00000000 ?
[/U]And if can what option to use?[/QUOTE]
[FONT="Courier New"]sed 's: W.*::' < results.txt > myPRPresults.txt[/FONT]

[QUOTE=Batalov;350588][FONT=Courier New]sed 's: W.*::' < results.txt > myPRPresults.txt[/FONT][/QUOTE]

Currently, I use method similar to yours
Thanks for answer :)

Would like to report a prime95 bug.
Running ECM, once a factor is found the program continues to use the CPU but the program becomes unresponsive.

Happens for 32 bit and 64 bit and other numbers that I tried to factor.

[QUOTE=Citrix;351305]Would like to report a prime95 bug.
Running ECM, once a factor is found the program continues to use the CPU but the program becomes unresponsive.[/QUOTE]

It isn't hung, it is doing a probable prime test on the cofactor. Why? The code does this if the exponent is less than 100,000. Why? Because when the ECM code was written, the only base supported was 2 and the PRP test was fast. Your number, on the other hand, has a large base and the test is quite slow.

There is no workaround for this bug. I will fix it in the next release.

Thanks for the clarification. I will await the new version.
(I will avoid using ECM for sieving as it will not save the PRP test).

Benchmark oddity
 

Had a few hours to set up a new laptop, so I of course installed P95 to get a benchmark.

Attatched is the result.txt from the laptop. The first two runs were with single channel DDR3-1600, the last with dual channel DDR3-1600.

No ability in BIOS to disable hyperthreading.

During each benchmark run, the first group of exponents runs on cores 1 and 3 with 50% processor utilization. The second group of exponents also runs on cores 1 and 3 with 50% utilization. The third group (4 threads on 2 cores) runs on all cores, but with 25-39% processor utilization.


This was on a fully updated Windows 7 Pro x64 system. There are reports that Win 8 has some funkiness that makes conventional benchmarking unreliable (power saving measures mess with timers) so I wonder if MS has backported some of the measures.

[QUOTE=sdbardwick;352691]During each benchmark run, the first group of exponents runs on cores 1 and 3 with 50% processor utilization. The second group of exponents also runs on cores 1 and 3 with 50% utilization. The third group (4 threads on 2 cores) runs on all cores, but with 25-39% processor utilization.[/QUOTE]

That is very usual, it essentially boils down to the fact that even with 4 threads you still have only two processors, and for a processor intensive program such as prime95 one processor can't keep up with the throughput of two threads.

If Prime95 uses different P-1 bounds because of what's in the save file, it doesn't display the actual probability, only the probability it thought it was going to be before it saw there was a savefile with different bounds. For example:[quote]Assuming no factors below 2^79 and 2 primality tests saved if a factor is found.
Optimal bounds are B1=2655000, B2=65047500
[b]Chance of finding a factor is an estimated 4.36%[/b]
Using AVX FFT length 16M, Pass1=2K, Pass2=8K, 2 threads
Setting affinity to run helper thread 1 on any logical CPU.
Ignoring suggested B1 value, using B1=2945000 from the save file
Ignoring suggested B2 value, using B2=83932500 from the save file
[color=red]Chance of finding a factor is an estimated 4.61%[/color][/quote]The line in bold shows the predicted probability [i]before[/i] looking at the savefile.
The line in red isn't in the Prime95 output, but should be: the probability based on the bounds in the savefile.

Possible bug report
 

Windows64, Prime95, v27.9, build 1
CPU: Intel Core i7 920, LL test, one worker plus two helper threads

Exponent: M64220633

[i]Trying 1000 iterations for exponent 64220633 using 3360K FFT.
If average roundoff error is above 0.24286, then a larger FFT will be used.
Final average roundoff error is 0.24194, using 3360K FFT for exponent 64220633.[/i]

I got the following error at iteration 15028257.

[i]Iteration: 15028257/64220633, ERROR: ROUND OFF (0.4375) > 0.40[/i]

I restored the save file from a few hours before the error, and re-run the test starting with the iteration 14150041. I got the same round off error again at iteration 15028257.

If this is a hardware issue, what are the chances I would get the error at the exact same iteration?

Is it possible the error happened before iteration 14150041 and was not reported until iteration 15028257?

Thanks.

[QUOTE=TObject;355625]If this is a hardware issue, what are the chances I would get the error at the exact same iteration?[/QUOTE]

This is not a hardware problem and it is not a software problem. Everything is going according to plan!

You are testing an exponent very close to the maximum allowable for the FFT size. Thus, roundoff errors will be larger than most LL tests. Occasionally, one will exceed 0.4 -- and this is OK. Prime95 will retest that iteration just to make sure all is OK.



Correction: This could be considered a software bug if prime95 flatly stated an error occurred. I thought it said something like "possible error" but I could be remembering wrong.

It says:

[i]Possible hardware errors have occurred during the test! 1 ROUND OFF > 0.4.
Confidence in final result is fair.[/i]

Thank you.