Yup; much to my chagrin I missed that one in my scan of that thread because it was in sam6861's forensic analysis post rather than as a failure report per se :-( -- as he'd just reported 33395 I probably misread the forensic one to be the same...
I'd assumed that, so I've been looking at wingmen for all my recent 32-bit jobs (rather than just the unstuck tasks...) and most of the time there's nothing obvious about the O/S in use - typically a 64-bit system... Sometimes, however, it's obvious what's going on as there's a 32-bit kernel in play, albeit not that often!

However, I suspect that some of those systems actually have a 32-bit client without the configuration adjustment for 64-bit tasks; that would go a long way to explaining it.

Cheers - Al.

Thank you, Kevin.

If you are reducing the deadline for extreme case, are you reducing the definition of reliable to narrow the machines eligible?

As there are only 3 units restarting at 000, could you not have a short list of the fastest machines to receive them? That way they would close up faster.

There are currently only 261 days to my calculated completion date and those 3 units will need to be run through 183 generations, which means they will need to turn around every 1.43 days (34 hours) to meet that date.

I would suggest that only machines regularly returning units within 18 hours should be eligible for those 3 units. The other extremes could continue as now.

That would rule me out, but help the project!

Mike

No - while I would like to do this, the reliable mechanism in the BOINC code applies to everything on World Community Grid and making this change would cause there to be too many jobs needing a reliable host which would in turn gum up the works.



I agree that would be nice, but no such mechanism exists in BOINC.



That's in line with my estimate. Currently the extremes average 38 hours while the median is 29 hours ( as an aside 62% of the workunits finish within 34 hrs). The difference between the average and the median is the hard luck cases that stretch out to 100+ hours. As long as these three jobs have a minimal number of hard luck cases, then they should be able to be close by the end of project. In the absence of better tools to target these at specific hosts, the next best tool is to make sure that the worst case time to finish a single generation isn't too bad. That way if the average is pushed closer to the median (and in particular, below 34 hours), then they should be able to catch up. Once most of the extreme workunits become accelerated we can look at tightening the report deadline for those three further to be only slightly longer than the reliable threshold.

We have also discussed this with the Delft team and they know that these 3 might take another 3-4 weeks to finish after the bulk are done.

Kevin

Thank you for your replies. I note that 7 divided by 2 is 3.5 and 3.5 divided by 2 is 1.75. Is the 2.75 arrived at by adding the 1.75 and the 1 leeway allowed part way through the project?

Did you find the error on ,,,,stats/state?

Cheers

Mike

I have ARP1_0000026_123. I don't recall seeing a number as low as 0000026 in a long time. It has a 5 day deadline.
Cheers