I wanted to bring up something that’s been bugging me lately while running different projects. I just started a new task that showed a 2.5 hour estimate, but I hit 72% completion in literally 6 minutes.

While it’s cool that my PC is fast, I feel like these wildly inaccurate estimates are a massive issue for the growth of BOINC and distributed computing in general.

If a casual user installs this and sees a massive 5 or 10 hour estimate for a single task, there is a huge chance they’re just going to close the program and uninstall it. They think it’s going to melt their computer or take days to finish, when in reality, modern hardware is just way ahead of whatever "baseline" the project is using.

From what I’ve gathered, the software has to "learn" your speed over time using a correction factor, but that takes way too long to kick in. By the time the clock looks normal, a new person has already quit. It seems like a lot of these projects are using super outdated benchmarks from years ago, and it makes the work look 20x more daunting than it actually is.

It also messes with the scheduler—the client thinks your queue is full of hours of work when it’s actually only a few minutes, so your hardware ends up sitting idle because it won't request more tasks.

Does this bother anyone else? Does seeing a massive time estimate make you think twice about trying a new project or application?

I’m curious how many people we’ve lost because the "estimated time" made them think their computer couldn't handle the load. How do you guys explain this to people you're trying to get into the hobby?

Does this bother anyone else? Does seeing a massive time estimate make you think twice about trying a new project or application?

Short answer "No", but then I've been running BOINC-based projects ever since BOINC first emerged so know its problems and ways.
Longer, "No and Yes": "No" - see above; "Yes" - some projects are very bad at consistently declaring how many "FLOPS" tasks will take, thus make a mockery of any existing calibration guesstimate vs. reality.
p.s. I far prefer to see an over-estimate of duration rather than an under-estimate that some projects consistently do.

Well, a positive surprise when you complete tasks faster than estimated. Just some literally complete like 10 times quicker than estimated, while some do take as many days as the estimated time says.

It is just much more satisfying completing many smaller tasks faster than a few big ones now and then, for some people, might not be the purpose of folding, but just how it is.

My first question would be to ask whether you’ve run the benchmarks, that is where I’ve seen highly overestimated times given.

Running the benchmarks works sometimes, but can actually be detrimental in the short term.

BOINC has a somewhat confusing set of rules when it comes to working out (guessing) the expected run time for what is perceived to be a "new" application which can result in some rather random guesstimates.....

The guestimates are based, broadly, on two things - the FLOPS count sent out by the project, and the apparent performance of your computer.
Obviously if both the FLOPS estimate and the performance estimate are about right the guestimate will be pretty close to reality, but if either is "wrong" some very substantial differences can be seen, then you get a task that is an outlier, or has an error and it either finishes much faster than expected, or takes far longer, in either case there's not a lot that we can do about these.

As for wanting lots of short tasks, or lots of long tasks. Choice of project can help - for example CPDN is great if you want long tasks, consistently running for days not minutes.
However a great many projects deliver a mix of tasks, just now MilkyWay is sending out a mix of short task (a few minutes) and longer tasks (an hour or two); meanwhile WCG MCM tasks are generally taking about an hour - both projects providing fairly accurate estimates.

If a casual user installs this and sees a massive 5 or 10 hour estimate for a single task, there is a huge chance they’re just going to close the program and uninstall it. They think it’s going to melt their computer or take days to finish, when in reality, modern hardware is just way ahead of whatever "baseline" the project is using.

Why on earth would they think it would take days to finish, when the Estimate is 5 or 10 hours???
And why on earth would they think a long running Task is going to impact their system thermally more than a short running one?

It also messes with the scheduler—the client thinks your queue is full of hours of work when it’s actually only a few minutes, so your hardware ends up sitting idle because it won't request more tasks.

As the Task is done, the Remaining (estimated) time to completion will quickly decrease, and as Tasks are returned, the cache will have less Tasks there, so it will refill as work is returned. It will not end up sitting idle.
Having ridiculous cache settings (eg 4 days + 10 additional days), will impact on how low the cache falls before more work is requested, but it won't run out and sit idle because of the excessively large initial Remaining (estimated) time.

Even with the Remaining (estimated) time no longer updating (apparently depending on the project's Credit mechanism) after being broken with the release for BOINC v 8.2.4, it won't run out of work and sit idle due to the incorrect initial estimate.


However, the impact on the Scheduler & cache is why the broken updating of the Remaining (estimated) time as work is returned needs to be fixed.


And the accuracy of the initial estimate is entirely up to the project- as long as the benchmarks have been run and the project's estimated FLOPs for the Task roughly close to the actual value, then the initial Remaining (estimated) time will be reasonably close to the actual time.
And the reason to wait for 10 Valid results to be returned before updating the Remaining (estimated) time is to help avoid wild variations in that value, and ending up with more work than can be done before the deadline due to wildly low Remaining (estimated) times.

---

Grant
Darwin NT.

And the accuracy of the initial estimate is entirely up to the project- as long as the benchmarks have been run and the project's estimated FLOPs for the Task roughly close to the actual value, then the initial Remaining (estimated) time will be reasonably close to the actual time.
And the reason to wait for 10 Valid results to be returned before updating the Remaining (estimated) time is to help avoid wild variations in that value, and ending up with more work than can be done before the deadline due to wildly low Remaining (estimated) times.

The waiting for ten tasks to be returned means that over at CPDN I am unlikely to ever get an accurate estimate on some batches. After a task lasting three to five days finishes, I am unlikely to get more than one from that batch, and often the next batch is a new task type as the code is tweaked.

This is not a complaint, rather an observation. Changing the rules to cope with an edge case would not make much sense, and doesn't really bother me that much.