Crash!
 

I found Prime95 crashed a little while ago. From what I could see on the worker windows, the second core was using the bulk of the memory I had allocated doing a P-1 stage 2. The first core had completed P-1 stage 1 and was trying to start stage 2.

I managed to capture a temporary file that the error reporting service uses, It don't say much. There was nothing in the system logs.

The RAM allocation is 512 MB. The second core was running at 632 MB I think I made a mistake in thinking that each core would be allocated 512 MB. Not sure how to set it now.

[quote=storm5510;187639]The RAM allocation is 512 MB. The second core was running at 632 MB I think I made a mistake in thinking that each core would be allocated 512 MB. Not sure how to set it now.[/quote]I can't speculate about the cause of crash, but want to present a clarification:

"The RAM allocation is 512 MB." -- The allocation figure you give ("Available memory") is for only the [I]auxiliary work areas used in P-1 (and ECM) stage 2[/I]. It is not a bound on total memory used, because it does not include any other memory allocation done by Prime95.

The reason is that all other (other than the auxiliary work areas, that is) memory allocation done by Prime95 is necessary, not optional, so there's no point in having the user limit it. Prime95 will allocate what it needs, and no more, other than the auxiliary work areas (which are the only optional memory allocations).

The difference of 120 MB (= 632 MB - 512 MB, or actually probably a bit more since the aux workareas probably don't total 512 MB exactly) probably represents what Prime95 [I]had[/I] to allocate in order to do the processing at all.

Note that I'm [I]not[/I] saying whether 512 MB was too large an amount to specify for "available memory". I'm just addressing the matter of what the 512 and 632 figures mean, relative to each other.

I restarted P95 without problems.

This computer has 2 GB total RAM. The system grabs 256 MB of that for its own used at power-on. By the time everything is loaded by the OS, there is usually around 1.3 GB available. I could have set the memory allocation higher in P95, but didn't.

Pause the second worker until the first finishes stage 2.

We would do a lot less trial factoring and a lot more interesting work (P-1 or ECM) if we could fix [URL="http://www.mersenneforum.org/showpost.php?p=159919&postcount=113"]this[/URL] problem.

We are tempted to go back to an older client that is not multi-threaded. Then we could define the memory per "worker".

(BTW, "MaxHighMemWorkers" did not work for us. It did allow the specified number of workers to use a lot of memory, but the workers that were not to use a lot of memory went idle. And the 2 workers set to use a lot of memory still fought over memory.)

[QUOTE=Xyzzy;188065]We are tempted to go back to an older client that is not multi-threaded. Then we could define the memory per "worker".[/QUOTE]Even with the new multithreaded clients, you can limit them to one thread and run 4 instances like you did with the previous versions (I do this now on a quad core : one instance using 3 workers and one using one worker.) Another possibility would be to run one four threaded worker to do P-1 factoring (not very efficient though.)

Jacob

I'm hitting something similar on mprime under linux.

My work around, was to only do 1x P-1 at a time. The other workers to do double checks. This appears to be stable.

-- Craig

[quote]Even with the new multithreaded clients, you can limit them to one thread and run 4 instances like you did with the previous versions (I do this now on a quad core : one instance using 3 workers and one using one worker.)[/quote]Very cool! Thanks!

:smile:

I've had no problems since. I keep the same work type assigned to both cores; seemed to logical thing to do.