Hi Jeff,

Welcome to WCG! The status that you mentioned is quite normal and it makes sense if you consider you could be the other wingman waiting on somebody for more than 10 days to return a result. If you don't have internet access all the time or if you don't like to keep your machine on 24/7, my suggestion would be to find a balance between your WU buffer (smaller would probably be better) and the intervals when you actually have internet connection. I would also suggest that you pick the projects with less computing time per WU and definitely steer clear of CEP2, especially if you don't crunch 24/7!

So those are my suggestions from my non-expert point of view. I hope this helps.

Cheers!

I have crunched few other projects, but WCG is the most generous of all. I don't know how it is if you send WU after due time (I returned all my work within it), but WCG is the only one awarding crunchers with (some) credits for Invalid result.

Cheers

If 10 days is not enough time with a minimum buffer, which means only running tasks are on the host, no tasks ready to start [except the few minutes prior to finishing previous work], I don't know what. There is a -must- in getting work back in a reasonable time as else the storage of unarchived results grows out of hand which makes the whole system go slow for everyone.

At the present some core development is underway to allow sizing assignments based on device power, and possibly also based on hours per day average, but that is a medium term future implementation. A possible effect of that is, that results on average will return faster, meaning if your device is on only 3-4 hours a day, I'd still be able to return that result within a few day, well within the current general deadline of 10 days [non-repair].

Of course, if a computer is on only few hours a day, a setting of "Do work after idle for xx minutes" is pointless. In effect no progress will then be made other than the small intervals that a user takes a break from operating the computer. In that situation a Run Always is recommended... most don't ever notice BOINC is on and if they do, they can specify the specific programs when requiring BOINC to pause.

.....two MONTHS for a WU at SETI! They must have altered a lot since I was there, wow!

Great for SETI they can afford that [They can't is my observation for proper operation, given their weekly multi-day outages]. Over here at WCG the results are part of inter-related batches, experiments, of life-science... if one is missing, the data can't be archived, with the resultant performance impact. The Result Status page bares witness. WCG can only allow a few days of production to remain on-line.

As I explained, there's work ongoing for dynamic sizing according to various device criteria. As you put it, "The Grid get's spare time" and that is the intend. It is though that if the [default] settings are that spare cycles are not allowed to be used during user input, which varies from 0-100% on usually 1 CPU thread, the other non-user utilized threads also waste the spare time, not used by BOINC. The preference of "While computer is in use", is then recommended to be ticked, and if your computer is e.g. a quad core processor, "On multiprocessor systems, use at most 75%", a percent so that 1 thread remains at your disposal, but the others are having 100% of the spare cycles donated to grid computing. Whatever settings that optimize the crunching without you being obstructed.

Maybe, long on many a wish-list has been, a % of processor while in use and when idle, just as there is one since long for memory use by BOINC. Never heard the argument why that could not be implemented by Berkeley. On the said quad, that would mean in the example 100% use when idle and 75% when in use. Optimized utilization according users wishes. With LAIM [Leave application in memory while suspended], that in effect never unloads the task, so it can resume whenever that 25% is not used by member, without a second of computing loss.