During the outage recovery, I noticed a problem related to 'Redundant result - Cancelled by server'. This is a heads-up in case anyone - particularly those with fast processors and large caches - hits the same thing.

When the servers came back up, my fast box was allocated a lot of WUs quite quickly, but struggled to download them through the congestion. However, other people obviously did download them, because some became redundant before I'd even managed to complete the download.

Once I'd reported the (aborted) result, my trusty BoincView was showing green across the board, but no new work was being fetched. I discovered that the machine was still re-trying five downloads, but getting 'file not found' (obviously, because the WU had been assimilated and the datapak deleted from the server). I just aborted the meaningless downloads, and work fetch started back up as normal.

BOINC needs to check for, and cancel, any associated transfers when doing a server-mandated abort. I'll log a Trac report. Edit - trac 366.

Richard, it has been around since I joined. It is not just a problem with 5.10.13. It just appears that more people are experiencing it due to reduced quorom of results needed to validate a unit.

. . . I discovered that the machine was still re-trying five downloads, but getting 'file not found' (obviously, because the WU had been assimilated and the datapak deleted from the server). I just aborted the meaningless downloads, and work fetch started back up as normal. . . .

I noticed the same thing on 3 machines. One actually ran out of work in one of two threads.
Don't know if this has happened before, but it is the first time I've seen that on any of my computers.
I am running BOINC v5.10.13.

Nice catch. I hope they find the little bug and stomp it. Ah yes, programs are never finished, always a work in progress, eh?

---

"Time is simply the mechanism that keeps everything from happening all at once."