Flagging up task errors for crunchers

[mo.v]

Most projects have a small proportion of computers attached which crash large numbers of tasks. Even though these computers automatically have their daily quota reduced, many tasks can still be wasted and there can be an unfortunate waste of unproductive processing cycles and electricity. This situation can sometimes continue for months or years.

I believe that most Boinc users, even those who set and forget, probably look into their Boinc manager occasionally. Even if the computer repeatedly crashes tasks, a glance by an uninformed user may give the impression that all is well. There may be a crunching task from the problem project in the Task tab and the Messages tab will say that computation for all tasks 'finished'. The word finished gives the impression of success.

When a task terminates prematurely would it be possible to indicate this in red in the Boinc manager messages? This would inform more people of a problem.

The inclusion of the task's exit status would give the impression that someone may know about it and repeated failures need not induce fatalism or despair.

The addition of for example: 'Visit the project forum for advice' would encourage more people to take action.

Only a small proportion of crunchers would ever see their Messages tab full of red entries.

I think this approach would help increase the proportion of successful processing.

[Richard Haselgrove]

Currently, the commonest log message for failed tasks is one or more lines of "Output file absent", which most non-specialist users seem to interpret as a project error, not a science app failure which merits user attention.

I agree that having an additional log entry, high priority, to flag a non-zero status outcome as worthy of attention, would be beneficial to project science in the long term.

[mo.v]

John McLeod? has suggested that a dialogue box that pops up from the Boinc icon, like the one indicating that Boinc needs an internet connection, would provide a more prominent indication for users.

Boinc is supposed to be settable and forgettable. The set-and-forget modus operandi makes it imperative that if problems arise Boinc should whenever possible proactively communicate with the user.