(archive)MISFIT

[swl551]

Originally Posted by flashjh

It's easiest to use the MISFIT stage file, but you can still stop all your workers and close MISFIT, manually add exponents and then restart MISFIT.

You can also double click the ER cell on the grid to open the integrated editor. If you then click the EDIT button a lock is placed on the workToDo file to prevent IO collision. NOTE only MISFIT and MFAKTO implement the .LCK file locking system.

See MISFIT changelog for details on that implementation.

[Chuck]

I will only have one instance; simply going from one staging file to my worktodo file.

[swl551]

Originally Posted by Chuck

I will only have one instance; simply going from one staging file to my worktodo file.

The staging file serves two distinct purposes.
1. place to load up, organize, play with work without fear of compromising actual workTodo files

2. provides a single entry point to queue up work to be assigned out when required by the workers. A bit less meaningful if you have only one mfaktX instance, but still high functioning.

[flashjh]

One thing I'll point out is that if you get an assignment you want worked immediately then you either have to stop MISFIT and add the assignment manually or stop the worker, double click the ER column and edit the file manually and then restart the worker.

[kladner]

I started using Version 2.4.b13 yesterday and can report full success with Native Fetching.

I did have to work out a SUE, or CUE (Silly/Stupid User Error or Careless User Error.) Last night I completely drained MISFITworktodo.txt so I could test Fetching. I have MISFIT set to get 30 assignments at a time when GHz-Days falls below 500. This morning, I found that it had retrieved 5x30=150 assignments with single bit levels. After scratching my head a bit I realized that the default bit level of 60 had cause GPU72 to deliver the next available level i.e. 70-71. Fortunately, all of these assignments were still in the MISFIT staging file, so it was a simple matter to delete them there and unreserve them in GPU72.

I am amazed how far this app has come in such a short time. Many thanks, Scott!

[swl551]

Originally Posted by kladner

....default bit level of 60 had cause GPU72 to deliver the next available level i.e. 70-71.

Can you look in the web_logs directory for GPU72FETCHxxx.html to see if the response contained "Sorry... No assignments available which match your criteria."

If you see those then it was a good test of the "Failback" feature. If you don't see that then GPU72 auto-upgraded your pledge past from 60 to 71 all by itself. (just curious which engine got you those bit levels.)

Thanks!

Scott

[chalsall]

Originally Posted by swl551

If you don't see that then GPU72 auto-upgraded your pledge past from 60 to 71 all by itself. (just curious which engine got you those bit levels.)

Yes, for LLTF assignments any "pledges" below 71 are bumped up to 71.

[flashjh]

I haven't fetched any yet because I super-fetched before the impending BIG news. I'll test it tonight after work.

[swl551]

Originally Posted by chalsall

Yes, for LLTF assignments any "pledges" below 71 are bumped up to 71.

Thank you for that information!.

[kladner]

Originally Posted by swl551

Can you look in the web_logs directory for GPU72FETCHxxx.html to see if the response contained "Sorry... No assignments available which match your criteria."

If you see those then it was a good test of the "Failback" feature. If you don't see that then GPU72 auto-upgraded your pledge past from 60 to 71 all by itself. (just curious which engine got you those bit levels.)

Thanks!

Scott

I did not see that string. I attached the log files so you can look them over.

[swl551]

U must agree to try breaking it, not just letting it run.