bfmorse

I looked at the first one and it seems that you received your copy as soon as the other copy had passed its due date and then it was returned soon after. Any crunching by you would have been wasted as they already had 2 valid results so yours was aborted to save your crunching from being wasted.

Mike

Well, I suppose I should put this in perspective...

I had 18 server aborted work units (WU's) on July 9th - which, to me, is frustrating.

When I started processing them, I have no idea that the original volunteers run an apparent Queue of at least six days. (A reasonable queue with UNLIMITED as the cap on WU's could do that too.) That six day delay in returning their WU causes an automatic WU release for, in these cases, me.

But I should put my Aborted Work Units in perspective:
I looked at "My Activity over time" on my "OVERVIEW" page, the Mapping Cancer Markers' graph shows that I typically successfully return and get credit for at least 1,500 Results each day. Other projects' WU's I successfully return are not included in those numbers.

All in all, my wish is that queues be monitored and not run so long as to cause a new WU to be released for someone else to process. Thereby making unnecessary work whether they are aborted or not.

I am in agreement with link64 as to reasons for late returns happening, though I can think of other "innocent" reasons as well...

As for cutting down the number of retries that end up being unnecessary, in olden days (WCG/IBM) projects had a 24 hour grace period associated with them. The client didn't know about this (seeing only the deadline time) but the server would allow that grace period for No Reply cases before sending a retry. This made it far more likely that overdue results would end up aborted by the client (known as "Not started by deadline"[*1]) so the proportion of Server Aborted retries for tasks from applications with short run times (most WCG projects!) was a lot lower then...

However, the grace period was taken off as part of clearing up the outstanding work before the IBM->Krembil migration -- it doesn't seem to have been restored. The ratio of delayed tasks that end up No Reply is a lot higher now. Some convert to Error status fairly quickly (as the client aborts them!) and some don't return before the WU is assimilated, but some of the rest will return late and validate -- some of those will cause Server Aborts but others will result in a WU having three (or more!) validated results!

Personally, I'd like to seem them bring back the grace period and reduce the deadlines by a day at the same time -- nowadays I can't see any reason for a 6 day deadline on something like ARP1[*2], let alone MCM1 or [presumably] MAM1 when it finally launches, and shortening the deadline might help with the occasional problems with either backed-up validations or issuing of [needed?] retries.

Cheers - Al.

*1 -- WCG don't give that as a status, but it is fairly easy to recognise which Error returns are actually "Not started by deadline"

*2 -- I would suggest that anyone who needs more than 72 to 96 wall-clock hours (from collection to completion), let alone 144, to run an ARP1 task probably shouldn't be running ARP1... :-)

Again, I mostly agree with that, but as this is supposed to be a WCG Project Status thread I will back out now, rather than discussing issues for multi-project users and the lack of generally available, easy to use, flow management for many BOINC projects.

However, I must note that I see a far higher percentage of WUs with missed deadline wingmen at Einstein (which also has long deadlines for GPU work, by the way!) than at WCG. And when I had Milkyway as a main project rather than a reserve I used to see higher percentages of WUs with missed deadlines there as well...

While this has been an interesting discussion, I don't actually see WCG changing anything about task deadlines (or re-introducing grace periods). So ARP1 will continue to clear work more slowly than it could, and some users will continue to be irritated by Server Aborted tasks...

Cheers - Al.

P.S. I run five "standard" systems, all of them deliberately power-limited and configured for custom workloads with fast turnaround; I turn in between 650 and 730 MCM1 tasks a day depending on how many ARP1 tasks my systems actually get! I do realize that not everyone can/will put in the effort to set systems up like that... :-)

I haven't seen any ARP WUs in a while. MCM has been flowing well.

We are getting close to the end of generation 148. I hope they will start 149 over the weekend.