There's nothing to discuss; It has been used fully.

The problem (or bottleneck - the correct word) is on the researchers side. That is because it needs HUMAN INTERVENTION between different types (A,B,C). If only the scientist (or humans per se) can process millions of instructions per second then we wont be discussing this.



Now, I think the discussions should be, how can we eliminate/minimize that human intervention?

Jean, only the first part was directed at your last sentence, Not o/t ignorance, this time. Just suggesting the existence of a present inherent WCG "prejudice" - for another project(s) and WRT power; Linux users experience faster performances for most projects, can presently run all the WCG project, and were able to contribute during a past Beta round.

X-Files 27 explained the DDDT2 intermittency, time consuming human intervention is presently required between runs, and suggested this be reduced. I don'€™t think we crunchers can do much to automate the task analysis and creation procedure, but perhaps the scientists could, though I guess this is new ground for them and not something they have down to production line optimization. Of course we could return the tasks more quickly (by keeping a low task cache), and the technicians/scientist might be able to further refine task allocation. There has been excellent progress with this recently for the Beta tasks. So that might be a better template for the allocation of DDDT2 tasks (if it is not already employed) than the standard Active projects; with their 10day due time. If this was 5days, then it would expedite the project by 5days during every run, and move us closer to the expected longer runs (times when tasks become more available), where the allocation could be relaxed. So far there have been 5 sets of task releases, so we could have been 25days further on, and 25days closer to continuous task releases for more sustained time periods.

Hi Jean,

Obviously, the techs will be able to answer this categorically, but I'm not sure that the Type A's are distributed on a 1/core basis. I know it's been discussed many-a-time, but I don't recall seeing a comment that this has been implemented. Of course, it could well have been (and may still be) implemented, just don't recall seeing it... In fact, although my memory could well be playing tricks, on the last distibution of Type A's, I'm sure I got more WU's than just the 4 cores I've got available with this machine.

Thank you for this information. My difficulty in the last round of B's was that the estimated times-to-completion were too short, so my slow machine was given more WUs than it could complete by the deadline, even though my cache was set to only 2.5 days. I aborted 3 WUs so they could get back out there, and it finished the rest on time and without error.

I've taken DDDT2 off the list of projects for that machine, so it won't happen in the future. But this machine is a "reliable host," with enough memory, disk space, etc. per the system requirements for the project, so I didn't have reason to expect issues.

I think at this point, the Bs were running longer and causing more problems than the A's. Maybe both should be assigned one-per-core.

I love DDDT2, and am grateful for the chance to crunch it on my other machine, which charges through all kinds of DDDT2 WUs -- A's, B's, and C's.

You are right. I have corrected my previous post... and I am bumping my April 2 post in the CA forum.