In the past a project had tasks that ran to 99% in minutes, before stopping there for many multiple tens of hours before it would go to 100%. 1 second can take hours and hours. On CPDN probably weeks.

The percentage and time are estimates. BOINC doesn't use them for calculating how long a task still takes. It will purely use the estimated floating operations per second count, combined with your benchmarks for CPU or GFLOP count for the GPU, the project's resource share vs the others and the DCF or REC (depending on project) to calculate how long tasks take by approximation. It does not use a clock. It won't know a task is still at 90 minutes before completion. It doesn't care about the clock.

All it cares about is if the task gets done before the deadline. And how it does that is damn difficult enough already, especially when combining 30+ projects with different resource shares, with different applications, with different runtimes, with different science, with different deadlines. It's a miracle BOINC manages to get most all the work done by the deadline.

---

BOINC can't predict the future, so if the computer's switched off unexpectedly, how do you want BOINC to know that?

No, but it could actually honor FIFO (First In First Out) and run tasks to completion once they've started, which is the way most people would expect it to work and rightfully so. Doing those two things would solve this for most cases.

I saw this exact scenario many times over the years, it's pretty frustrating to see BOINC letting work sit that you know it can't complete before the deadline, because it's running something else that has a later deadline! It's why I usually run a very low cache, while BOINC still runs things out of order sometimes at least it will have time to get everything returned in time.

Maybe true for most cases. If one of the projects has tasks lasting several weeks as CPDN does at least on slower computers, FIFO would then stop shorter tasks with much shorter deadlines ever running.

The way I see it, whatever system is used, it isn't going to please all of the people all of the time. Personally, I am happy the way it is

I agree, except I would say that projects with extreme deadlines like that should be run by themselves. Work that takes weeks is an outlier and should be handled accordingly. To me, that's more of a project problem than a BOINC problem since most work takes a few hours at most. You should expect problems if you're asking BOINC to do handle project work schedules that are out of the norm, and weeks-long work is definitely that.

That doesn't even apply to the situation being discussed. If the task really sat around for two weeks there was more than enough time to get it processed. Like I said, I've seen this sort of thing for years, I doubt it's going to get fixed. I've found my own way to cope so it's no longer a major problem for me, just an annoyance.

---

Team USA forum
Follow us on Twitter
Help us #crunchforcures!

But there you go again, you call for an unpredictable situation and want BOINC to handle that. You even call it unpredictable. How do you want BOINC to react to unpredictable situations when you yourself can't even do that? Although, there's that solution, ignore BOINC its scheduler and from now on decide per hour, per minute which task should run when, by suspending work/projects. But no, that's not something you want to do either.

So why not just let BOINC handle it as long as it brings everything home by the deadline, even if you feel it's cringe worthy, even if it pauses tasks at 1 second, even if it does things completely different than you would've done them?

And else, go to https://boinc.berkeley.edu/trac/wiki/SourceCodeGit, get the source code, start hacking at it, start adding that stuff that you want, compile it and run it. Only by going into the code will you learn that things aren't so black and white, so easily done as you demand them to be.

---

I would think all of us on here monitor what it's doing. But what proportion of Boinc users are not computer-savvy at all and just install it and leave it forever to run by itself. They probably have the (in my opinion wrong) defaults of stopping work whenever the computer is in use. The user probably turns it off at night or whenever they're not using it, they probably have it go to sleep after half an hour, very unpredictable. Boinc needs to handle this. And it should default to doing way more work, asking the user on install if they want to stop the computer from sleeping, run it during use, etc.

BOINC does actually track its own availability, quite closely.

This is my daily driver:

<time_stats>
    <on_frac>0.999871</on_frac>
    <connected_frac>0.999992</connected_frac>
    <cpu_and_network_available_frac>0.999987</cpu_and_network_available_frac>
    <active_frac>0.999994</active_frac>
    <gpu_active_frac>0.999994</gpu_active_frac>
    <client_start_time>1586108916.836021</client_start_time>
    <total_start_time>1452717932.503635</total_start_time>
    <total_duration>134204793.748473</total_duration>
    <total_active_duration>134203482.360486</total_active_duration>
    <total_gpu_active_duration>134203482.360486</total_gpu_active_duration>
    <previous_uptime>864154.903479</previous_uptime>
    <last_update>1586973069.731384</last_update>
</time_stats>

total_active_duration is about four and a quarter years - sounds about right, since I last replaced it. Many of the work fetch requests are scaled according to the availability fraction. The one thing BOINC can't measure is your future holiday plans (and at the moment, I can't predict my own, either).