(archive)MISFIT

[flashjh]

Originally Posted by swl551

FlashJH,
Please test 2.3.0 beta 4 with these changes.

No showing of non zero error codes at all. Only show if fatal error calling external appliation. Results and Errors can be emailed. See new configuration.

http://mersenneforum.org/misfit/

I'll get it tested. Thanks!

[LaurV]

Originally Posted by Dubslow

Well, the point of GPU272 was to distribute lower-than-accessible-from-PrimeNet expos for TF by quick workers. Auto-assignment was never the goal. I'd thus argue that even with autofetch-from-GIMPS, it would still be a good thing to mix in some GPU272 exponents in there.

Of course, is MISFIT could auto fetch from GPU272, that would be supremely awesome...

No. That came later, with the spiders. The initial goal was to get TF assignments to 67-68 bits from PrimeNet and hold them (as different type of assignment) until the newer, faster GPUs, would TF them to 72 bits, taking the same time (as they were 10 times faster) as P95 would need to TF them to 68 or so, therefore eliminating part of the expos, and saving a lot of precious LL/DC time.

++1 for fetching expos from GPU272 part.

[Dubslow]

Originally Posted by LaurV

No. That came later, with the spiders. The initial goal was to get TF assignments to 67-68 bits from PrimeNet and hold them (as different type of assignment) until the newer, faster GPUs, would TF them to 72 bits, taking the same time (as they were 10 times faster) as P95 would need to TF them to 68 or so, therefore eliminating part of the expos, and saving a lot of precious LL/DC time.

And the reason this needed to be done is because PrimeNet's TF reservation system handed out expos way beyond the wavefront. The spiders were the whole point of GPU272.

[swl551]

Pretty cool Ah?

If you want this please file a petition with Chalsall. I'll even release the full source code (c#) for this utility.

[chalsall]

Originally Posted by swl551

Pretty cool Ah?

If you want this please file a petition with Chalsall. I'll even release the full source code (c#) for this utility.

Cool!

I have 95% complete a Primenet like API for fetching work (and reporting estimated completion) which I need get back to Real Soon Now. (Life has gotten in the way.) But this is a worthwhile stop-gap menthodology until then. Thanks for doing this.

[kracker]

Originally Posted by swl551

Pretty cool Ah?

If you want this please file a petition with Chalsall. I'll even release the full source code (c#) for this utility.

Looks awesome!!

[Dubslow]

Originally Posted by chalsall

Cool!

I have 95% complete a Primenet like API for fetching work (and reporting estimated completion) which I need get back to Real Soon Now. (Life has gotten in the way.) But this is a worthwhile stop-gap menthodology until then. Thanks for doing this.

Well, his PrimeNet autofetch also just uses the standard-"public"-frontend-fancy-formatted-pages of PrimeNet, so he doesn't actually use the API (yet).



Also, if I may suggest, why not make all the source code available? There's no reason not to.

[swl551]

VERSION 2.3.0
1. version 2.3.0 the focus is on preventing IO with GIMPS during peak times. I have defined peak time (in my code) as 2 mins before the hour to 10 mins after the hour (UTC).

During this restricted window anything done via button clicks will get a dialog error indicating cannot perform task during peak time.

For automation it is more complicated.
Schedule exports/uploads can no longer be scheduled during that time frame. Existing schedule will be challenged during start-up and you'd have to reschedule.

Time interval based exports/uploads will auto delay to past the restricted window if the event occurs within the restricted window.. this will cause the timer to drift past the window and future uploads won't fall in the window at all.

GIOM retries (if GIMPS is down) will also auto delay to past the restricted window if the event occurs within the restricted window. So if you have a schedule upload at 3:30 and it fails due to some primenet problem it retries every 30 mins. this puts the next retry right at peak time (4:00). In this case GIOM will delay that retry to after peak time.

In all automation scenarios the delay past peak time is randomized between 0 and 5 minutes. This delay is to prevent the thousands of MISFIT instances from uploading results at the same time after the peak window has passed.


2. Ability to stage work in bulk and have it drained only when GHZDaysToDo drops below threshold. In addition the number of factor rows to assign out in one event can be controlled. In the process thread AutoAssignWork occurs before AutoBalanceWork so balancing of newly assigned work can occur in harmony with assigning work if you have AutoBalanceWork turned on. The last feature is the ability to execute a custom program prior to assigning of work. The call to the custom program is a blocking call an the exit code is retrieved. If the custom program fails to start an exception is thrown and the AutoAssignWork will *not* complete. The return code can be emailed to you to help monitor any issues when you are away from your computer.

3. Ability to automatically fetch work from GIMPS. On an hourly basis MISFIT will check the number of rows left in MISFITworkToDo.txt and if below threshold will fetch work directly from GIMPS.


4. Minor tweaks and fixes no one will ever notice.

See screenshot showing configuration for the new features.

Get from http://mersenneforum.org/misfit/

[sonjohan]

Originally Posted by swl551

I put 2 hours in there figuring it was an extremely long duration. Why is 2 hours max interval too short?

Post your follow up in the MISFIT forum instead of on this thread.

thx

I set it to the maximum because it creates (a tiny) overhead and I rarely check it.
I remember a post in the 'You might be addicted to GIMPS...' which addressed this tiny overhead.

I do however understand that it is needed to be low enough as the manual button 'update stats' does not trigger the auto-fetching process.

[swl551]

Originally Posted by sonjohan

I set it to the maximum because it creates (a tiny) overhead and I rarely check it.
I remember a post in the 'You might be addicted to GIMPS...' which addressed this tiny overhead.

I do however understand that it is needed to be low enough as the manual button 'update stats' does not trigger the auto-fetching process.

Remember the auto-fetching process only fetches if the workToDo needs to be refilled. File-IO times are sub second if the files is local to the PC.
I think you are worried about a problem that does not really exist. However there is a work-around. edit the MISFITconfig.txt manually and set the value higher. MISFIT config editor will overwrite that value if you use it later, but that is a work around.

Enjoy

Scott

[swl551]

Since everything has gone so well with the stand-alone GPU72 fetching tool I've decided to integrate the fetching code directly into MISFIT. The screen shots show the new WORK FETCH config screen where GPU72 is selected and where GIMPS is selected.


Feel free to comment.