I am getting this STALL warning. I have a number of exponents in the original worktodo file and am letting them clear out manually.

How does this utility know the name of the worktodo file that I am using for mfaktc? Does it read my mfaktc configuration file?

[QUOTE=Chuck;327469]I am getting this STALL warning. I have a number of exponents in the original worktodo file and am letting them clear out manually.

How does this utility know the name of the worktodo file that I am using for mfaktc? Does it read my mfaktc configuration file?[/QUOTE]

worktodo.txt and results.txt must be named as stated and in the same directory as mfatkc. checkpoint files are created by mfaktc and are in the same directory as mfaktc. mfatkc.ini determines if checkpoint files are enabled (are by default) at 30 second interval.

You have NO work and a stall warning. So either mfaktc is no longer running or you don't have the configuration as stated above.

Or you have worktodo.txt somewhere else specified in mfaktc?

I usually keep my all worktodo's together, and they are named like "worktodo_DCTF.txt", "worktodo_332M.txt", etc. and select them from the mfaktc.ini, depending on my mood (what kinda work I want to do). Does that mean I can't use Misfit?

(I like the scimitar in your logo, however :razz:)

[QUOTE=swl551;327458]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[/QUOTE]

Hey Scott,

Nothing to be sorry for! You've gone above and beyond many times over already. My grasp of what an idea would entail to implement is next to nil. Besides, I'd get bored if there wasn't something for me to mess with by hand. MISFIT is marvel as it is. I don't want to tarnish that in any way. Believe me, it was just a "what if" moment from someone for whom just about all coding might as well be magic.

Thanks for everything from a happy user! :grin:
Kieren

[QUOTE=kladner;327479]
Thanks for everything from a happy user! :grin:
Kieren[/QUOTE]

+1. :smile:

[QUOTE=LaurV;327478]I usually keep my all worktodo's together, and they are named like "worktodo_DCTF.txt", "worktodo_332M.txt", etc. and select them from the mfaktc.ini, depending on my mood (what kinda work I want to do). Does that mean I can't use Misfit?

(I like the scimitar in your logo, however :razz:)[/QUOTE]
LaurV your config requirements would require product adjustments. Just not something I ca. Whip up. maybe a future release will read from mfaktx.ini files......maybe...


EDIT: Actually I won't be adding reading of mfaktx.ini files. The goal of MISFIT is to normalize/simplify,standardize your configuration so you don't have to do things like naming files "worktodo_DCTF.txt", "worktodo_332M.txt". I have no complaint that you like things distinct and customized, but not the direction I'm taking MISFIT.

sorry

[QUOTE=swl551;327472]worktodo.txt and results.txt must be named as stated and in the same directory as mfatkc. checkpoint files are created by mfaktc and are in the same directory as mfaktc. mfatkc.ini determines if checkpoint files are enabled (are by default) at 30 second interval.

You have NO work and a stall warning. So either mfaktc is no longer running or you don't have the configuration as stated above.[/QUOTE]

I would have to make some adjustments...I am running GIMPS and GPU72 in the same directory, using worktodo.txt for GIMPS and GPUworktodo.txt for GPU72.

I am hesitant to start making changes since this program as released is not working correctly on my system (UI overlaying, program as released won't run),

[QUOTE=Chuck;327466]No, nothing special here.[/QUOTE]

Chuck, I was able to reproduce a crash on startup exactly as you saw it. If you have configured Windows to start the app MAXIMIZED or MINIMIZED or anything else that will cause a form.resize event to occur before the form.load event occurs the crash happens.

It is actually an easy fix, but impossible for me to say why, with any authority, your OS is resizing the form before it loads.


Next release will have your fix in it.


As for your strange control spacing and alignments your screenshot shows still suggest something else is manipulating the form. Try setting Windows Visual Effect to BEST PERFORMANCE which remove all AERO and or other advanced UI presentation layer trickery.

thx

OK I have found the cause of the UI display problem...I have my text size display set to "medium" (125%) where normal is 100%. I temporarily changed it back to default and the UI displayed correctly.

You are going to have to deal with this. I am old and cannot comfortably read the display at the normal setting. No other programs I have ever used exhibit this behavior.

[QUOTE=Chuck;327491]OK I have found the cause of the UI display problem...I have my text size display set to "medium" (125%) where normal is 100%. I temporarily changed it back to default and the UI displayed correctly.

You are going to have to deal with this. I am old and cannot comfortably read the display at the normal setting. No other programs I have ever used exhibit this behavior.[/QUOTE]


Ok, I'll study the problem and figure out how to resolve it.
THANKS!!!

[QUOTE=swl551;327498]Ok, I'll study the problem and figure out how to resolve it.
THANKS!!![/QUOTE]

I think Scott has this fixed.

How do I get MISFIT to send email to my AOL email address? (I don't know what all this SMTP mumbo-jumbo is).

2.4.1 now available.
 

Version 2.4.1
1. [B]Added ability to fetch DCTF work from GPU72[/B]
2. standardized naming convention of the various files written to web_logs
3. Fixed unhandled exception bug if form.resize event fired before classes were initialized in form.load.
4. Fixed form to correctly adjust distance between [B]grid.bottom[/B] and [B]statuspanel.top[/B] when OS display is set to 125%. Scaling beyond 125% is not addressed since the form won't even fit on my monitor at greater than 125%

[url]http://mersenneforum.org/misfit/[/url]

[QUOTE=Chuck;327603]I think Scott has this fixed.

How do I get MISFIT to send email to my AOL email address? (I don't know what all this SMTP mumbo-jumbo is.[/QUOTE]

The problem is that in order to send mail, one needs an SMTP server to do it. In your case, when you log into your account, you're using AOL's SMTP servers whenever you hit the "send" button.

The configuration that MISFIT asks for should be exactly the same as what Outlook Express or Thunderbird might ask for. So Google "AOL Outlook setup" or something similar and that should help get you started.

[QUOTE=Dubslow;327606]The problem is that in order to send mail, one needs an SMTP server to do it. In your case, when you log into your account, you're using AOL's SMTP servers whenever you hit the "send" button.

The configuration that MISFIT asks for should be exactly the same as what Outlook Express or Thunderbird might ask for. So Google "AOL Outlook setup" or something similar and that should help get you started.[/QUOTE]

Rats. Why can't it just be "Enter email address".

[QUOTE=swl551;327605]Version 2.4.1
1. [B]Added ability to fetch DCTF work from GPU72[/B]
2. standardized naming convention of the various files written to web_logs
3. Fixed unhandled exception bug if form.resize event fired before classes were initialized in form.load.
4. Fixed form to correctly adjust distance between [B]grid.bottom[/B] and [B]statuspanel.top[/B] when OS display is set to 125%. Scaling beyond 125% is not addressed since the form won't even fit on my monitor at greater than 125%

[URL]http://mersenneforum.org/misfit/[/URL][/QUOTE]

Thanks! :smile:

EDIT: Just noticed.

[QUOTE=Chuck;327607]Rats. Why can't it just be "Enter email address".[/QUOTE]
Because if I did that the LaurV would have a reason to be paranoid about MISFIT's inner workings.

If you cannot get it to work with AOL (not tested by me).. It works fine with Gmail and Hotmail so setting up a [email]MISFIT_CHUCK@GMAIL.COM[/email] just for MISFIT to send email to your AOL account is totally reasonable.

[QUOTE=kracker;327608]Thanks! :smile:

EDIT: Just noticed.[/QUOTE]

I can't win. :bangheadonwall::bangheadonwall::bangheadonwall::bangheadonwall:

[QUOTE=swl551;327613]Because if I did that the LaurV would have a reason to be paranoid about MISFIT's inner workings.

If you cannot get it to work with AOL (not tested by me).. It works fine with Gmail and Hotmail so setting up a [EMAIL="MISFIT_CHUCK@GMAIL.COM"]MISFIT_CHUCK@GMAIL.COM[/EMAIL] just for MISFIT to send email to your AOL account is totally reasonable.[/QUOTE]

No I don't want another email account. When I try to set up AOL it says "The specified string is not in the form of an email address" when I send the test message, but I don't know which field it is talking about. Surely someone must know how to configure this....

The server is supposed to be smtp.aol.com and the port is 587

AOL Mail SMTP server address: smtp.aol.com AOL Mail SMTP user name: Your AOL Mail screen name (what comes before "@aol.com" in your AOL Mail address; if your address is [email]me@aol.com[/email], for example, the corresponding screen name is "me") AOL Mail SMTP password: Your AOL Mail password AOL Mail SMTP port: 587 AOL Mail SMTP TLS/SSL required: yes

[QUOTE=flashjh;327618]AOL Mail SMTP server address: smtp.aol.com AOL Mail SMTP user name: Your AOL Mail screen name (what comes before "@aol.com" in your AOL Mail address; if your address is [EMAIL="me@aol.com"]me@aol.com[/EMAIL], for example, the corresponding screen name is "me") AOL Mail SMTP password: Your AOL Mail password AOL Mail SMTP port: 587 AOL Mail SMTP TLS/SSL required: yes[/QUOTE]

Doesn't work.

[QUOTE=Chuck;327620]Doesn't work.[/QUOTE]

chuck the email is not from MISFIT. It is from you. Senders name must be YOUR email address in AOL.

[QUOTE=swl551;327613]Because if I did that the LaurV would have a reason to be paranoid about MISFIT's inner workings.[/QUOTE]
Not if you give the sources :razz:
There are plenty of free SMTP servers (sources) around, but putting one inside Misfit would really be smelly...






[COLOR=White]
(Man, I am teasing you, you don't need to do programs to make me happy, I am too old and being in this too long to change my habits now, I really appreciate what you are doing, this program evolved from nothing to a brilliant tool in very short time, and I really like the fact that you are continuously here, 24/7, to offer help and support, I only wish that you won't get tired of it! Don't worry about me, I can carry my own fur..).
[/COLOR]




.

[QUOTE=swl551;327622]chuck the email is not from MISFIT. It is from you. Senders name must be YOUR email address in AOL.[/QUOTE]


Well that works but makes no sense...it is from and to the same email address.

[QUOTE=Chuck;327624]Well that works but makes no sense...it is from and to the same email address.[/QUOTE]

I do that frequently in particular circumstances. From and To are the same. Any others are BCC's. I do it when I want to circulate an item to a number of people, but don't want to expose everyone's email address to everyone else on the list.

All right, [COLOR=red]THIS IS IT!!!!!![/COLOR][COLOR=black] I am moving mfaktc and its work files into a separate directory and I am going to start MISFIT. This is scary...:sos:[/COLOR]

[QUOTE=Chuck;327624]Well that works but makes no sense...it is from and to the same email address.[/QUOTE]

I didn't make up the rules for SMTP. What you filled out on that form is what is required to make it work. I do absolutely nothing to/with the values beyond passing them to the SMTP endpoint.

[QUOTE=Chuck;327632]All right, [COLOR=red]THIS IS IT!!!!!![/COLOR][COLOR=black] I am moving mfaktc and its work files into a separate directory and I am going to start MISFIT. This is scary...:sos:[/COLOR][/QUOTE]

Working........

Does the "Work progress" bar represent what I have finished in relation to the contents of the worktodo.txt file? The bar will advance as exponents are completed, then fall back when additional work is moved from the staging file into the worktodo file?

[QUOTE=Chuck;327640]Does the "Work progress" bar represent what I have finished in relation to the contents of the worktodo.txt file? The bar will advance as exponents are completed, then fall back when additional work is moved from the staging file into the worktodo file?[/QUOTE]


exactly :smile:

[QUOTE=swl551;327642]exactly :smile:[/QUOTE]

Look at my little gif image from a couple of posts back. Under the "WORKING" heading I see the current bit level 72-73, a vertical bar, a mysterious 3, then the exponent 61711537.

What is that 3 following the vertical bar?

[QUOTE=Chuck;327644]Look at my little gif image from a couple of posts back. Under the "WORKING" heading I see the current bit level 72-73, a vertical bar, a mysterious 3, then the exponent 61711537.

What is that 3 following the vertical bar?[/QUOTE]


3 is the max bit level for that assignment. so if it said 70-71|3 it mean you working the early stages from 70-71 where the max is 73. 72-73|73 would mean u on the final stage.

if you have stages=0 in mfaktc then you should turn this setting off in MISFIT's MISC configuration tab. However stages=1 is the default and the recommended setting for mfaktc

[QUOTE=swl551;327646]3 is the max bit level for that assignment. so if it said 70-71|3 it mean you working the early stages from 70-71 where the max is 73. 72-73|73 would mean u on the final stage.

if you have stages=0 in mfaktc then you should turn this setting off in MISFIT's MISC configuration tab. However stages=1 is the default and the recommended setting for mfaktc[/QUOTE]

Will the program create its MISFITWorktodo file on the first work fetch or should I make an empty one?

[QUOTE=Chuck;327647]Will the program create its MISFITWorktodo file on the first work fetch or should I make an empty one?[/QUOTE]

The program takes care of that.

[QUOTE=Chuck;327647]Will the program create its MISFITWorktodo file on the first work fetch or should I make an empty one?[/QUOTE]


click ADD WORK button then click the fetch button to forece an immediate fetch. that is best to confirm your configuration is correct. after that auto fetching will occur. Use the Work Calculator if you don't know what values to choose.

After MISFIT has been running minimized to the system tray, when I try to look at the program this window comes up. I cannot get the window to enlarge.

The program is fetching work, reporting the results, and sending me a status report via email. Everything is working EXCEPT I cannot get the window to enlarge to see what is going on.

[QUOTE=Chuck;327681]After MISFIT has been running minimized to the system tray, when I try to look at the program this window comes up. I cannot get the window to enlarge.

The program is fetching work, reporting the results, and sending me a status report via email. Everything is working EXCEPT I cannot get the window to enlarge to see what is going on.[/QUOTE]

Chuck, I found the cause of the window smashing. (If a form height calculation occurs while minimized the height of the form is totally incorrect afterwards) Solution: Don't calculate form size unless WindowState=Normal

However it is clear there are a lot more variables at play here than I anticipated and testing all UI scenarios will take a lot of time.

So you can do two things for now...

1. restart the app and don't minimize it.
2. download and assist in testing 2.4.1.1(test) version to help confirm I've addressed the [B]minimize[/B] issue. At this point I am not stating all the form size issues are addressed since there is a cascading effect here.

[QUOTE=swl551;327698]Chuck, I found the cause of the window smashing. (If a form height calculation occurs while minimized the height of the form is totally incorrect afterwards) Solution: Don't calculate form size unless WindowState=Normal

However it is clear there are a lot more variables at play here than I anticipated and testing all UI scenarios will take a lot of time.

So you can do two things for now...

1. restart the app and don't minimize it.
2. download and assist in testing 2.4.1.1(test) version to help confirm I've addressed the [B]minimize[/B] issue. At this point I am not stating all the form size issues are addressed since there is a cascading effect here.[/QUOTE]

I discovered that by repeatedly pressing F3, each press opens the window up a bit — about ten presses and it is almost back to normal size. Can't quite get the sixth button (below "Export results") exposed, but it is clickable.

If I download the new version, do I just need to unzip and replace the misfit.exe and everything else can stay the same? And can't you just allow the user to resize the window as desired?

[QUOTE=swl551;327646]3 is the max bit level for that assignment. so if it said 70-71|3 it mean you working the early stages from 70-71 where the max is 73. 72-73|73 would mean u on the final stage.[/QUOTE]

Another very cool feature! I had not really focused on that detail, and it is good to know the meaning. I take it that MISFIT only submits an assignment when all phases are done? Excellent if so! With manual submissions in earlier versions of mfaktc it could be confusing if a partial run was submitted, though GPU72 didn't count it as completed until the pledged level was fulfilled.
[insert many positive smileys here]

[QUOTE=kladner;327736]Another very cool feature! I had not really focused on that detail, and it is good to know the meaning. I take it that MISFIT only submits an assignment when all phases are done? Excellent if so! With manual submissions in earlier versions of mfaktc it could be confusing if a partial run was submitted, though GPU72 didn't count it as completed until the pledged level was fulfilled.
[insert many positive smileys here][/QUOTE]

MISFIT does not wait for all stages to be complete if STAGES=1. Set STAGES=0 to ensure only a single completed result is uploaded.

See mfaktX.ini for information on STAGES.

Thanks! :tu:

EDIT: I was aware of the Stages explanation in the .ini file, and Oliver also explained some time back why mfaktc 2.0 is more efficient with Stages=1. I'll have to track that down and re-read it. With previous versions I was in the habit of running Stages=0. But, as mentioned, GPU72 deals with partially done pledges just fine, so I'll stay with the more-efficient =1 setting. :smile:

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.

[QUOTE=Chuck;328210]I guess I would opt for the % fetching. The DCTF would need its own range selection in addition to the LLTF.[/QUOTE]

yes, differing bit levels would be a requirement.

I still recommend the GPU72WorkFetcher as an interim solution.

[QUOTE=Chuck;328210]I guess I would opt for the % fetching. The DCTF would need its own range selection in addition to the LLTF.[/QUOTE]

Actually, (and I hope I'm not "speaking out of school" here), I suggested to Scott that he offer those who do both LLTFing and DCTFing the option of balancing their reservations based on either % of candidates, or % of GHzDays.

[QUOTE=chalsall;328212]Actually, (and I hope I'm not "speaking out of school" here), I suggested to Scott that he offer those who do both LLTFing and DCTFing the option of balancing their reservations based on either % of candidates, or % of GHzDays.[/QUOTE]

No, you are not. "We (anyone who chimes in)" are exploring the options so any ideas are useful.

The percentage fetching with ranges and bit levels specified would be very cool, though I've only recently thrown some DCTF into my pot. :stirpot:

[QUOTE=swl551;328211]yes, differing bit levels would be a requirement.

I still recommend the GPU72WorkFetcher as an interim solution.[/QUOTE]

But that doesn't put in the work as next to be processed, right? It would add in at the end of the existing queue. I have the fetcher, as I was using it before MISFIT.

[QUOTE=Chuck;328236]But that doesn't put in the work as next to be processed, right? It would add in at the end of the existing queue. I have the fetcher, as I was using it before MISFIT.[/QUOTE]
Correct, it appends to bottom of queue. If you have good, ongoing, mixing ratio of LLTF/DCTF why does it matter exactly when it is processed. *help me understand so I can try to see the overall functionality*

[QUOTE=swl551;328240]Correct, it appends to bottom of queue. If you have good, ongoing, mixing ratio of LLTF/DCTF why does it matter exactly when it is processed. *help me understand so I can try to see the overall functionality*[/QUOTE]

I just WANT it to start NOW. That's all.

[QUOTE=Chuck;328245]I just WANT it to start NOW. That's all.[/QUOTE]

Hey Chuck,

I mean no offense, but this seems a bit much. Throughout the development of MISFIT, most, if not all the users have seemed to want assignments to remain in order of their age. Scott has worked to accommodate that. If I understand correctly, you want the program to change on demand to "insert on Line 2" of worktodo.txt. I have no idea how much work this might entail, not being a programmer. I'm sure you have reasons for wanting it.

However, I do think that Scott has gone out of his way to resolve other issues for you, and has done so on a very short turn around. Perhaps this level of tweaking is best done manually. :two cents:

Just for the record, my comment above about percentage fetching stated that it would be "very cool". That should not be taken as a demand. I'm happy with shoving things around by hand, especially since MISFIT is there to clean up my mistakes which could result in duplicating work. :smile:

2.4.3 (final release addressing screen scaling issues) [i hope]
 

Version 2.4.3
1. Added logging of the raw HTML from a GIMPS fetch.
2. Added detection and alerting if no assignments returned from GIMPS/GPU72 where no I/O error occurred. (fetch log file will show what actually happened)
3. Global Work Report is now always generated PRE-work fetch and PRE results upload. The reports are stored in the WEB_LOGS directory. Emailing of the reports is optional.
4. Removed prototype feature allowing random determination of GPU72 work types to fetch.
5. Significant retesting and additional minor tweaks related to proper form sizing when OS display is set to scale over 100%

Get from [url]http://mersenneforum.org/misfit/[/url]

[QUOTE=kladner;328252]

However, I do think that Scott has gone out of his way to resolve other issues for you, and has done so on a very short turn around. Perhaps this level of tweaking is best done manually. :two cents:

Just for the record, my comment above about percentage fetching stated that it would be "very cool". That should not be taken as a demand. I'm happy with shoving things around by hand, especially since MISFIT is there to clean up my mistakes which could result in duplicating work. :smile:[/QUOTE]

Of course; I wouldn't expect the program to incorporate every far-fetched idea. If I'm near the computer I can add work manually as desired. When I'm not, it works in the way MISFIT feeds it. The % is appealing though.

MISFIT generates a lot of logging. After it is set up and running smoothly, these are of not much interest to me. Does the program have any provisions for periodic removal of old log information?

[QUOTE=Chuck;328298]MISFIT generates a lot of logging. After it is set up and running smoothly, these are of not much interest to me. Does the program have any provisions for periodic removal of old log information?[/QUOTE]

You are on your own deleting logs.

[QUOTE=swl551;328300]You are on your own deleting logs.[/QUOTE]

Maybe a provision for no logging?

I'm loath to comment on misfit since I do not use it (I could not be happier with GPU72WorkFetcher!) I can see where having an option to keep x days of logs would be nice.

Still though, you can do this with a scheduled task. for windows XP the task command would be:
[QUOTE]forfiles -p "C:\what\ever" -s -m *.log -d <number of days> -c "cmd /c del @path"
[/QUOTE]
and for windows 7 it would be
[QUOTE]forfiles -p "C:\what\ever" -s -m *.log /D -<number of days> /C "cmd /c del @path"
[/QUOTE]
where "C:\what\ever" is the folder your misfit log files is in, and *.log is the file mask for the log files. Someone else might be able to make that command more applicable to misfit, as I don't know what file extention the logs use.

To be extra explicit, if I wanted to delete all .log files from the "c:\misfit\logs" folder that were older than 7 days (On windows 7) I'd start a scheduled task to run daily, and the task command would be
[QUOTE]forfiles -p "C:\misfit\logs" -s -m *.log /D -7 /C "cmd /c del @path"
[/QUOTE]

[QUOTE=Aramis Wyler;328316]I'm loath to comment on misfit since I do not use it (I could not be happier with GPU72WorkFetcher!) I can see where having an option to keep x days of logs would be nice.[/QUOTE]

This is very helpful, thanks. Still, I think management of the logging should be part of the application

[QUOTE=Aramis Wyler;328316]I'm loath to comment on misfit since I do not use it (I could not be happier with GPU72WorkFetcher!) I can see where having an option to keep x days of logs would be nice.

Still though, you can do this with a scheduled task. for windows XP the task command would be:

and for windows 7 it would be

where "C:\what\ever" is the folder your misfit log files is in, and *.log is the file mask for the log files. Someone else might be able to make that command more applicable to misfit, as I don't know what file extention the logs use.

To be extra explicit, if I wanted to delete all .log files from the "c:\misfit\logs" folder that were older than 7 days (On windows 7) I'd start a scheduled task to run daily, and the task command would be[/QUOTE]

Excellent solution as I will not be turning off or managing log files in any way. 2 meg of disk space is not worth my time.

[QUOTE=Chuck;328323]Still, I think management of the logging should be part of the application[/QUOTE]

I agree.

[QUOTE=chalsall;328359]I agree.[/QUOTE]
Me to.

[QUOTE=swl551;328407]Me to.[/QUOTE]

:loco:

[QUOTE=swl551;327410]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.[/QUOTE]
My mind is still stuck in the old days of mfaktc when you had to take the cpu cores into consideration, so I still designate them as only DC and on LL. (I had 7 GPUs running on 19 cores) My spider machine to report results went down, and I have not had the time to diagnose it or resetup what I had on this machine.

Basically I have 2 GTX 480's running LLTF and 2 GTX 560's running DCTF, but the machines (while connected by lan) are not close physically. I currently use Windows Explorer to look at the networked drives and add more assignments when the worktodo filesize < 1kb. I also (daily, if I remember) copy the results to a temp file to upload to primnet and mersenne.ca and when finished copy the results to a master result file.

I would prefer to be able to run 1 or 2 instances from the main computer and lock the GPUs to their current work types.

[QUOTE=bcp19;328453]My mind is still stuck in the old days of mfaktc when you had to take the cpu cores into consideration, so I still designate them as only DC and on LL. (I had 7 GPUs running on 19 cores) My spider machine to report results went down, and I have not had the time to diagnose it or resetup what I had on this machine.

Basically I have 2 GTX 480's running LLTF and 2 GTX 560's running DCTF, but the machines (while connected by lan) are not close physically. I currently use Windows Explorer to look at the networked drives and add more assignments when the worktodo filesize < 1kb. I also (daily, if I remember) copy the results to a temp file to upload to primnet and mersenne.ca and when finished copy the results to a master result file.

I would prefer to be able to run 1 or 2 instances from the main computer and lock the GPUs to their current work types.[/QUOTE]

MISFIT will work fine. You will like the REMOTE CONTROL feature which allows you to INQUIRE, STOP,START, SAFE-REBOOT, FORCE-REBOOT. Stalled process detection.
You can keep the work split or commingle, that is just an implementation detail.

Enjoy.

2.3.4.1 with prototype Log Purger is out there
 

It will give you an idea of how it will work once I account for all directories


under the configurtion|MISC tab.


thx

[QUOTE=swl551;328533]It will give you an idea of how it will work once I account for all directories

thx[/QUOTE]


Excellent. Thanks :hello:

Oh the IRONY...
 

The Log purger has to write out a log indicating it purged logs.


I love it!

The log purger is done...
 

The log purger is done...

I have decided not to build the DC/LL mixer since there is low interest in DCTF and existing functionality already allows you to fetch DCTF work. It was a good idea but is expensive to build with little R.O.I.



So, do I release log purging now or wait until I have a release with a larger change set?

[QUOTE=swl551;328672]The log purger is done...

So, do I release log purging now or wait until I have a release with a larger change set?[/QUOTE]

Your call...the batch file Aramis described earlier is working for me and I can use it until the "purging" MISFIT is released (then I can delete the scheduled tasks).

What other changes are in the pipeline?

[QUOTE=Chuck;328764]Your call...the batch file Aramis described earlier is working for me and I can use it until the "purging" MISFIT is released (then I can delete the scheduled tasks).

What other changes are in the pipeline?[/QUOTE]
Currently no changes. We are reaching the functional plateau of this utility. Occasional minor tweaks, but I just don't see anything taking 100s of hours like previous builds have.

reconsidered and removed post

Rewritten duplicate assignment detection report.
 

A long standing gap in MISFIT is duplicate detection across active workers and the [B]staged[/B] work. The lack of this feature really came to light yesterday when everyone was turning in work, hand editing all files and essentially producing the conditions where duplicates could be introduced through mass change.

In the attached screenshot you can see the new report file. It is a .CSV, already sorted by exponent and the example we have duplication both within the worker and spanning into the staged file. The red circled item is not a duplicate because its bit level is different. The report can be launched to evaluate the bit level as part of the duplicate determination or just look at exponents.

This report is not automated and is purely a diagnostic tool.
Please comment if you have any additional ideas on this specific feature.

Scott

That looks very useful. Just open it in a spreadsheet and have a look. :tu:

[QUOTE=kladner;328851]That looks very useful. Just open it in a spreadsheet and have a look. :tu:[/QUOTE]

It puts the [B]<---- DUPLICATE [/B] marker on the line as part of the detection. (not sure if you picked up on that).

Also the new configuration to include [B]bit level[/B] evaluation as part of duplicate exponent detection is used in the following:
1. in the new duplicate report
2. detecting duplicates during GridStatsUpdate
3. detecting and tossing duplicates during WorkBalance

[QUOTE=swl551;328853]It puts the [B]<---- DUPLICATE [/B] marker on the line as part of the detection. (not sure if you picked up on that).

Also the new configuration to include [B]bit level[/B] evaluation as part of duplicate exponent detection is used in the following:
1. in the new duplicate report
2. detecting duplicates during GridStatsUpdate
3. detecting and tossing duplicates during WorkBalance[/QUOTE]

Even better! :grin: I had not realized that was part of the process.

I remember that there is a problem with Primenet's parsing of results if the first result submitted is a "factor found"; Primenet considers it to be a P-1 result if there are no preceeding "no factor" lines in the submission.

Does MISFIT do any reordering of results submitted to avoid this?

[QUOTE=Chuck;328861]I remember that there is a problem with Primenet's parsing of results if the first result submitted is a "factor found"; Primenet considers it to be a P-1 result if there are no preceeding "no factor" lines in the submission.

Does MISFIT do any reordering of results submitted to avoid this?[/QUOTE]

Yes it does.

Version 2.4.4 released....
 

Version 2.4.4
1. Added purging of all MISFIT generated logs. Checking is performed roughly every six hours and is set and forget (cannot be triggered manually). Configured in the MISC tab. **GPU72FETCH_logs which is not part of MISFIT and not purged

2. Added global exponent duplicate detection report. Detection is for everything in inventory, workToDo(s) and MISFITworkToDo files.

3. Added configuration to assess bit level as part of any duplicate detection procedure. It can turned on in the config|MISC tab.
If bit level evaluation is turned on the following example assignments would NOT be considered as having duplicate exponents
55555544,71,72
55555544,72,73
55555544,72,75
55555544,75,45

If bit level evaluation is enabled it will impact the results of the following procedures:
a. global exponent duplicate report
b. detecting duplicates during GridStatsUpdate
c. detecting and tossing duplicates during WorkBalance

Get from [url]http://mersenneforum.org/misfit/[/url]

Sounds great. You can probably disregard most of the PM which I cross-posted with yours above.

Hell yeah, the purge actually works now!.... *poke poke* :smile:

Thanks. :smile:

EDIT: the above to swl551.

Would anyone object...
 

Putting this out there for discussion...

Since Scott has done such a wonderful job of "taking the human out of the loop", would anyone object if I remained in the loop?

Specifically, I'm wondering if anyone would object to the idea that when GPU72 sees a request for assignments from a MISFIT-TF-FETCHER client with the "What Makes Sense" option set, that the system ignores all the other settings (i.e. Range and TF level), and issues assignments (of the worktype requested; as in if LLTF is requested it will be issued, same with DCTF) which makes the most sense for GIMPS as a whole?

If any other option was set (i.e. Lowest TF level, etc.) the system would honor the request explicitly as best it could.

The reason I ask is there is a [U]chance[/U] we won't have to release at 72 -- although I very much appreciate everyone's diligence in building a buffer to there in case we do need to.

But if the "surge" subsides and we have the time to go to 73, rather than asking everyone to change (once again) their MISFIT settings, I could simply make one change in one Perl script and everyone using MISFIT would be doing what really "Makes Sense"[SUP](TM)[/SUP].

Thoughts?

[QUOTE=chalsall;328878]Putting this out there for discussion...

Since Scott has done such a wonderful job of "taking the human out of the loop", would anyone object if I remained in the loop?

Specifically, I'm wondering if anyone would object to the idea that when GPU72 sees a request for assignments from a MISFIT-TF-FETCHER client with the "What Makes Sense" option set, that the system ignores all the other settings (i.e. Range and TF level), and issues assignments (of the worktype requested; as in if LLTF is requested it will be issued, same with DCTF) which makes the most sense for GIMPS as a whole?

If any other option was set (i.e. Lowest TF level, etc.) the system would honor the request explicitly as best it could.

The reason I ask is there is a [U]chance[/U] we won't have to release at 72 -- although I very much appreciate everyone's diligence in building a buffer to there in case we do need to.

But if the "surge" subsides and we have the time to go to 73, rather than asking everyone to change (once again) their MISFIT settings, I could simply make one change in one Perl script and everyone using MISFIT would be doing what really "Makes Sense"[SUP](TM)[/SUP].

Thoughts?[/QUOTE]

I see the idea as very high value since we all want to do what is right.
Another option would be the LLTF and DCTF pages accept an option value equating to "Mission Specialty" this would allow the "Fallback to what makes sense" still viable if the Mission Specialty ran dry or was cancelled/completed.

[QUOTE=swl551;328884]I see the idea as very high value [U]since we all want to do what is right[/U].[/QUOTE]

That's not entirely true -- most want to do what is best for GIMPS, but some want to do very specialized work. Particular ranges; find the most factors, etc. All work is valuable, so in the long run all work is good for GIMPS, but sometimes some want to do what [I]doesn't make the most sense at this particular moment in time[/I].

Since this is a volunteer effort, everyone should be allowed to do whatever they want with their own electricity, hardware and time (so long as there's no negative impact on the project or any other participant).

[QUOTE=swl551;328884]Another option would be the LLTF and DCTF pages accept an option value equating to "Mission Specialty" this would allow the "Fallback to what makes sense" still viable if the Mission Specialty ran dry or was cancelled/completed.[/QUOTE]

That's what I envisioned all the other options are.

The issue is I have sort of painted myself into a corner. The web-interface was never intended to be spidered. As in, before MISFIT there was a human in the loop who could see if the options they were specifying (Option, Ranges, Pledge level) resulted in no available assignments.

If I had been smarter, the "What Makes Sense" option would have always ignored all the other settings. But, as has been demonstrated, I'm not that smart...

This is why I initially discouraging you from using the "intended for a human in the loop" interface. I had hoped to be able to expose an API appropriate for automation. But then life (and a death) happened, and I realized there was a serious vacuum which needed to be filled and you were keen to fill it.

So the question at hand is how do we best deal with what we have available right now. Specifically, I'm asking if anyone would mind if the "What Makes Sense" behavior changed when a human isn't in the loop.

Edit: Unlike Micro$oft, I don't like changing the behavior of things without notice.

I'd rather see this as a 5th dropdown option in gpu72, such that it affects all users and all methods, and not something specific to misfit.

I think that was clear, but to be extra repetitive, I'd like to see a 5th option on the dropdown on the gpu72 web site that says 'Do what Chris wants' or the like (ha!) and nothing on the form matters (but you get the preview).

There would be no change to the workfetcher or misfit (except that '5' or '0' would be a legal option).

[QUOTE=Aramis Wyler;328887]I'd rather see this as a 5th dropdown option in gpu72, such that it affects all users and all methods, and not something specific to misfit.[/QUOTE]

Sorry... I should have been clearer...

To any human accessing the Assignment forms there should be no changes needed, since I can already update the default settings which the human sees (and the preview shows the results of) as the real-time situation requires.

My proposal is only for MISFIT users, who only yesterday had to change their "pledge" setting from 73 to 72 even though most already had "What Makes Sense" as the option.

Again, this is actually a mistake I made long ago -- WMS should have always ignored all the other settings.

Just to be sure...
 

MISFIT and the stand-alone workFetcher both pass in the same UserAgent string. I can make them unique if required.

[QUOTE=swl551;328890]MISFIT and the stand-alone workFetcher both pass in the same UserAgent string. I can make them unique if required.[/QUOTE]

Thanks, but no need.

I've seen a couple of users using human-driven browsers which didn't provide a UA string. With the MISFIT... UA string I know a human isn't in the loop, and the system can act accordingly.

I won't make the proposed change until we hear back from some more humans.

I think it's a great idea as I just enjoy helping GIMPS as much as possible (though the occasional side project is fun too). This will allow the system to be a bit more flexible. I have often wondered if it would be possible to implement a live-feed system where the work is flexed on demand depending on what was best. This answers my question. :smile:

Just remember that it won't be quite as responsive as the change we all made yesterday, depending on how much work each user has stored up.