I have been watching my Rosetta tasks. Even with the "12 hours requested" I am regularly getting what appear to be 8 hour tasks.

What I am not getting is the 2-3 hour tasks that seem to be the group average for the beta task on the server page.

Is there ANY chance a 2 or 3 hour task is more productive?

A lot of volunteers seem to be going with it.

---

Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel.....

Rosetta tasks usually run for a set amount of time, and execute several models during that time, with diffrernt rng seeds.
For some reason some workunit types run very fast, and produce lots of data .
For example my task reached model 16 in 10 minutes of cpu time.

I have been watching my Rosetta tasks. Even with the "12 hours requested" I am regularly getting what appear to be 8 hour tasks.

What I am not getting is the 2-3 hour tasks that seem to be the group average for the beta task on the server page.

Is there ANY chance a 2 or 3 hour task is more productive?

A lot of volunteers seem to be going with it.

3hr runtimes aren't chosen by volunteers. They're 'default' runtimes that are screwed up within the task by the researchers. It's a mistake (IMO but I'm convinced I'm right).
Default runtimes are <all> intended to be 8hrs. That's why Boinc is forced by Rosetta to show all unstarted tasks as 8hrs, even if other settings contradict that runtime.
The task runtimes screwed up by researchers only run 3hrs by mistake.
Those set to be a different time by the volunteer (eg you and me at 12hrs) run that time, but Boinc only realises 2/3rds or 3/4s through the task to adjust the remaining time - whether up to 12hrs or down to 3hrs.

<No chance> the shorter runtime is more productive.
I don't think <any> change to runtime improves credit/hr, except the start/stop overhead is less significant for longer tasks and shorter tasks waste the work that's provided to us, so we may run out of tasks sooner than expected.
<Never> run any less than 8hrs (intentionally).
If your runtime setting is "default" and you mean that to be 8hrs, better (currently) to set runtime explicitly to 8hrs, not 'default'

Credit is awarded for the number of "decoys" completed <within> each task within your chosen runtime.
The quicker your machine, the faster each decoy is completed, the more decoys you can complete within your runtime, the more credit you get. That's essentially it.

After each decoy, the average time per decoy is worked out. If you have sufficient runtime left to complete another decoy, you do so. If you don't, the task ends.
That's why tasks don't run exactly to your runtime. Sometimes a bit shorter, sometimes a bit longer.
It's also why the countdown on runtime never drops below 10mins remaining, but then suddenly ends.
The task doesn't ever know when the current decoy will complete until it does. Then sees there isn't time to do another, so it ends.

---