Many thanks Alessandra for the update

And at the same time , and on behalf from all of us here , congratulate you for being honored last year as "Woman Scientist of the Year" by the jury of the 9th Irene Joliot-Curie Prize from the French Department of Higher Education and Research.



Félicitations !!

BUT - that is the case when the project is operating normally, not when the output of work has been abruptly stopped.

BOINC hasn't yet stabilised on my new machine and I'm still micromanaging it. When the supply of HCMD2 work was turned off, it was turned OFF - there were no repair units being sent, No-replies or completion work - NONE.

I had a few tasks in my cache that I knew were going to be returned late. I noted in this very thread on August 2nd that the system had generated a repair unit but on arrival of the late unit, that repair had been marked with a status of "Other" and sent/received dates of 1/01/70 00:00:00. I'll presume that when the queue is re-started these units will be deleted.

The reason I did this was curiosity (I have to do it nowadays - the cat died a long time ago.) I knew that the work had been turned off because I'd received no more in the prior 7 days - and it had been documented in this forum. There was therefore no danger of the job being sent to another machine.

The point is that every unit that was returned after August 4th was returned late. Every last one. Regardless of the numbers involved, the chart indicates that the runtime on these units was significantly higher than the average before the switch was thrown. Unsurprisingly, this would be because the slower processors given the same mix of units would take longer to process them, and would likely hit the wall more often.

The issue is to get those slower processors to do useful work and not simply slow down the system as they are currently doing.



All very well for a live system. This is not a situation that has occurred on a live system. It is a situation that occurred when the system was turned off. No make-up copies have actually been sent, so those very late results are not redundant. They will be used.



I can't control the data published on the HCMD project status page. There doesn't seem to be any data from WCG about how much data has actually been delivered. Since the only data visible seems to show that data-delivery for batches 1785+ is incomplete, and that was being crunched what - two months or more ago - then there must still be incomplete work from that time outstanding.

It's probably not significant at this stage of the project, but extending the deadline would allow results from slower crunchers to be used where they are currently discarded and delaying the work. I'd suggest that the deadline for any project, not just HCMD2 should be a minimum of (maximum-expected-runtime + maximum-BOINC-cache-size-in-days.) Very difficult to estimate max-runtime I'd suppose - but matching the jobsize to the individual processor capacity available would aid significantly - and the 6/12-hour HCMD2 wall would set a limit, too.

Perhaps at the start of a project, the deadline could be let out significantly and then brought in as the project nears completion.

The downside would be that there would be more credit sitting in PV.

Mysteron347,
I suspect that these tasks returned after so many days have nothing to do with the speed of these machines.
Because even for the slowest machine the 6-hour limit will be reached in time if the machine is running an average one hour a day, whatever the speed of the processor.

Considering that it is currently Summer holiday time in many countries my guess would rather be that these tasks are coming back from machines which have been switched off one or two weeks for holidays and, probably to the surprise of their owners, they are allowed to finish the job and be granted credits normally when starting crunching again, simply because the time has been suspended for this project.

Typically the slower devices are the later returners, so when the normal mix in production gives 4.35 hours and the residuals in the field come in, you'll see exactly what was observed, a creep up, the difference being here that it would be capped at somewhere between 6 and 12 hours... the fewer results get returned, the more weight a long running result has on the averages and sure enough, for the 54 results that came in this morning the mean is 5.54 hours, more than an hour more than in full production, with actually a declining trend as the batches get lighter to process.

As for the 12 hours hard-cut, I see no reason why a slow device pair would not hit upon a task that would go the full stretch. All depends on the positions packed in a result and their difficulty. WCG does as yet not distribute tasks based on CPU power; as I mentioned in a post above, that's one of the long term goals. You'd have to visit posts by knreed for some elaboration.

--//--

CMD2_ 2052-2I85_ A.clustersOccur-2IGQ_ B.clustersOccur_ 0_ 12499_ 16476_ 1-- 640 Valid 7/22/11 13:01:05 7/23/11 13:00:31 2.67 35.3 / 35.5