mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   MISFIT (https://www.mersenneforum.org/forumdisplay.php?f=103)
-   -   (archive)MISFIT (https://www.mersenneforum.org/showthread.php?t=17414)

swl551 2013-02-04 00:09

[QUOTE=Chuck;327391]
[/CODE]They look OK[/QUOTE]

One last test.... In the MISFIT repository there is a utility called LLcalcTest. Try that. It represents the absolute basic of windows forms applications.

Chuck 2013-02-04 00:14

[QUOTE=swl551;327393]One last test.... In the MISFIT repository there is a utility called LLcalcTest. Try that. It represents the absolute basic of windows forms applications.[/QUOTE]

LLCalcTest works OK.

swl551 2013-02-04 00:20

[QUOTE=Chuck;327396]LLCalcTest works OK.[/QUOTE]

Ok, so the main form of MISFIT has something your machine cannot tolerate. A corrupt font or DataGridView object.....

If you can capture a crash dump I can try to analyze it.
[url]http://technet.microsoft.com/en-us/sysinternals/dd996900[/url]


I also put a utility out there called HelloChuck. It is the MISFIT form with NO code running on the load event. If that crashes you do have a .NET corruption somewhere.

Chuck 2013-02-04 00:26

[QUOTE=swl551;327397]Ok, so the main form of MISFIT has something your machine cannot tolerate. A corrupt font or DataGridView object.....

If you can capture a crash dump I can try to analyze it.
[URL]http://technet.microsoft.com/en-us/sysinternals/dd996900[/URL]


I also put a utility out there called HelloChuck. It is the MISFIT form with NO code running on the load event. If that crashes you do have a .NET corruption somewhere.[/QUOTE]

Thanks but I've had enough...I'll just have to do without the program.

swl551 2013-02-04 01:20

[QUOTE=Chuck;327398]Thanks but I've had enough...I'll just have to do without the program.[/QUOTE]
Chuck, I JUST noticed your post from pages back that had a stack trace.

Please try ONE last thing. Download MISFIT(chucktest).zip and try it out. I put a silent try/catch block around the SysTray event so it may actually run without you seeing the crash.

If it does not work then I agree with you... it is time to stop....

Sorry for all this hassle anyway....

bcp19 2013-02-04 02:30

[QUOTE=swl551;327165]Your environment can be handled by one instance but there are limitations if you want to keep the type of work segregated by instances. (to prevent cross pollination of work)

**With two physical machines just run MISFIT on each machine and cross pollination won't be an issue at all.**

**With one physical machine running two mfaktX instances then you will have to do work fetching and adding of work manually and directly into the desired WorkToDo.txt files.** (this can be done by the CLI Gpu72WorkFetcher.exe utility using different configuration files and executing via Windows Scheduler (or whatever))

If cross pollination of work is not an issue then there are no restrictions on MISFIT's implementation.

Feel free to clarify any restrictions/conditions you have in your environment that might produce a different option.

Also the Gpu72WorkFetcher.exe utility can use both the LLTF and the DCTF urls so you can fetch either type of work.

Thanks[/QUOTE]
I have 4 computers 2 dc 2 ll and wanted to control them from 1 system as they are not in close proximity.

swl551 2013-02-04 02:44

[QUOTE=bcp19;327408]I have 4 computers 2 dc 2 ll and wanted to control them from 1 system as they are not in close proximity.[/QUOTE]

Did you see this post. It may be of value to you.
[url]http://mersenneforum.org/showpost.php?p=327329&postcount=364[/url]

Please clarify if you must keep the DCTF & LLTF dedicated to specific GPUs or if is OK to commingle the work.

kladner 2013-02-04 05:25

Possible feature
 
It has occurred to me to wonder if it would be possible to bias the distribution of staged work (or of balancing) to give more to one instance than another. I ask because I run two instances of mfaktc, one on a GTX 570 and the other on a GTX 460. Obviously, the 570 plows through a lot more work than the 460. Balancing works just fine, except that 570 immediately starts pulling ahead again. I have taken to moving a chunk of assignments from the bottom of the 460 worktodo to the bottom of the 570 worktodo, and setting auto-balance to zero. The 570 runs nearly twice as fast, so giving it 2/3 of the assignments and the 460 1/3 would seem to work out about right (assuming all similar assignments.) I can see that it might get more complicated with more than two instances. Also, diverse assignments would necessarily throw things off unless GHz-days were used as the metric instead of number of lines.

Just a thought. Things are great as they are. :smile:

Chuck 2013-02-04 13:30

[QUOTE=swl551;327400]Chuck, I JUST noticed your post from pages back that had a stack trace.

Please try ONE last thing. Download MISFIT(chucktest).zip and try it out. I put a silent try/catch block around the SysTray event so it may actually run without you seeing the crash.

If it does not work then I agree with you... it is time to stop....

Sorry for all this hassle anyway....[/QUOTE]

So should I just run with this test version that works for me? Or is there something that needs to be corrected?

swl551 2013-02-04 13:47

[QUOTE=kladner;327424]It has occurred to me to wonder if it would be possible to bias the distribution of staged work (or of balancing) to give more to one instance than another. I ask because I run two instances of mfaktc, one on a GTX 570 and the other on a GTX 460. Obviously, the 570 plows through a lot more work than the 460. Balancing works just fine, except that 570 immediately starts pulling ahead again. I have taken to moving a chunk of assignments from the bottom of the 460 worktodo to the bottom of the 570 worktodo, and setting auto-balance to zero. The 570 runs nearly twice as fast, so giving it 2/3 of the assignments and the 460 1/3 would seem to work out about right (assuming all similar assignments.) I can see that it might get more complicated with more than two instances. Also, diverse assignments would necessarily throw things off unless GHz-days were used as the metric instead of number of lines.

Just a thought. Things are great as they are. :smile:[/QUOTE]
Kladner that is a pretty tall order and not simple. I can only do simple... My recommendation is increase the threshold when a workbalance occurs. Remember the goal of the workbalancer is to make sure no worker runs out of work between reloads and it definately does that nicely.

Sorry.

However I'm glad you are happy with how everything else works!

Scott

swl551 2013-02-04 13:48

[QUOTE=Chuck;327453]So should I just run with this test version that works for me? Or is there something that needs to be corrected?[/QUOTE]

If you can... please do as I'm curios if you see other UI issues.. Are you running more than one monitor?


All times are UTC. The time now is 22:25.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.