The 6.05 results are perfectly fine, except now that the new release will be coming out which also has a client benchmarking feature, the result signature won't be the same, thus would not compare. Hence the draining prior to launch of 6.06. In short, the system is not able presently to tell version A from version B results and thus would start sending out far to many extra copies, so this is as said a bit messy i.e. quite manual control intense, but minimises duplication.

ciao

Is there a scheduled date when the new DDDT WU's will be "Generall Available" ?

Dear Sekerob,

if you read the 4th post (as I did) it appears sunday and again Wenesday, the old DDDT WU's are going to be migrated to the top of the queue for expidited processing, just to get them out of the system and completed.

What's not stated is when the new WU's will begin to fully populate the queue for general assignment.

Did I miss something?

here's how I have my bionic client parms set up...



basically, the connect about every 0.0001 days translates to about every 8 seconds.

Additional work Buffer 0.01 days says about 8 minutes before a work unit ends get another one.

This seems to be working out nicely so if there's something to get on the DDDT I get it otherwise I get what else needs to be run.

I am running some experiments to see what (if any) performance implications there are.. but so far I've not seen anything staggering.

What I would really like is the ability for each application to have parms where I can say globally; when the application gets within n units of time of completeing; signal that condition and request a new work unit. And within N units of time after the WU ends return it.

Having something like in the code would do a couple of things.

Keeps the WU's on the clients queue small (only gets them when another WU is about to finish

returns the WU's back failry quickly as they complete.

Keeps folks from loading up a machine to run days on end without reporting back the sataus.

But, that's what I would like to see.. and what do I know?

Barney's settings are fine long as he has the "alternate work" option on in the website profile. His client will only contact the server briefly before present job is finished. If there is no DDDT, he gets a warning and the client will again fetch an alternate job.... until such time that DDDT is generally available again.

If he does not have the alternate work option on the client will try and be told to back off for ever increasing periods. Gain/Loss: idle client. Now that is a waste of energy.

PS, this is the optimal setting to clean out any spare/repair work as it will be very sparse and help to reach the soonest launch of the new 6.06 version work.... remember there are literally thousands of devices connecting frequently. 6.05 work is recycled soon as an error is reported and a client / any client calls for a job.... no point in sitting there waiting for it. Almost the same as if waiting for a beta test job 1 day after launch.