The ETAs from R@H are only ever correct for me if I select 8 hours in user preferences. If someone selected something longer with a large cache (deadlines would prevent too many) then there is no way for them to complete.

A 1 day queue with 36 hour run time will cause the tasks to run past deadline as that the tasks will run over 4x their ETA.
For a single thread and 1 day queue you'll have 3x 8 hour ETA tasks but could run for 36 hours each. 108 hours is more than what can be completed with a 3 day deadline. That's only with a 1 day queue and BOINC could download more with a longer queue.

The ETAs from R@H are only ever correct for me if I select 8 hours in user preferences. If someone selected something longer with a large cache (deadlines would prevent too many) then there is no way for them to complete.

A 1 day queue with 36 hour run time will cause the tasks to run past deadline as that the tasks will run over 4x their ETA.
For a single thread and 1 day queue you'll have 3x 8 hour ETA tasks but could run for 36 hours each. 108 hours is more than what can be completed with a 3 day deadline. That's only with a 1 day queue and BOINC could download more with a longer queue.

I'm not going to get bogged down with why 8hr tasks could run 36hrs each - just to say I agree that if anyone chooses to exceed either the 8hr runtime default or the cache size default, the onus is <entirely> on the user to ensure that the combination of the 2 (and in the context of tasks coming from other projects) doesn't exceed the deadline.

It will always be a user problem to solve, never the project.

---

It's not the users fault a task with an 8 hour initial ETA can be set for much longer, from the project. But this project has zero development on the site or apps to ever address it.

It's not the users fault a task with an 8 hour initial ETA can be set for much longer, from the project. But this project has zero development on the site or apps to ever address it.

It is the users fault if they're not aware of what they are doing and what will be the result of those changes, and they go ahead and do it anyway.
And it is the projects fault for when they made the changes to the Initial estimated completion time years ago that they went for the simplest option of setting it to the default Target CPU time instead of the suggested option of the users own selected Target CPU time.

It is what it is and i don't see it ever changing.

---

Grant
Darwin NT

It's not the users fault a task with an 8 hour initial ETA can be set for much longer, from the project. But this project has zero development on the site or apps to ever address it.

What I wrote first time remains correct

"if anyone chooses to exceed either the 8hr runtime default or the cache size default, the onus is <entirely> on the user to ensure that the combination of the 2 (and in the context of tasks coming from other projects) doesn't exceed the deadline"

---