(archive)MISFIT

[TObject]

I got the following error after running MISFIT for 13 days non-stop:
2/10/2013 3:47:17 PM Error during ProcessAutoGIMPSFetch:Index was outside the bounds of the array.

Edit: MISFIT version number 2.4b12

[swl551]

Originally Posted by TObject

I got the following error after running MISFIT for 13 days non-stop:
2/10/2013 3:47:17 PM Error during ProcessAutoGIMPSFetch:Index was outside the bounds of the array.

Edit: MISFIT version number 2.4b12

Look in WEB_LOGS for your GPU72 fetching HTML file. You will see it returned NO results.

You are on a BETA version and I believe I fixed that error so it says "No results were available, check log file"

[swl551]

When the override is selected (see screenshot) MISFIT will disable all input boxes to signify they won't be honored, and will perform an OPTION [0] POST with a modified WebAgent string.

Normally MISFIT sends
web.UserAgent = "MISFIT-TF-FETCHER";

in override mode it will send

web.UserAgent = "MISFIT-TF-FETCHER-U-DECIDE";

This will allow GPU72 to identify MISFIT traffic in general, and when to actually make all the assignment decisions for the caller.

This implementation is a close as I can come to manipulating the system as if there was an OPTION[5].

Additionally this implementation of (xxxx-U-DECIDE) could be used by other utilities not in the MISFIT family and of course the stand-alone work fetcher could have this implementation as part of its configuration file.

No code has been written yet, so now is the time to hammer out the final implementation details.

[flashjh]

Like it.

In your screen shot you have it set to 1st time tests, but when the option is clicked it will default to WMS, right?

[swl551]

Originally Posted by flashjh

Like it.

In your screen shot you have it set to 1st time tests, but when the option is clicked it will default to WMS, right?

"First time tests" and "Double Check Test" resolve to different URLs. The lower box "Preference" selection is what is overridden regardless of what URL is called. This means GPU72 has to put the web.UserAgent check on both pages for consistency. ( I think Chalsall stated both pages would have the web.UserAgent check)

[swl551]

Originally Posted by swl551

"First time tests" and "Double Check Test" resolve to different URLs. The lower box "Preference" selection is what is overridden regardless of what URL is called. This means GPU72 has to put the web.UserAgent check on both pages for consistency. ( I think Chalsall stated both pages would have the web.UserAgent check)

Example screenshot show WMS chosen where it would function exactly as it has in the past because. In this configuration MISFIT would not include the -UDECIDE suffix in the web.UserAgent string so GPU72 would honor the fetch parameters exactly as supplied.

In other words WMS is not the trigger for GPU72 to override. It is all based on the -UDECIDE suffix in the web.UserAgent string. Or the page just accept an OPTION[5] as the trigger for making all decisions.

I hope that clears up the desired implementation of the override.

[chalsall]

Originally Posted by swl551

Example screenshot show WMS chosen where it would function exactly as it has in the past because. In this configuration MISFIT would not include the -UDECIDE suffix in the web.UserAgent string so GPU72 would honor the fetch parameters exactly as supplied.

This seems like a reasonable solution space.

So everyone knows, WMS is usually the same as Lowest Exponent. But sometimes it makes decisions based on the pledge level. For example, in DCTF right now if someone pledges to 71, the Low range is moved up to 33M. However, if any other Option is set the ranges are not modified.

I will wait for this to be released and deployed, and then I'll revert my WMS modification and implement the override based on the "UDECIDE" UA.

Actually, an extension to the idea... When the "Let GPU72 decide" option is enabled, leave the Pledge field "unghosted", but change it to be something like "Maximum Pledge". Then GPU72 will never assign work past this level, but has the option of lowering it.

My thinking is we may be able to go to 74 (at least, occasionally) in a month or so, but some may not want to do that work. So, for example, if someone is only wanting to go to a maximum of 73, that's what they'd get even if the system as a whole wants to go to 74.

Thanks Scott et al.

[chalsall]

Originally Posted by flashjh

Since the fetcher and the distribution are based on GHzDays of work now, can the WMS form take a field for how many GHzDays the requester wants instead of how many?

OK, this has now been implemented on the LLTF form (including the preview). Adding to the DCTF form shortly. Note that you are still constrained by the maximum number of assignments allowed per request (as given on the form; 100 for most people, 1,000 for a few).

Also please note that the number of assignments are rounded up -- as in if you only ask for, as an example, 10 GHzDays of WMS LLTF you'll be assigned one candidate worth ~27 GHz Days of work.

Scott, the field is named (predictably) "GHzDays".

Please let me know if anyone sees any regressions; AKA SPEs.

[swl551]

Originally Posted by chalsall

OK, this has now been implemented on the LLTF form (including the preview). Adding to the DCTF form shortly. Note that you are still constrained by the maximum number of assignments allowed per request (as given on the form; 100 for most people, 1,000 for a few).

Also please note that the number of assignments are rounded up -- as in if you only ask for, as an example, 10 GHzDays of WMS LLTF you'll be assigned one candidate worth ~27 GHz Days of work.

Scott, the field is named (predictably) "GHzDays".

Please let me know if anyone sees any regressions; AKA SPEs.

Just to confirm I would never send both "number" and "ghzDays" where each had a value > 0. Only one of them can be > 0 and that is the way the page will determine the total count of assignments to return. If both are > 0 the page might reply with something like {ambiguous count request} (however that is just to protect against bugs in my code).

[chalsall]

Originally Posted by swl551

Just to confirm I would never send both "number" and "ghzDays" where each had a value > 0. Only one of them can be > 0 and that is the way the page will determine the total count of assignments to return. If both are > 0 the page might reply with something like {ambiguous count request} (however that is just to protect against bugs in my code).

Nope... The way I've coded it is if GHzDays is >0, then it overrides Number.

And, this has now been implemented on DCTF as well.

Edit: And I believe (haven't tested) that the case for the form fields matter.

[swl551]

Originally Posted by chalsall

Nope... The way I've coded it is if GHzDays is >0, then it overrides Number.

And, this has now been implemented on DCTF as well.

Got it. Now I know how to unit test.

Thanks!