I don't like the concept of closed-source software, but I respect your decision. Hopefully nobody decides to send an assassin to your house or anything. :smile:

C# is relatively easy to decompile anyway, so it wouldn't be [I]too[/I] hard for someone to inspect the source code. But I highly doubt anyone here would use it for unlicensed modifications, etc.

For the record, early versions of MISFIT did come with the source code: [url]http://www.mersenneforum.org/showpost.php?p=307024&postcount=11[/url]

[QUOTE=ixfd64;330863]I don't like the concept of closed-source software, but I respect your decision. Hopefully nobody decides to send an assassin to your house or anything. :smile:

C# is relatively easy to decompile anyway, so it wouldn't be [I]too[/I] hard for someone to inspect the source code. But I highly doubt anyone here would use it for unlicensed modifications, etc.

For the record, early versions of MISFIT did come with the source code: [URL]http://www.mersenneforum.org/showpost.php?p=307024&postcount=11[/URL][/QUOTE]

Well as I stated earlier today MISFIT has reached its functional plateau so releasing source code now wouldn't really position someone to "compete against me" and take away the fun.

I'm guessing 2.4.6 "Let Gpu72 Decide" is working ok.
 

No news is good news....


I didn't really expect any problems but just wanted to be sure Chalsall and I satisfied everyone's wishes on GPU72 #9.

[QUOTE=swl551;331019]No news is good news....


I didn't really expect any problems but just wanted to be sure Chalsall and I satisfied everyone's wishes on GPU72 #9.[/QUOTE]

It seems to perform as described, with a range of bit levels obtained.

[QUOTE=swl551;331019]No news is good news....


I didn't really expect any problems but just wanted to be sure Chalsall and I satisfied everyone's wishes on GPU72 #9.[/QUOTE]

Looks OK

On the bright side, this tread is getting large, as more people starting using misfit. I think (and I will vote for it!) this toy deserves its own subforum (like yafu has) where we could make threads like "support request", "bugs", "features request", bla bla. Any supermod willing to do the subforum. Thanks in advance.

On the dark side, I have big problems with "stalling" feature. I like the (idea of) such feature, i.e. to have some bell ringing (and maybe some alert mail sent) when there are troubles, so the user acknowledge the problem, and take action.

But you see, my problem is: there are 5 instances working, and in 80% of the time, at least one of them is "stalled". None of them is stalled, but misfit thinks so. No mater what setting I make in mfaktc, and/or misfit (except disabling the feature).

The root cause is the fact that one assignment in the 332M where I work now, to 72 bits, takes between 4:58 and 5:11 minutes on the cards I have.

Misfit detects that "the things are moving" from the changing of the checkpoint files. This [B]"method number 1"[/B] (I only use this name for the current method used by misfit, to make clear what I refer to) is good for long assignments, where other files (result, worktodo) changes very seldom. The user can set mfaktc to make checkpoints every 30 minutes, one, two hours, or so, and have misfit checking at a longer interval, to detect if the program is still doing useful work. Or have a shorter check interval, with repetition (I really like this repetition thing, it is a wonderful idea!).

But the [B]"method number 1"[/B] is totally not appropriate for short assignments. First of all, it makes no sense to stress the harddisk doing checkpoints for assignments that take 5 minutes. But I am going to step on my own hand and put in mfaktc.ini creating checkpoints every 2 or 3 minutes. But this is still futile, beside of the fact that it kills the hdd. Why is futile? very simple, it is called "resonance". Or "interference". Whatever.

Example: Say for the sake of the example that an assignment takes 5 minutes and 1 second (5:01). I set misfit to check stalling every 5 minutes (or 10, or 15, or one hour, it really makes no difference, I will use 5 minutes for the example). I set the "number of times bla bla" to 3, or 5, or 20, it really makes no difference (immediately you will see why). I set mfaktc to make checkpoints every 1, or 2, or 3 minutes (anything smaller then 5 minutes and one second, the duration of the assignment). Say we use 3 minutes. This means the checkpoint files are created after 3 minutes, and deleted after 5:01 (assignment finish), another one is created at 8:01, deleted at 10:02, the third one created at 13:02, deleted at 15:03, etc. You got the idea? Even if misfit checks every 5 minutes, he detects "new checkpoint", "new checkpoint", "new checkpoint", "new checkpoint", "new checkpoint", after a wile they shift apart from each-other, each assignment offsets it with one second, so after 121 assignments are finished, misfit will read "in the holes", i.e. in the periods where there is no checkpoint file. Then "hole", "hole", "hole", "hole", "hole", "hole", "hole", for another 180 assignments. It is no use if I put the "number of bla bla" even to 50 or 100, it still says is stalled, after 8-10 hours, and because there are 5 instances running (and some of them TF to 73 bits, which takes 9-10 minutes) they shift in such a way that one looks "stalled" to misfit, the most of the time, no matter what settings I use.

For this "short time assignments", a [B]"method number 2"[/B] should be used, like checking the changes in size for worktodo or result files. This would work much better, and I believe that the program should implement a "nor" algorithm (give alerts if nor the checkpoints, nor results, nor wortodo files change in sizes, or whatever. Also, an idea is to randomly change the time of checking, like for example, if I put 5 minutes, he should generate a number which is +/-10% of my setting interval, i.e. between 270 and 330 seconds (instead of always 300) and THAT should be next scheduled time. In this way we avoid "resonance". Also, a third way (but not so professional, because it will still force me to make checkpoints for short assignments, but is much simple to implement) is to alow misfit to check ever minute, or every 30 seconds, etc. Right now the minimum time settable by interface is 5 minutes (totally futile for 3-minutes assignments for example). I tried to edit the misfitconfig.txt by hand to use 1 minute, but it is not considered by the program, and it is changed back to 5 when I open the config editor from the menu.

Opinions?

I just did a small artwork to make the understanding easier. No matter the interval one creates checkpoints, and no matter misfit settings. [B]After a while[/B] (due to the fact that checkpoint files are always deleted when the assignment is done, and they are created again when mfaktc.ini says so, and the assignment time is not an exact multiple of misfit checking time) [B]there will be a shift.[/B] And during this shift, misfit will read "no checkpoint file", (he creates his _faux file, but this is not relevant to the discussion) for an arbitrarily large number of times (can be thousands, depends of those two periods, see the red stars in the diagram). And then "bink, blink, you are stalled", when in fact mfaktc works perfectly.
[ATTACH]9464[/ATTACH]

[QUOTE=LaurV;332169]Opinions?[/QUOTE]

I raised this exact issue earlier.

The term I used was "harmonic", but the idea is the same.

Yep. I just searched for it, and indeed you said it, it is on page 10 of this current thread. At that time I had no idea what "harmonic"** you were talking about. Now it totally makes sense for me when I read your post.

edit: Jerry (which was the "counterargument" that time, with his big farm and never met the issue) is only doing "long term" assignments, like 60M to 73 or so, which takes 10-12 times longer (like one hour, etc). For me now the best way is to disable the feature, otherwise I have almost always a red-alert blinking somewhere.

edit 2: ** [URL="http://en.wikipedia.org/wiki/Harmonica"]harmonic[/URL].

[QUOTE]I think (and I will vote for it!) this toy deserves its own subforum (like yafu has) where we could make threads like "support request", "bugs", "features request", bla bla.[/QUOTE]What forum should it be a subforum of?

[QUOTE=LaurV;332169]On the bright side, this tread is getting large, as more people starting using misfit. I think (and I will vote for it!) this toy deserves its own subforum (like yafu has) where we could make threads like "support request", "bugs", "features request", bla bla. Any supermod willing to do the subforum. Thanks in advance.

On the dark side, I have big problems with "stalling" feature. I like the (idea of) such feature, i.e. to have some bell ringing (and maybe some alert mail sent) when there are troubles, so the user acknowledge the problem, and take action.

But you see, my problem is: there are 5 instances working, and in 80% of the time, at least one of them is "stalled". None of them is stalled, but misfit thinks so. No mater what setting I make in mfaktc, and/or misfit (except disabling the feature).

The root cause is the fact that one assignment in the 332M where I work now, to 72 bits, takes between 4:58 and 5:11 minutes on the cards I have.

Misfit detects that "the things are moving" from the changing of the checkpoint files. This [B]"method number 1"[/B] (I only use this name for the current method used by misfit, to make clear what I refer to) is good for long assignments, where other files (result, worktodo) changes very seldom. The user can set mfaktc to make checkpoints every 30 minutes, one, two hours, or so, and have misfit checking at a longer interval, to detect if the program is still doing useful work. Or have a shorter check interval, with repetition (I really like this repetition thing, it is a wonderful idea!).

But the [B]"method number 1"[/B] is totally not appropriate for short assignments. First of all, it makes no sense to stress the harddisk doing checkpoints for assignments that take 5 minutes. But I am going to step on my own hand and put in mfaktc.ini creating checkpoints every 2 or 3 minutes. But this is still futile, beside of the fact that it kills the hdd. Why is futile? very simple, it is called "resonance". Or "interference". Whatever.

Example: Say for the sake of the example that an assignment takes 5 minutes and 1 second (5:01). I set misfit to check stalling every 5 minutes (or 10, or 15, or one hour, it really makes no difference, I will use 5 minutes for the example). I set the "number of times bla bla" to 3, or 5, or 20, it really makes no difference (immediately you will see why). I set mfaktc to make checkpoints every 1, or 2, or 3 minutes (anything smaller then 5 minutes and one second, the duration of the assignment). Say we use 3 minutes. This means the checkpoint files are created after 3 minutes, and deleted after 5:01 (assignment finish), another one is created at 8:01, deleted at 10:02, the third one created at 13:02, deleted at 15:03, etc. You got the idea? Even if misfit checks every 5 minutes, he detects "new checkpoint", "new checkpoint", "new checkpoint", "new checkpoint", "new checkpoint", after a wile they shift apart from each-other, each assignment offsets it with one second, so after 121 assignments are finished, misfit will read "in the holes", i.e. in the periods where there is no checkpoint file. Then "hole", "hole", "hole", "hole", "hole", "hole", "hole", for another 180 assignments. It is no use if I put the "number of bla bla" even to 50 or 100, it still says is stalled, after 8-10 hours, and because there are 5 instances running (and some of them TF to 73 bits, which takes 9-10 minutes) they shift in such a way that one looks "stalled" to misfit, the most of the time, no matter what settings I use.

For this "short time assignments", a [B]"method number 2"[/B] should be used, like checking the changes in size for worktodo or result files. This would work much better, and I believe that the program should implement a "nor" algorithm (give alerts if nor the checkpoints, nor results, nor wortodo files change in sizes, or whatever. Also, an idea is to randomly change the time of checking, like for example, if I put 5 minutes, he should generate a number which is +/-10% of my setting interval, i.e. between 270 and 330 seconds (instead of always 300) and THAT should be next scheduled time. In this way we avoid "resonance". Also, a third way (but not so professional, because it will still force me to make checkpoints for short assignments, but is much simple to implement) is to alow misfit to check ever minute, or every 30 seconds, etc. Right now the minimum time settable by interface is 5 minutes (totally futile for 3-minutes assignments for example). I tried to edit the misfitconfig.txt by hand to use 1 minute, but it is not considered by the program, and it is changed back to 5 when I open the config editor from the menu.

Opinions?[/QUOTE]

My opinion is this:
The missed detection of [B]short duration checkpointing[/B] is a limitation of my design. I have highlighted it myself in discussions.

Using WorkToDo as a component of the detection should resolve the issue.

Laurv: I'll have a release in a day or two for you to test.