Prime95 behaviour question
 

I have some kind of gremlin in my system. My i7 processor was running 4 LL tests. They were at 35-50% completion with no errors.

I then did something -- 3 of the 4 threads reported hundreds of rounding errors. I might have bumped the PC, maybe there was a vibration.... I don't know what, but hundreds of rounding errors in a brief time.

I didn't notice until two days later. By this point, prime95 had written checkpoint files, and rotated them through the two configured backups. Everything saved in the prime95 directory was (I'd bet) junk.

I did have a backup of the prime95 directory, and restored that and restarted. It is now running smoothly, with no errors reported. This manual restore saved me a week or two of computing time.

What I'd like to see is that prime95 automatically allow this kind of recovery. If I didn't have my manually created backup I would have lost a lot of time. P95 could either not rotate the backups after a certain number of errors, or always keep a "last good" checkpoint file available. Thoughts?

Hmm, just curious are you overclocking?

Disable the HT! (or use a single thread for each worker, so if you have 4 physical cores, use 4 workers, each single threaded).

If you read through the forum, that was a problem with v27.7, when you run multithreaded workers or use HT. Other people (me including) ran into it. That problem is solved by v27.9 which I suggest you to download, if you do not have it already.

Also, this thread might be closed, as it erroneously induces the idea that this is the last version.

OTOH, the errors you get didn't affect the results. P95 is enough clever to try "slower" methods when the faster method fails. As you continued to get rounding errors, it means it was not a reproducible error, but a new one each time, the faster method failed, but the slower one passed (otherwise the test would be terminated, and larger FFT need to be used).

You could use the files and finish your work with the new version, without using the manual backup, without affecting the results. At the end the result would be marked that it had a rounding error somewhere, which was eliminated by using a slower multiplication method.

But the final result would be - most probably - correct.

I didn't know 27.9 was out :confused:

Apparently so. I didn't know either, but it's in there:
[url]ftp://mersenne.org/gimps/[/url]

Thanks

[QUOTE=James Heinrich;325798]Apparently so. I didn't know either, but it's in there:
[URL]ftp://mersenne.org/gimps/[/URL][/QUOTE]


If it didn't make the GIMPS homepage is it a beta build or something? Should it be used without worry?

whatsnew.txt:
[quote]New features in Version 27.9 of prime95.exe
-------------------------------------------

1) None, only minor bug fixes.[/quote]

Since I started using mfaktc .20, one of my systems has been BSOD with 0x101 or 0x124. Not much info on those codes, but it looks like hardware. So far with 27.9, it hasn't restarted. I am using HT on that system, so maybe that was the issue?

[QUOTE=flashjh;325823]Since I started using mfaktc .20, one of my systems has been BSOD with 0x101 or 0x124. Not much info on those codes, but it looks like hardware. So far with 27.9, it hasn't restarted. I am using HT on that system, so maybe that was the issue?[/QUOTE]

Flash,
I had to reduce clock speeds on my 570s to prevent hangs and system freeze-ups and the occasional bsod.

Maybe not related but worth mentioning. There are several posts on the mfaktc thread where the clock speed impact is discussed by Oliver.

[QUOTE=kracker;325749]Hmm, just curious are you overclocking?[/QUOTE]
No. Not overclocking

[QUOTE=LaurV;325755]Disable the HT! (or use a single thread for each worker, so if you have 4 physical cores, use 4 workers, each single threaded).

If you read through the forum, that was a problem with v27.7, when you run multithreaded workers or use HT. Other people (me including) ran into it. That problem is solved by v27.9 which I suggest you to download, if you do not have it already.
...
But the final result would be - most probably - correct.[/QUOTE]

I couldn't figure out what the best options were for cores/threads with HT enabled.

I'll look for 27.9. It seems to me that the 27.7 problem only arose when I stopped and restarted within the linux client without exiting.

So far no BSOD with 27.9.

27.9 running 24/7 on an i5-3570K and an A6-3400M. About 70C on the A6 and 40C temps on the i5. The i5 is Win 8-64 the A6 is Win 7-64. No problems whatsoever.

[QUOTE=LaurV;325755]If you read through the forum, that was a problem with v27.7, when you run multithreaded workers or use HT. Other people (me including) ran into it. That problem is solved by v27.9 which I suggest you to download, if you do not have it already.

Also, this thread might be closed, as it erroneously induces the idea that this is the last version.
[/QUOTE]

For me, this thread was not creating the conception that 27.7 is the newest client. The fact that 27.7 is the only version linked to from the download page is. I have now downloaded the latest directly from the ftp server.

[QUOTE=LaurV;325755]Disable the HT! (or use a single thread for each worker, so if you have 4 physical cores, use 4 workers, each single threaded).

If you read through the forum, that was a problem with v27.7, when you run multithreaded workers or use HT. Other people (me including) ran into it. That problem is solved by v27.9 which I suggest you to download, if you do not have it already.
[/QUOTE]
I just downloaded and ran a benchmark for Prime95 v27.9, to compare to 27.7 on a new Core i5-3210M machine. The results are almost identical (some of the times are actually higher on 27.9).

This is a two-core processor with hyperthreading. FWIW, I can't find an option in the BIOS/UEFI to enable [B]or[/B] disable HT, although when I select a particular worker in Test --> Worker Windows, it does give me the choice of running it on CPUs 1, 2, 3, or 4.

So, I'm not sure what the benefit of 27.9 is supposed to be over 27.7. I'm probably doing something wrong...?

Rodrigo

And here's the file for 27.9 (only one attachment per post allowed).

[QUOTE=Rodrigo;326673]So, I'm not sure what the benefit of 27.9 is supposed to be over 27.7. I'm probably doing something wrong...?[/QUOTE]

None expected, see [URL="http://www.mersenneforum.org/showthread.php?p=325803#post325803"]here[/URL].

[QUOTE=flashjh;326681]None expected, see [URL="http://www.mersenneforum.org/showthread.php?p=325803#post325803"]here[/URL].[/QUOTE]
Thanks -- so then the improvements have to do with avoiding errors when using HT, rather than with improvements in per-iteration times.

Remarkably, when using 27.7 on the i5-3210M if I set two workers each to use two CPUs for their own exponents instead of one CPU apiece, the total CPU load jumps to 100% but LL per-iteration times stay the same.

I'll have to go back and see how the i7-3770 handles this; my recollection is that the times get lower (they improve) if you assign more than one CPU to the same worker.

Rodrigo

[QUOTE=TheJudger;321113]Xyzzy: yepp, I think this has to do with multithreading, too.

I'm doing some multithreaded P-1 (one worker per mprime process, multiple mprime processes per machine), everytime I add new work via worktodo.add I've to check whether the workers keep going or end in a endless loop (two different symptoms [SUP]*1[/SUP]).[LIST][*]1 thread per worker: never happened[*]2 threads per worker: very, very rare[*]4 threads per worker: sometimes[*]8 threads per worker: often (>80%)[/LIST]
While mprime is running this can happen when starting a new exponent (start stage #1) or when switching from stage #1 to stage #2 (start stage #2), too.

Linux, mprime 27.7 64bit, 1 thread per core, running on a network share (NFS).
This happens with AVX code (Sandy Bridge), I can't exactly remember about SSE code.

I've the feeling that it happens more often on faster CPU.

Oliver

[SUP]*1[/SUP][LIST][*]endless loop: "SUMOUT error occurred"; wait 5 minutes[*]endless loop: "Possible roundoff error (<some number>), backtracking to last save file."[/LIST][/QUOTE]

So far this didn't occur with mprime 27.[B]9[/B]. :smile:

Oliver

AVX detection
 

On one of my machines with i5-2400 proc AVX is (no longer) detected in version 27.9 (64 bit) on another machine with same proc AVX is detected in 27.9 as is AVX seen in CPU-Z. Is there an undoc.txt option to force AVX codepath?

[QUOTE=koekie;327450]On one of my machines with i5-2400 proc AVX is (no longer) detected in version 27.9 (64 bit) on another machine with same proc AVX is detected in 27.9 as is AVX seen in CPU-Z. Is there an undoc.txt option to force AVX codepath?[/QUOTE]

Yes, CPUSupportsAVX=1

Small nitpicking:

In the last version of undoc.txt there is a copy/paste error:
[QUOTE=undoc.txt]You can have the program output residues every n iterations. The default value is the InterimFiles value.[/QUOTE]
it should read as "InterimResidues". [edit, in fact the second sentence can be at all eliminated, to be in line with the above and below paragraphs]

[QUOTE=LaurV;329414]
it should read as "InterimResidues".[/QUOTE]

Actually, this is correct. If you set InterimFiles, InterimResidues is also set.

I'm still having problems with my 2500k erroring out when trying to contact the server. It's the same for both the GIMPS server and when I try using the proxy at GPU72. I talked to chalsall about noticing assignments that 'allocated' to it but aren't in the worktodo, and have figured out that my system will get a send request ouit for a new assignment then crash before receiving it. There seems to be nothing I can do as it likely is an inherent flaw in the BIOS for this motherboard that causes the crash. I have automatic talking to Primenet shutoff since P95 only crashing when trying to communicate.

My question though, is it possible to somehow manually report results so the this system gets credit for it? The ones I have submitted so far, even though I include the (UID: bcp19/Main-2500k) it credits it to Manual Testing.

If the above question is no, can P95 be set to NOT delete the final save file upon determining an exponent is composite? I looked all through undoc.txt and trying searching the forum (I don't seem to be able to narrow the search enough to find an answer) so any help with this is appreciated.

[QUOTE=bcp19;330206]I'm still having problems with my 2500k erroring out when trying to contact the server. It's the same for both the GIMPS server and when I try using the proxy at GPU72. I talked to chalsall about noticing assignments that 'allocated' to it but aren't in the worktodo, and have figured out that my system will get a send request ouit for a new assignment then crash before receiving it.[/QUOTE]

Very interesting...

Another user was having a very similar issue. But his was a bit more complex. Sometimes his machine would get an assignment from the GPU72 proxy, but then immediately ignore the proxy settings and talk directly to Primenet seconds later.

Other times, the client would talk through the proxy for several days, and then suddenly ignore the proxy.

The user in question didn't have control of the firewall, so we couldn't debug this further. But your information suggests this might be a bug with the Prime95/mprime client.

[QUOTE=chalsall;330221]Very interesting...

Another user was having a very similar issue. But his was a bit more complex. Sometimes his machine would get an assignment from the GPU72 proxy, but then immediately ignore the proxy settings and talk directly to Primenet seconds later.

Other times, the client would talk through the proxy for several days, and then suddenly ignore the proxy.

The user in question didn't have control of the firewall, so we couldn't debug this further. But your information suggests this might be a bug with the Prime95/mprime client.[/QUOTE]
I don't think it is P95. When the program crashes on me, I restart it about 5-10 times before it stops crashing and runs(I'm thinking when it lasts long enough to finish talking to the server). From the assignments I saw on GPU72, it's apparent during these restarts that the program lasts long enough to request a new assignment 2-3 times before it lasts long enough to accept the response and continue running.
When I was running the 332M exp, I had the program set to only talk to primenet every 7 days cause it would crash too often otherwise and I hated losing several hours of work time for each crash. After having switched to 7 day reports, P95 would report anywhere from 1-4 times before crashing (1 week to 1 month give or take).
Since completing that exp, I first started doing DCs then switched to P-1 until I realized they finished too quickly and the program crashed too often. To offset this, I switched to LL and finally decided to stop it from talking to primenet and just manually report the results.

I have a wishlist type of question.
Could you make the program change the taskbar icon's colour from green to red when either of the active workers stop due to an error? I use Prime95 for stress testing only, but usually keep working with the PC while CPU is being mutilated in the background, and often realize there has been an error fairly long after it happens.

Also, it might be better to have the inactive state displayed by other than red colour, which generally makes you jump up with "ha! something's wrong!". I'd propose something more neutral, like yellow or something.

edit: it might be system tray icon that's changing colours, but same idea applies. Of course, taskbar icon colour change is much better (not only because systray icons get hidden by default unless you manually change each of them).

So it is always better to run 27.9 compared to 27.7? Are there problems with running 27.9 now? I use Prime95 for Torture testing my CPU OC.

When torture testing, is it recommended to enable sum (inputs) error checking and round off error checking under advanced menu and set priority to 10?

Hm... grrrr... anyone ever met this? The worker is stuck in this since the date shown, does no progress but it consumes CPU resources like a good faith guy...
[ATTACH]9485[/ATTACH]
After taking the screenshot I restarted the worker and it immediately did stage 1 GCD (it took 64 seconds) and now is patiently doing stage 2 which is in good progress already ... No idea what it was... But it lost me 2 days...

edit: no idea if the test result is valid anymore, too...

[QUOTE=LaurV;332560]Hm... grrrr... anyone ever met this? The worker is stuck in this since the date shown, does no progress but it consumes CPU resources like a good faith guy...
[ATTACH]9485[/ATTACH]
After taking the screenshot I restarted the worker and it immediately did stage 1 GCD (it took 64 seconds) and now is patiently doing stage 2 which is in good progress already ... No idea what it was... But it lost me 2 days...

edit: no idea if the test result is valid anymore, too...[/QUOTE]

I have seen something similar not long ago.

Supposing you are using the last version of Prime95, which hardware is it working on?

Luigi

This is a known, multi-year old bug/feature, but it is purely cosmetic.
(The progress X% is wrong after some restarts.)
The result will be valid.

Ok. Thanks.

Can this have anything to do with the fact that I "artificially" increase B1/B2 limits? Usually, every time I get new P-1 assignments (I am not a P-1 heavy producer, I only do this occasionally, taking manual assignments, when I have free cores), I will modify the last digit on the "pfactor" lines (number of LL tests saved if a factor is found), from 1 or 2, to 3, 5, etc. This is to trick P95 into increasing the B1/B2 limits. If he believes I save a lot of work by finding a factor, then he will increase the limits, therefore increasing the chance to find a factor, like from 3% to 10% or so. Of course, this increases the running time too, like from 20 hours to 3 days, but I am totally ok with it. :razz:

I even don't need to use my old batch to increase the saved LL numbers, because James' site is giving me [URL="http://www.mersenne.ca/p1small.php?min=46900000&prob=3.00&tfmin=50&tfmax=90&onlystage1=0&ignorenop1=0&showassigned=0&showpminus1=0&tests_saved=6"]the right Pfactor lines[/URL] already. It may be that when I got this assignment I increased that value too much, like 10, or 8, etc, then after I started the test I found out that the test will take too long time, longer then I expected to have free cores, and I manually reduced the value (like to 6, or 5, or 3). After such adventures, I usually delete the P95 temporary files (because he is using the limits from the file, if the file exists, and you can't change the limits, but this is not always happen, sometime your new limits are considered, I don't know which criteria is used). It may be that this time I forgot to delete the temp files...

I am just telling this story in case it may help to identify the bug. Most probably I can't reconstitute it, as it is very rare (I only have seen it now for the first time, in years of using P95 P-1 this style).

PauseWhileRunning vs. worktodo.add
 

I have a strange effect with Linux64,Prime95,v27.7,build 2 and PauseWhileRunning

my prime.txt contains

PauseWhileRunning=*[3] during 1-5/7:45-17:10

working well normally. However, when I add work using worktodo.add during "working hours" (after 17:10), then the go-to-sleep the next morning (ff.) will be ignored.

OK, worktodo.add is unsupported, but I thought I'd report it anyway :smile:

27.9 on 64bit linux.

I have a dual socket sandybridge server. 2 E5-2670s. HT is off. 27.9 thinks this is an 8 core machine with HT on.

I care because I am trying to compare the benchmark with a single socket i7-3960x (overclocked) and trying to understand the speedups due to AVX and due to the overclocking.

With the HT confusion I can't tell what's going on. I need to compare 1 thread per physical core to one thread per physical core on the i7-3960x.

From undoc.txt:
[CODE]
The program automatically computes the number of CPUs, hyperthreading, and speed.
This information is used to calculate how much work to get.
If the program did not correctly figure out your CPU information,
you can override the info in local.txt:
NumCPUs=n
CpuNumHyperthreads=1 or 2
CpuSpeed=s
Where n is the number of physical CPUs or cores, not logical CPUs created by
hyperthreading. Choose 1 for non-hyperthreaded and 2 for hyperthreaded. Finally,
s is the speed in MHz.

As an alternative to the above, one can set NumPhysicalCores=n in local.txt.
This is useful on machines that are somtimes booted with hyperthreading enabled
and sometimes without. Normally, the program can detect this situation, but one
notable problem case is a dual-CPU hyperthreaded machine, For example, take a
dual-CPU quad-core hyperthreaded machine. When booted with hyperthreading enabled
this is properly detected as an 8-core hyperthreaded machine. When booted
with hyperthreading disabled, this is improperly detected as a 4-core hyperthreaded
machine. If you set NumPhysicalCores=8, then the program will set the
hyperthreading state properly no matter how the machine is booted.[/CODE]

[QUOTE=dts350z;337644]27.9 thinks this is an 8 core machine with HT on.[/QUOTE]

See undoc.txt. You can add entries to local.txt that override prime95's CPU detection.

I noticed that Prime95 when start job start every core with 5 seconds of delay. In that time it set cpu affinity.
Can you tell me how you manage that Prime95 lock cpu usage to 100 on every core.
If I manually set affinity on four llr.exe process I dont got that "perfect" high core usage, it is around 99-100 % but on Prime 95 it is always 100%.
Thanks for reply!

This I guess falls under user-error / GIGO, but Prime95 will crash on a PRP test that specifies [i]all[/i] the factors for a fully-factored exponent (leaving nothing left to check for probable-primality). For example:[code]PRP=1,2,101,-1,"7432339208719,341117531003194129"[/code]

I'm testing v27.9 build 1 on a dual e5-2670 xeon system (16 physical cores, 32 with hyperthreading, everything detected correctly) and there seems to be a problem with the expected completion date calculation. I did LL tests on all 32 cores and the estimated completion time was always approximately twice as long compared to reality (no restriction in the settings).

The general wisdom is that hyperthreads do not help, and may even hurt performance in Prime 95. The only circumstance, IIRC, in which it seems to be a benefit is when other uses (software) are competing for CPU time.

[QUOTE=kladner;343320]The general wisdom is that hyperthreads do not help, and may even hurt performance in Prime 95. The only circumstance, IIRC, in which it seems to be a benefit is when other uses (software) are competing for CPU time.[/QUOTE]

To be a bit more precise, an LL worker in Prime 95 will completely occupy a physical core. There is no gain in running more workers than you have physical cores. Even with hyperthreading enabled, you need to arrange Prime 95 to run only on "real", not virtual cores.

Search the forum for "affinity scramble". Note that it is far more effective to search via Google with "site: mersenneforum.org [search terms]" (no quotes, no brackets.)

It's always good to check the general wisdom from time to time to see if it's still valid. ;)

Since the first CPUs with hyperthreading came out I always tried to find the best work scenario for Prime95 for a given system. If I remember correctly back then the best combination on the first single core CPU with hyperthreading was to do a LL-Test on one virtual core and a TF-Test on the other.

On the system mentioned in my original message running Prime95 on all 32 virtual cores is approx. 15% faster than running only on 16 physical cores.

Anyway, my observation regarding the faulty expected completion date calculation is independent from the number of used CPU cores. On that system it seems to always differ by a factor of ~2.

Is there a way to keep Prime95 from sending back to PrimeNet [U][I][FONT="Lucida Console"] every time [/FONT][/I][/U] I adjust memory settings? I change the memory setting on my machines if I know that I will be away from them for a while. I set the day time memory to be the same as nighttime. I would prefer it if I could shut off the check-in.

[QUOTE=Uncwilly;343460] I would prefer it if I could shut off the check-in.[/QUOTE]

Options / Manual Communication

I understand what FFT2=2480K does but, what does FFT2=3M mean?

kilo, mega, tera?
FFT2=3M is FFT2=3072K

Still waiting to see the time when my personal computer will be able to use a tera-FFT... Or at least few-giga-FFT... hehe.. I will go for the big EFF money... :razz:

I use Prime 27.9 if I need quickly to verify that number is PRP or not. But I noticed next behavior, and that is in same time question: I can set program to use 4 threads on quadcore CPU, and it is ok, but Prime only uses about 72-80% of CPU. Can I manage to to get 100% of use?
This is local.txt

[QUOTE]OldCpuSpeed=3829
NewCpuSpeedCount=0
NewCpuSpeed=0
RollingAverage=1000
RollingAverageIsFromV27=1
ComputerGUID=xxxxxxxxxxxxxxx
WorkerThreads=1
Affinity=99
ThreadsPerTest=4
RollingHash=1257001510
RollingCompleteTime=104[/QUOTE]

[QUOTE=pepi37;346442]I use Prime 27.9 if I need quickly to verify that number is PRP or not. But I noticed next behavior, and that is in same time question: I can set program to use 4 threads on quadcore CPU, and it is ok, but Prime only uses about 72-80% of CPU. Can I manage to to get 100% of use?
This is local.txt[/QUOTE]
What kind of quad core is it? If your CPU has Hyperthreading on it, you'll never use 100% of it (and wouldn't want to as it's not faster).

i7-2700K with HT off

I saw 28.1 mentioned earlier, is that only an in house release?

[QUOTE=tului;349321]I saw 28.1 mentioned earlier, is that only an in house release?[/QUOTE]

It is still in development. It is basically version 27.9 with Haswell enhancements.

[QUOTE=Prime95;349323]It is still in development. It is basically version 27.9 with Haswell enhancements.[/QUOTE]

My Sandy Bridge is already approaching decrepitude :no:

[QUOTE=Prime95;349323]It is still in development. It is basically version 27.9 with Haswell enhancements.[/QUOTE]

Can't wait to see what it does on my lappy.

Prime95 (version 27.9, build 1) has been unable to communicate a result to the server despite numerous attempts:

[Main thread Aug 21 10:01] Mersenne number primality test program version 27.9
[Main thread Aug 21 10:01] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 256 KB, L3 cache size: 6 MB
[Comm thread Aug 21 10:01] Updating computer information on the server
[Main thread Aug 21 10:01] Starting workers.
[Comm thread Aug 21 10:01] Sending result to server: UID: richs/work-new, M29576419 is not prime. Res64: 2BBB7D00CCE____. We1: 6D8A12E5,7867395,00000000, AID:
[Comm thread Aug 21 10:01]
[Comm thread Aug 21 10:01] PnErrorResult value missing. Full response was:

followed by a lot of html commands. I blanked the last four digits of the residue.

Any suggestions?

Is there a proxy server involved? Do the proxy settings need to be changed?

Try putting "Debug=2" in the [Primenet] section of prime.txt. Restart prime95. This should output the complete server response to the prime.log file. This response might help us figure out what the problem is.

Debug=2 showed that mersenne.org was newly blocked by our company spam filter. I'll get that corrected. Thanks for the advice, George.

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=pepi37;350562]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]
That tells the error status results at the end of the run. It is important for flagging numbers to get a "quick double check". If the test was bad, a new prime could have been missed. Better to double check sooner rather than later.

[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.

Is there a way to switch to a larger FFT manually in the middle of a primarily test?

[QUOTE=TObject;355637]Is there a way to switch to a larger FFT manually in the middle of a primarily test?[/QUOTE]

You can, but there is no need to do that. The smaller FFT size is chosen because it will be faster, albeit a bit whiney.

Mac mprime vs prime95?
 

I'm sorry if this was asked earlier but I can't find this concern if so...


I see at [url]http://www.mersenneforum.org/gimps/[/url] there is p95v279.MacOSX and mprime277-MacOSX

Is the difference between the mac OS X mprime v27.7 and prime 95 v27.9 only for the GUI of prime95?

Otherwise, is there an mprime for mac os X at v27.9 that I can get?

I'm interested in mprime over prime95 so that I can script the execution and timing of mprime via unix-related utilities in Mac OS X.

[QUOTE=JTL;356215]I'm sorry if this was asked earlier but I can't find this concern if so...


I see at [url]http://www.mersenneforum.org/gimps/[/url] there is p95v279.MacOSX and mprime277-MacOSX

Is the difference between the mac OS X mprime v27.7 and prime 95 v27.9 only for the GUI of prime95?

Otherwise, is there an mprime for mac os X at v27.9 that I can get?

I'm interested in mprime over prime95 so that I can script the execution and timing of mprime via unix-related utilities in Mac OS X.[/QUOTE]

If you have a Haswell processor, the v27.9 version may give you better performance if:
* You have fewer than 4 real cores
* You have 4+ real cores with RAM faster than dual channel 2000 MHz (dual channel 1600 MHz RAM can barely keep 3 cores of my i7-4770 saturated when running v27.9).

If you have one of those Haswell Mac Pros with quad channel RAM, you probably want to talk Prime95 into compiling a version for you.

What 4 memory channel Haswells? AFAIK, the Pros are using Ivy Bridge-E based processors.

[QUOTE=sdbardwick;356635]What 4 memory channel Haswells? AFAIK, the Pros are using Ivy Bridge-E based processors.[/QUOTE]

You're correct. My apologies.

When the Haswell-based Xeon's come out, then it will matter. But that's not until next year.

28.1 with my ivy bridge runs so slowly & the fft lengths only last 5 mins instead of the usual 15? it droops vcore to the same amount and gets to the same temps as 27.9 & loves to crash. is it trying to force haswell instructions onto a cpu that doesnt have them or is it full of bugs or what? 27.9 goes flying & completes tons of tests..

[QUOTE=Yuno;356770]28.1 with my ivy bridge runs so slowly & the fft lengths only last 5 mins instead of the usual 15? it droops vcore to the same amount and gets to the same temps as 27.9 & loves to crash. is it trying to force haswell instructions onto a cpu that doesnt have them or is it full of bugs or what? 27.9 goes flying & completes tons of tests..[/QUOTE]

All is OK. In 28.1 I changed each torture test to run more iterations. The theory is that the time spent running iterations is more stressful than the time doing setup work.

Sorry about the loving to crash. It is either due to the increased stress or it could be due to a bug -- especially if the crash comes in the same spot every time.

[QUOTE=Prime95;356804]All is OK. In 28.1 I changed each torture test to run more iterations. The theory is that the time spent running iterations is more stressful than the time doing setup work.

Sorry about the loving to crash. It is either due to the increased stress or it could be due to a bug -- especially if the crash comes in the same spot every time.[/QUOTE]

it is most common at the 24k fft, it crashed once on stock speed too crash as in "prime95 has encountered an error etc" crash. i think small fft should default to 8k ~ 32k instead of 16k the caches of modern cpus have grown a lot, 24k is much more stressful than 8k or 16k.

[QUOTE=JTL;356215]
Is the difference between the mac OS X mprime v27.7 and prime 95 v27.9 only for the GUI of prime95?
[/QUOTE]


Is the difference between the mac OS X mprime v27.7 and prime 95 v27.9 only for the GUI of prime95?

[QUOTE=JTL;356945]Is the difference between the mac OS X mprime v27.7 and prime 95 v27.9 only for the GUI of prime95?[/QUOTE]

Yes (and no). There were a few bug fixes between 27.7 and 27.9. These fixes are described in the second post of this thread. Unless you are running multi-threaded FFTs you shouldn't be affected.

[QUOTE=Yuno;356824]it is most common at the 24k fft, it crashed once on stock speed too crash as in "prime95 has encountered an error etc" crash. i think small fft should default to 8k ~ 32k instead of 16k the caches of modern cpus have grown a lot, 24k is much more stressful than 8k or 16k.[/QUOTE]

Unless the crash occurs absolutely every time running the 24k fft test, then the problem is most likely stress related. Sorry, but that applies even if you are running at stock speed.

[QUOTE=Prime95;357138]Yes (and no). There were a few bug fixes between 27.7 and 27.9. These fixes are described in the second post of this thread. Unless you are running multi-threaded FFTs you shouldn't be affected.[/QUOTE]

Ah I see that post you were referring to. I guess I should have read it more carefully.

Thanks very much for the clarification, Prime95!

Prime95 27.7/27.9 issues with AMD FX-8350
 

Hello everyone,

I have just joined this forum, it looks very interesting.

I was wondering if anyone faced a similar issue like me. My PC easily goes hours after hours running Prime95 26.6, and everything else that I want to run, and never crashes.

But I downloaded Prime95 27.7 and 27.9, but both of them are crashing my computer within 5-10 minutes of running Prime95. Windows 8 crashes saying something happened and it will restart and a sad smiley on a blue screen.

Any idea why is this happening? I am trying the first torture test ((Maximum FPU Stress)

My system spec is:

AMD FX-8350 Stock
Zalman CNPS9900 Cooling
32GB 2133MHz Kingston HyperX Beast
Windows 8 Pro

Any idea anyone? Thanks a lot in advance.

I'm not sure I can offer any help. I am running 64-bit P95 v27.9, on Windows 7 64-bit. The system is:[INDENT]FX-8350 @ 4GHz (stock)
Asus Crosshair V Formula Z, 990FX motherboard
32 GB Crucial Ballistix Sport @ 1600
[/INDENT]This setup mostly runs 24/7 doing P-1 factoring and dual-GPU LLTF. I have not had P95 crashes or warnings since the last time I messed around with overclocking. At Stock it seems to be rock solid.

I do not own an AMD cpu, but I have read here around that the AVX on those is slower than the SSE, therefore you should use SSE (klander can confirm or contradict here, what is he running). The difference between the two versions of P95 is that the last one implements the AVX. On Intel cpu's, this translate in [U]additional performance[/U], but which comes with [U]a lot of additional stress for the CPU and heat[/U]. Without proper cooling, an intel cpu running v27+ will crash where the same system running v26 will not crash. If (I said "if", some other users can confirm or infirm) the additional heat and stress appears for FX cpu's too (because I understood that the additional performance is yet to be seen on those :P) then you may have a cooling problem. The fan is not properly mounted, or paste is dried, dust clogs, etc. Also, George (or someone else) can confirm/infirm if it is worth to update P95, for your CPU. I still have few core-2 cpu's running v26 and I feel ok with it, George said there is no reason to update to v27-29 on those, as it does not get additional speed (no AVX). If it works, don't fix it.

My impression, (and that is all it is,) is that Prime95 does not enable AVX on FX chips. I suspect that this is part of the "Optimizing for Bulldozer" startup.

I endorse looking elsewhere for the problem.

[QUOTE=kladner;359332]"Optimizing for Bulldozer" startup.[/QUOTE]
Oh, it does that? Then it is cleverer than I expected :razz:
Honestly I though you use prime.txt options to force SSE or AVX, George said something in the past, but silly me, I didn't pay attention to FX-related because I don't have any.

I have 27.9 running on my Athlon X4, and I have not had any trouble with it. It's been running 27.9 for what seems like a long time now, I don't even remember upgrading. x64.

[QUOTE=Kyle;324487]Hi, mprime 27.9 build 1 Linux64 "crashed" this morning on my computer. It said:
[CODE]Segmentation fault[/CODE]and stopped working. Nothing in prime.log. Invoking dmesg, I got:
[CODE]mprime[35596]: segfault at 7fbb0f2c3938 ip 00007fbc12ad4771 sp 00007fafbbffd010 error 4 in libc-2.12.so[7fbc12a5d000+186000][/CODE]I dont know if you can find out the problem with so less informations. It can't be a hardware bug, since the computer memory has 2bit-ECC and temperatures never exceed 45°C.[/QUOTE]

I had the same thing happen on mprime 27.9 build 1 for 64-bit Linux, after doing ECM on small Mersenne numbers for 2 days.

"PauseWhileRunning" request?
 

Using Windows 7, we can run Prime95 on our CPU and mfaktc on our GPU without any lag in the system.

Using Ubuntu 12.04, we cannot. However, we can run four instances of ecm on our CPU and mfaktc on our GPU without lag.

The lag manifests itself when scrolling web pages and popping up new windows. We move from app to app very frequently with ALT+TAB.

We have tried running mprime at the lowest priority. We have tried having it use only three cores instead of four. We have tried P-1 testing and double-check testing. They all lag.

The only solution we can think of is to have mprime "PauseWhileRunning" when the DPMS thingie has not kicked in.

We assume (?) that ecm does not lag because it is not nearly as optimized as mprime. (That does not explain getting lag when running mprime with fewer cores, though.)

We are open to any suggestion to tune our system if we have missed anything. Even if a solution is found, this feature would be a good one and (we think) fairly simple to implement.

FWIW, the system is not an aging laptop. It has an i7 (3770) with HT turned off, a 6GB/S SSD, 16GB of PC3-12800 memory and a Titan video card. (And plenty of cooling!) Things should run lickety-split, right?

PS - we have also adjusted the variables for mfaktc. Surprisingly, we can run 128/8 in Ubuntu whereas in Windows we had to use 32/8 to get decent screen performance. That is pretty odd behavior we think. The way Windows and Linux composes the screen must be very different.

PPS - We run the 2D Unity desktop, so we are probably using less than 1% of the GPU using the desktop or apps or videos.

:help:

[QUOTE=Xyzzy;365800]It has an i7 (3770) with HT turned off[/QUOTE]For the sake of experimentation, try with HyperThreading turned [b]on[/b]. If the source of your lag is competition for CPU resources then HyperThreading should address that very issue.

[QUOTE=Xyzzy;365800]
PS - we have also adjusted the variables for mfaktc. Surprisingly, we can run 128/8 in Ubuntu whereas in Windows we had to use 32/8 to get decent screen performance.[/QUOTE]

128/8 does give me the best performance for my cards (GTX 760 and GTX 430 x 2).

I normally control-c mfaktc when I use my desktop.

I would try setting NumStreams=2 (or even 1) to increase interactive performance at the expense of slightly reduced mfaktc performance.

Windows and Linux do indeed do graphics very differently behind the scenes. The Linux stack has ancient origins, and it's currently being rewritten (Wayland project) but will take a couple more years to be adopted in mainstream distributions.

[QUOTE]For the sake of experimentation, try with HyperThreading turned [b]on[/b]. If the source of your lag is competition for CPU resources then HyperThreading should address that very issue.[/QUOTE]
No change.

:sad:

[QUOTE]I would try setting NumStreams=2 (or even 1) to increase interactive performance at the expense of slightly reduced mfaktc performance..[/QUOTE]We tried values from 1 to 10 without noticing a difference. (This setting is not used when "SieveOnGPU=1", right?)

Further testing:

To test lag we did the two following tasks:

1 - Scroll up and down a long web page in Chrome.
2 - Scroll up and down a large PDF file in Document Viewer.

no mfaktc & no mprime = no lag
no mfaktc & mprime (4 cores) = no lag
mfaktc (4/4 = 332-341GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/4 = 332-341GHz-d/d) & no mprime = no lag
mfaktc (4/8 = 375-377GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/8 = 375-377GHz-d/d) & no mprime = no lag
mfaktc (4/16 = 399-400GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/16 = 399-400GHz-d/d) & no mprime = no lag
mfaktc (4/32 = 419-423GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/32 = 419-423GHz-d/d) & no mprime = no lag
mfaktc (4/64 = 435-436GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/64 = 435-436GHz-d/d) & no mprime = no lag
mfaktc (4/128 = 441-442GHz-d/d) & mprime (4 cores) = lag; mfaktc (4/128 = 441-442GHz-d/d) & no mprime = no lag

The above data suggests that we can get no lag if we run neither mfaktc or mprime, or if we just run mprime, or if we just run mfaktc. Once we combine both programs, we get lag.

:help:

That's odd to me. I always get lag when running mfaktc, regardless of CPU usage, so I control as I said.

One other thing to try is changing the CPU affinity of mprime. By default it binds to core 0, even if running just one process. This is problematic because some interrupts are only handled on core 0, and I'm guessing including interrupts involved with the graphics card.