![]() |
[QUOTE=chalsall;336301]Sure... But can be argued this is sub-optimal. And requires a human in the loop.
If MISFIT has knowledge about how many GHzDays/day an instance can do, then it should be able to balance the worktodo.txt files such that each instance has a reasonable amount of work based on that.[/QUOTE] Right, Suboptimal, but easily managed by configuration. |
[QUOTE=swl551;336303]Right, Suboptimal, but easily managed by configuration.[/QUOTE]
Never send a human to do a machine's job. A corollary: never send a machine to do a human's job. |
[QUOTE=chalsall;336301]...
If MISFIT has knowledge about how many GHzDays/day an instance can do, then it should be able to balance the worktodo.txt files such that each instance has a reasonable amount of work based on that.[/QUOTE] I should re-state. [U]If[/U] MISFIT had knowledge of an instance's GHzDays/day throughput it would be possible for it to make decisions on that information. However it does not. Adding that information and re-coding many of it's core feature to use that information is a [U]huge[/U] undertaking. Not something I would do anytime soon given my time constraints. I probably will do a small release to implement Chuck's Anti-Runout/fail-safe suggestion which may deliver all that is actually required. |
[QUOTE=swl551;336308]
I probably will do a small release to implement Chuck's Anti-Runout/fail-safe suggestion which may deliver all that is actually required.[/QUOTE] Just something simple like make sure there are always xx (2? 3?) lines left in each worktodo? |
[QUOTE=Chuck;336311]Just something simple like make sure there are always xx (2? 3?) lines left in each worktodo?[/QUOTE]
we'll call it. CHUCK-O-TRON |
[QUOTE=Chuck;336311]Just something simple like make sure there are always xx (2? 3?) lines left in each worktodo?[/QUOTE]
After sleeping on it and reviewing my code I'm going to withdraw from adding another feature to prevent work run-out. The existing set of features already work and will prevent work run-out if configured correctly. Chalsall made an argument that MISFIT was suboptimal because human intervention is required. [QUOTE] Originally Posted by [B]chalsall[/B] [URL="http://mersenneforum.org/showthread.php?p=336301#post336301"][IMG]http://mersenneforum.org/images/buttons/viewpost.gif[/IMG][/URL] Sure... But can be argued this is sub-optimal. And requires a human in the loop. [/QUOTE] However my failing to cite Chuck's actual situation could have prevented additional dialogs. [QUOTE] Originally Posted by [B]Chuck[/B] I am seeing this situation since I [U][B]manually[/B][/U] added a bunch of short double checks; normally this would not have happened. [/QUOTE] History has demonstrated I usually add the features and tweaks requested by the community. However at this point in MISFIT's life those opportunities are less frequent as I believe it has reached its functional plateau. ---------------------------------------------------------------------- Also let everyone refresh on the fact that MFAKTC does not implement a file locking system (like MFAKTO,CUDALUCAS, MISFIT) The lack of file locking in MISFIT's early versions was deemed a rather serious flaw. [url]http://mersenneforum.org/showpost.php?p=307068&postcount=21[/url] The more frequently something touches the files the greater the chance of an IO collision, albeit small. Many of MISFITS configuration constraints are designed to prevent the user from being overly aggressive and inflicting damage. Manually doing things may produce conditions that MISFIT cannot compensate for and I'm OK with that. So that's the deal. Scott |
[QUOTE=swl551;336360]After sleeping on it and reviewing my code I'm going to withdraw from adding another feature to prevent work run-out. The existing set of features already work and will prevent work run-out if configured correctly.[/QUOTE]
I have no problem with that; my situation was caused by my own manual changes to the worktodo files. When left alone the work management is fine. I always look at the workers and wait to make changes when they are each in the middle of an exponent. I terminate MISFIT so it won't do a work balance or assignment while I am editing. I don't do this very often. |
1 Attachment(s)
Possible bug: MISFIT does not appear to be able to submit "only" factor results, what happened is that misfit had submitted results, and then a few minutes later, a factor showed up and when I manually submitted misfit didn't....
|
[QUOTE=kracker;336472]Possible bug: MISFIT does not appear to be able to submit "only" factor results, what happened is that misfit had submitted results, and then a few minutes later, a factor showed up and when I manually submitted misfit didn't....[/QUOTE]
the message is misleading, but the cause is that the results file did not contain the phrase NO FACTORS FOUND and it has been stated that if u upload results and the first line of the file is a FACTOR FOUND row then gimps does not give proper credits. Does that answer make sense? |
[QUOTE=swl551;336491]the message is misleading, but the cause is that the results file did not contain the phrase NO FACTORS FOUND and it has been stated that if u upload results and the first line of the file is a FACTOR FOUND row then gimps does not give proper credits. Does that answer make sense?[/QUOTE]
Hmm, yes I see. Thanks :smile: |
I rather thought that that was a feature, not a bug.:smile:
|
| All times are UTC. The time now is 08:18. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.