MISFIT 2.4.2 works perfectly. Thanks :smile:

[QUOTE=kracker;327910]MISFIT 2.4.2 works perfectly. Thanks :smile:[/QUOTE]
Thanks Kracker,

We'll test for a few more days before declaring victory on the scaling issue.

[QUOTE=kracker;327910]MISFIT 2.4.2 works perfectly. Thanks :smile:[/QUOTE]

I haven't broken it, either. I still haven't solved why Aero is not available on my system, but I don't really care. I try to shut down resource hogs anyway.

The test version 2.4.1.1 looks to be fine with no sizing or "squashing" problems.

[QUOTE=Chuck;328058]The test version 2.4.1.1 looks to be fine with no sizing or "squashing" problems.[/QUOTE]
Excellent! I'll release the final update for this on the weekend.

Manual work addition — not sure how I should do this. I decided I wanted to add a few double-checks into the mix, so I stopped MISFIT and manually edited three lines into worktodo.txt

It looked like this was OK when I restarted MISFIT. It appeared to recalculate the GHz days to go. But a few minutes later I got a STALL warning and email. I just stopped and restarted the program.

Did my manual addition cause this?

[QUOTE=kladner;327759]Thanks! :tu:
... Oliver also explained some time back why mfaktc 2.0 is more efficient with Stages=1. [/QUOTE]

What's this? I don't recall reading that. I'm quite surprised that breaking the number down and doing it in chunks is more efficient than running the process straight through. I'll try to search the forum for posts from TheJudger saying so, but if you find them a link would be appreciated.

Edit: [URL="http://www.mersenneforum.org/showthread.php?p=325675&highlight=stages#post325675"]Found It[/URL]. It probably won't make much difference in the ranges I'm working, but it doesn't hurt enough to take the chance. I'll set the stages to 1.

[QUOTE=Chuck;328126]Manual work addition — not sure how I should do this. I decided I wanted to add a few double-checks into the mix, so I stopped MISFIT and manually edited three lines into worktodo.txt

It looked like this was OK when I restarted MISFIT. It appeared to recalculate the GHz days to go. But a few minutes later I got a STALL warning and email. I just stopped and restarted the program.

Did my manual addition cause this?[/QUOTE]
Chuck,
There is no reason to stop MISFIT. It is designed to work with mfaktX, not against it. In-fact one could state you should be stopping mfaktX before editing a workToDo file, not the other way around.

Here is how MISFIT directly supports WorkToDo via its built in editor.
1. it backups up your worktodo.txt upon save
2. it applies file-locking to prevent unhandled IO collisions
3. it updates the gridStats after edit is complete


****************
Reasons for stall warnings

1. mfaktX is not running in memory
2. mfaktX is is hung
3. You clicked the "Force a Stalled Process Test" button in rapid succession to produce a false stall indication
[B]4. You are factoring very low (< 68) bit ranges so fast that the checkpoint files are undetectable.[/B]
5. You have turned off check-pointing in mfaktX.ini

So only condition 4 is a false alarm and if it occur often you should increase the configuration value for "Number of times checkpoint file detected stalled before notification" from 2 to 5;

I hope this info helps.

Scott

I wanted the double checks to be the next exponents processed; whenever I introduce manual work, I want it to be started after the current exponent has finished processing. I do not see any other way to accomplish this.

I always check mfaktc and make sure that there is plenty of time before the exponent will finish before starting the edit.

I have checkpointing set to delay ten minutes, and the short time for each of the three I added explains the stall condition. I will increase the "Number of times" check as you recommend.

If you have any recommendations for addition of work for immediate processing I am interested. I plan on doing this each weekend so as to process 31M double checks over the weekend.

[QUOTE=Chuck;328207]I wanted the double checks to be the next exponents processed; whenever I introduce manual work, I want it to be started after the current exponent has finished processing. I do not see any other way to accomplish this.

I always check mfaktc and make sure that there is plenty of time before the exponent will finish before starting the edit.

I have checkpointing set to delay ten minutes, and the short time for each of the three I added explains the stall condition. I will increase the "Number of times" check as you recommend.

If you have any recommendations for addition of work for immediate processing I am interested. I plan on doing this each weekend so as to process 31M double checks over the weekend.[/QUOTE]

The build you have allows you to have MISFIT randomly select between LLTF and DCTF work. Chalsall has suggested a nice design where you can set a ratio for the type of work fetched. example: 70% LLTF, 30% DCTF. I may add it someday if there are at least a few people wanting it.

You could also use windows scheduler to fetch LLDC work for you once a week and direct the assignments into MISFITworkToDo. See the MISFIT site for the GPU72WorkFetcher tool.

[QUOTE=swl551;328208]The build you have allows you to have MISFIT randomly select between LLTF and DCTF work. Chalsall has suggested a nice design where you can set a ratio for the type of work fetched. example: 70% LLTF, 30% DCTF. I may add it someday if there are at least a few people wanting it.

You could also use windows scheduler to fetch LLDC work for you once a week and direct the assignments into MISFITworkToDo. See the MISFIT site for the GPU72WorkFetcher tool.[/QUOTE]

I guess I would opt for the % fetching. The DCTF would need its own range selection in addition to the LLTF.