MISFIT for MFAKTx
 

Posts for MISFIT for MFAKTx

I was just re configuring MISFIT from scratch, I got this error.

I probably did something wrong. As Usual. Again.
[code]See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentOutOfRangeException: Number of copies to create must be strictly positive.
Parameter name: count
at System.Windows.Forms.DataGridViewRowCollection.Add(Int32 count)
at MISFIT.Form1.initDataGrid()
at MISFIT.Form1.ApplyConfigs()
at MISFIT.Form1.LoadConfigForm()
at MISFIT.Form1.timer2_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.296 (RTMGDR.030319-2900)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
MISFIT
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/mersenne/MISFIT/misfit.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1002 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1001 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1001 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.237 (RTMGDR.030319-2300)
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Numerics
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

[/code]

[QUOTE=kracker;332848]I was just re configuring MISFIT from scratch, I got this error.

[/QUOTE]

You did not specify any paths and clicked SAVE. Now MISFIT cannot resolve a most basic assumption.. A path to lookin.


I'll fix the code but a workaround is to edit MisfitConfig.Txt and manually add at least ONE path
[CODE]Lookin:c:\XYZ[/CODE]

[QUOTE=swl551;332857]You did not specify any paths and clicked SAVE. Now MISFIT cannot resolve a most basic assumption.. A path to lookin.


I'll fix the code but a workaround is to edit MisfitConfig.Txt and manually add at least ONE path
[CODE]Lookin:c:\XYZ[/CODE][/QUOTE]

Ok, thanks :smile: I'll do that.

Result was not needed
 

I've been reading some recent "poaching" stories. Should MISFIT analyze the response from gimps and Pop a warning message if [B]"Result was not needed"[/B] is detected?

Easy to do. If others think it is worth adding I'll do it.

The floor is open.

[QUOTE=swl551;333067]I've been reading some recent "poaching" stories. Should MISFIT analyze the response from gimps and Pop a warning message if [B]"Result was not needed"[/B] is detected?

Easy to do. If others think it is worth adding I'll do it.

The floor is open.[/QUOTE]

This won't often happen, but it's possibly worth the effort.

I am interested in the feature. Not necessarily against poaching, but sometime I myself send duplicated results (hm.. well... aging...), and it would be wonderful if MISFIT detects "error 40" or how it is called, and alert me. In case I am re-queuing work that I have already done, it is better to stop early and purge the worktodo file before wasting too much time. And it will help identify the poachers in an early stage too. Not that we can do too much against them, but maybe get out of their way? If one idiot has this fixed idea to TF exponents from 17.23M to 17.51M, well let him do it and take other range, there are enough exponents for everyone.

I know of at least a few of us that have messed up our own assignments and re-processed work we already did. Not a big deal, but sure would have been nice to know.

We got MISFIT running last night.

Some notes and questions:

It took us forever to set up email. We figured out (eventually) that if you have "two step verification" turned on for Gmail you need an application-specific password. And to use "TLS" you have to use a weird port number.

We didn't know we would need a batch file to start each instance. Creating a batch file was easy, though. (We think we need a batch file because we pass a command line argument to select which video card to run?)

Since the button to stop trial factoring kills all instances, we think (?) we can manually kill an instance, play a game and then restart the instance (manually) from the batch file and MISFIT will understand what happened. Is this sane? (This is real important for us to figure out, or we will not be able to play our game!)

Under the scheduling tab there is the choice to let MISFIT choose when to turn in results (based on number of hours?) versus scheduling particular times. Is there any reason to choose one over the other?

What does "Set process default directory" mean?

Why is there a pool of work separate from the individual worktodo.ini files?

Does MISFIT auto-adjust filling worktodo.txt files for slow versus fast cards or will we need to periodically "balance" them?

There are no "tooltips" when you hover the mouse around so we have no idea what most of the fields are or what they represent. Literally, the main screen is a total mystery to us. We are not complaining, because it appears to be working, so please do not think we are flaming anyone or anything. We are just overwhelmed by buttons.

We have attached our main screen and each of the configuration screens below. It would be so cool (for dumb people like us) to have a "manual" that explains each option or button. Or even the theory of what is happening. For example, what does "staged" mean? Or "drain"?

We feel like we have "Process Setup", "Work Fetch" (The calculator helped a lot!) and "Security" figured out. We are not sure about he rest.

Apologies in advance for our ignorance. We have resisted MISFIT, although we know it is awesome, precisely because it has so many options. We are afraid that we might break something. Plus, the OCD in us wants desperately to understand everything.

:mike:

I personally like to use the event scheduler to do uploads at a fixed time — selecting "odd" times like 27 minutes after the hour several times a day, every day of the week, staying away from the busy top of the hour GIMPS processing.

@Xyzzy
 

I'll do a "hover text" upgrade soon. Clearly there is a lot of material to deal with.

A few items for now:
1. Processes are not killed. They are sent the Ctrl-C signal so they can gracefully shutdown.

2. [B]Work balan[/B]cing has to be enabled if you want the pool of work to be auto-balanced for slow/fast GPUs. This will keep the FAST gpus from running out of work as it can (drain, bleed, work from the slow GPUs) You currently have it disabled.

3. Drain: To de-queue. Since assigning out work can be only a portion of the staged work the term "drain" is used instead of "empty".

4. Staging work allows you to freely manipulate the staged work without fear of messing up active workToDo files. It is strickly designed as a buffer.


Others can help you with their feedback too.

thanks