[QUOTE=TObject;325514]Are you the devil? LOL[/QUOTE]

Yes.

Alright,

The problem is on my end. I got home and checked and 5 of 6 systems we not running mfaktc. I don't know why, but I think it may have happened this morning before I left as the systems were getting low on assignments, I made sure the exponents got assigned, but I never checked to make sure they were running. So the stalled warnings all day were valid. If I would have checked... oh well. I'll track tonight and see if any more errors pop up.

[QUOTE=flashjh;325524]Alright,

The problem is on my end. I got home and checked and 5 of 6 systems we not running mfaktc. I don't know why, but I think it may have happened this morning before I left as the systems were getting low on assignments, I made sure the exponents got assigned, but I never checked to make sure they were running. So the stalled warnings all day were valid. If I would have checked... oh well. I'll track tonight and see if any more errors pop up.[/QUOTE]
Don't forget u can do a global status inquiry using the remote manager features.

and... Phew... Now I can get back to 2.4

[QUOTE=swl551;325525]Don't forget u can do a global status inquiry using the remote manager features.

and... Phew... Now I can get back to 2.4[/QUOTE]

I know, and it was stupid not to. The display showed each worker still had at least 1 assignment, but it hadn't updated. From now on I'll make sure to check before I leave for the day. And hopefully there won't be a next time.

Thanks again.

VERSION 2.4.B2 (beta) prep build for GPU72 fetching
 

VERSION 2.4.B2
[B]Major[/B] overhaul of code base to support fetching from GIMPS, GPU72 or External file. [B]GPU72 fetch is NOT implemented yet[/B], but so much has been changed it is important to regression test MISFIT against current functionality. The preparation for implementing GPU72 support forced me to rename many configuration variables to clarify if they were GIMPS specific, GPU72 specific or generic Work Fetching values. Currently the GPU72 work fetch button is disabled since it is not ready.

An improvement to the encryption key generation was done which will make MISFIT unable to decrypt your existing SMTP, GIMPS passwords. Once re-encrypted with 2.4.x you cannot go back to 2.3.x without reconfiguration.


As stated many configuration changes are in 2.4.x so please backup your existing MISFITconfig.txt before running 2.4.x and after you run it re-check ***ALL*** your configuration values as many will be set back to defaults.



Under the Process Control menu you can now "Force an Automated Work Fetch" which bypasses all conditional checks and executes the fetch using the configured values. [if you fetch via External OS command the command will be executed].




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

I've tested just about all the manual things, and so far it's all good except external fetching from G72.

I'm set for an automatic upload @ 1640 MST, I'll let you know how that goes.

The external fetch from G72 doesn't work as configured before. I keep getting a 100. If I run it from he cmd prompt, it runs fine. The batch file didn't work either from within MISFIT.

Lots of good updates...

[QUOTE=flashjh;325695]I've tested just about all the manual things, and so far it's all good except external fetching from G72.

I'm set for an automatic upload @ 1640 MST, I'll let you know how that goes.

The external fetch from G72 doesn't work as configured before. I keep getting a 100. If I run it from he cmd prompt, it runs fine. The batch file didn't work either from within MISFIT.

Lots of good updates...[/QUOTE]

If the GPUfetcher is in the same directory as MISFIT you don't need a bat file at all. If not in the same directory the paths must be fully specified. Your bat file may need to execute a CD/Chdir to the fetcher's directory before calling the fetcher. In other words the working directory for MISFIT is the MISFIT directory..

Keep me posted.

thx

Everything is in the same directory as misfit.exe. I didn't change anything for 2.4b2 except updating misfit.exe and running the configuration again. I went back to the old config and 2.3.2 and everything works fine. I tried 2.4b2 again and I get a 100...

Edit:
I just manually assigned the work I got in the cmd test above. MISFIT put the work into the workers, but it's not showing the additional number in FactorRows. I tired closing and restarting and also removing the blank line in the worktodo file. Nothing changed...

[QUOTE=flashjh;325702]Everything is in the same directory as misfit.exe. I didn't change anything for 2.4b2 except updating misfit.exe and running the configuration again. I went back to the old config and 2.3.2 and everything works fine. I tried 2.4b2 again and I get a 100...

Edit:
I just manually assigned the work I got in the cmd test above. MISFIT put the work into the workers, but it's not showing the additional number in FactorRows. I tired closing and restarting and also removing the blank line in the worktodo file. Nothing changed...[/QUOTE]


I'll walk through the code tonight.

Thanks for testing!

I have another update:

I have ~6500 GHz days of work in my files in 274 lines. MISFIT is set to the settings in the attachment. Since earlier, every hour MISFIT is still running the external fetcher is running even though it shouldn't be.

I thought it wasn't getting assignments because it's returning a 100, but [B]it is[/B] getting assignments (I have it set to 4 right now). But, it's not putting them into the stage file nor is it assigning/balancing them.

After I manually grabbed the assignments given to me throughout the day and put them in add work and assigned work, it put them into the files as expected. It also found 4 duplicates that I had checked. But, for some reason it missed 4 more duplicates (G72 showed 274, MISFIT showed 278). Once I clicked Balance All, it found the other 4.

Let me know if you have any tests you need me to run.

Edit:
I updated the picture because I think I may see an issue? The circled areas seem to conflict with each other now, maybe? I'm expecting MISFIT to only fetch assignments when below 375GHz Days AND MISFITWorktodo is below 200, but it's doing OR, right? I've set work source to disabled, for now ;)

One item at a time.
 

I have an answer for the 100 error message.
MISFIT is locking MISFITworkToDo.txt before it kicks off Gpu72WorkFetcher.exe at which time Gpu72WorkFetcher tries to lock MISFITWorkToDo.txt and cannot and Error 100 is generated.
FIX... [B]MISFIT should not lock the file when running external fetcher[/B]. It is up to the external fetcher to lock the file since MISFIT is not actually doing the file IO. No IO log is created in the Gpu72WorkFetcher log directory because nothing was fetched. [EASY FIX...]

other items to note:
Gpu72WorkFetcher has a config file with a value [B]ReloadWhenBelow[/B]:xxx if the destination file has more than this number of rows Nothing will get fetched regardless of the MISFIT configuration.


[B]Draining [/B]work from MISFITworkToDo is based on the remaining GHZDays as calculated from all the workToDo.txt files. [B]Fetching[/B] work is based on the number of rows in MISFITWorkToDo. They are mutually exclusive, but can be harmonized via configuration to ensure MISFITworkToDo.txt always has enough work to service any Drain event. I recommend MISFITWorkToDo.txt have several days of reserve work in it in-case there is a prolonged inability to fetch new work. (totally my opinion).

[B]EDIT:[/B]
Duplicate detection only occurs during work balance, either automated or manual. It is not part of any other event.
Fetching via Gpu72WorkFetcher.exe won't be needed much longer for MISFIT users, but this testing did find a bug so good job and don't worry too much about how the two will interact long term since they won't need to.

Let me fix the file-locking conflict and resume from there. Stand by 30 mins!