What are your thoughts on selecting a longer target runtime and crunching more "decoys" per tasks versus selecting a shorter runtime and thus generate fewer decoys per task, but going through more tasks?

I believe that the efficiency should be similar, both results-wise and credit-wise (now that the validator has been fixed), are there any reasons to go one way or the other?

I think longer run time would be better for the project. You’d hit the servers less often and they would need less work units.

The scientists needs the results quickly, they’ve mentioned in other threads they’ll look at results 48 hours after they’ve released batches of work, so running for 48 hours is too long. Extending the target run time to 12 hours might work.

---

BOINC blog

I think longer run time would be better for the project. You’d hit the servers less often and they would need less work units.

And you're doing more useful work for each WU sent out.
Personally i'm just going with the default time as set by the project. If a Task finishes early, it finishes early. If it needs to take longer, it does up to the Watchdog timer ending it if it doesn't end sooner.

---

Grant
Darwin NT

My take is that the project administration knows best, leave it at the default and let them set it.

Admin has requested that people leave the preference unset, which presently defaults to 8 hours. This allows them flexibility to modify that value in the future.

There will be no difference in credit per hour of runtime either way.

The preference is really there to better accommodate specific situations, such as machines that only run a portion of the day, or only have have internet access during specific hours of the day or days of the week. Actually, limited internet access is probably better accommodated with download cache size.

If your internet connection were metered, running longer WUs would tend to mean less network traffic.

---

Rosetta Moderator: Mod.Sense

What are your thoughts on selecting a longer target runtime and crunching more "decoys" per tasks versus selecting a shorter runtime and thus generate fewer decoys per task, but going through more tasks?

I believe that the efficiency should be similar, both results-wise and credit-wise (now that the validator has been fixed), are there any reasons to go one way or the other?

The only difference I can imagine is the overhead of completing one task and starting another, as compared with starting a new decoy. A matter of seconds per 8hrs, no more.

---

What are your thoughts on selecting a longer target runtime and crunching more "decoys" per tasks versus selecting a shorter runtime and thus generate fewer decoys per task, but going through more tasks?

I believe that the efficiency should be similar, both results-wise and credit-wise (now that the validator has been fixed), are there any reasons to go one way or the other?

I like BOTH actually, some people have brand new really fast cpu's and can easily accomodate anything you can throw at them, while other people have older hardware that would struggle with too large a workunit or one that takes too long to crunch. Also not every crunches 24/7 so longer units could end up repeating sections if the checkpoints aren't setup often enough, further reducing peoples willingness to crunch here. So I would setup two kinds of workunits, let's call them short and long for brevity, and let users choose which they want to run. As long as the credits work out similar enough for each type both should be crunched. IF you want the long ones to be crunched more you could even setup a 'bonus' amount of credits for returning a long unit within 12 hours for example. The Project GPUGrid did that and people seem to like it, they reduced their cache sizes and units are crunched very quickly and the data is used to setup the next batch of workunits, the bonus credits gives them a pretty quick turn around time.

I've had mine set for 12 hours, but may actually end up going back to the project default.
One bit of excitement in my life is the new Ryzen 5-3600. Put more money than I wanted into it - 64 GB ram - but should be worth it in the long term. I have 32 coming for the 1800x - not spending $500 plus on ram, at this point.

As long as the project gets results as quickly and efficiently as possible, I'm fine. I'm in it for the science, not the credits - and considering I have had two very good friends pass from Coronavirus the money spent is well worth it in my eyes.

I've had mine set for 12 hours, but may actually end up going back to the project default.
One bit of excitement in my life is the new Ryzen 5-3600. Put more money than I wanted into it - 64 GB ram - but should be worth it in the long term. I have 32 coming for the 1800x - not spending $500 plus on ram, at this point.

As long as the project gets results as quickly and efficiently as possible, I'm fine. I'm in it for the science, not the credits - and considering I have had two very good friends pass from Coronavirus the money spent is well worth it in my eyes.

Well, 64GB for the 3600 seems a bit excessive, unless you have some edge-case that eats up a lot of RAM. I have 16 GB of ram, I've devoted 8 threads to Rosetta and it runs absolutely fine.
Enjoy your 3600, its a beast of a mid-range CPU.

What are your thoughts on selecting a longer target runtime and crunching more "decoys" per tasks versus selecting a shorter runtime and thus generate fewer decoys per task, but going through more tasks?

I believe that the efficiency should be similar, both results-wise and credit-wise (now that the validator has been fixed), are there any reasons to go one way or the other?

So I would setup two kinds of workunits, let's call them short and long for brevity, and let users choose which they want to run.

You can set your own target run-time here, and you can have separate settings for "Home", "Work", "School", and "Default".