Done. Let us know if you are still seeing these issues.

Hmm, the issues seem to be back with the recent jgHE tasks.

jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_2pl3hn8x_924610_3_1: 234.18 credits.
https://boinc.bakerlab.org/rosetta/result.php?resultid=1163408026

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_a05.xml @jgHE_a05.flags -in:file:silent jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_2pl3hn8x.silent -in:file:silent_struct_type binary -silent_gz -mute all -write_failures false -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_2pl3hn8x.zip @jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_2pl3hn8x.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1107708
Starting watchdog...
Watchdog active.
======================================================
DONE ::    79 starting structures   128529 cpu seconds
This process generated     79 decoys from      79 attempts
======================================================
BOINC :: WS_max 9.62732e+08

BOINC :: Watchdog shutting down...
21:37:14 (7936): called boinc_finish(0)

</stderr_txt>
]]>

jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_7mr5at2k_924646_4_0: 238.41 credits
https://boinc.bakerlab.org/rosetta/result.php?resultid=1163267724

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_a05.xml @jgHE_a05.flags -in:file:silent jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_7mr5at2k.silent -in:file:silent_struct_type binary -silent_gz -mute all -write_failures false -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_7mr5at2k.zip @jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_7mr5at2k.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1188434
Starting watchdog...
Watchdog active.
======================================================
DONE ::    82 starting structures   128262 cpu seconds
This process generated     82 decoys from      82 attempts
======================================================
BOINC :: WS_max 1.00707e+09

BOINC :: Watchdog shutting down...
15:04:51 (15140): called boinc_finish(0)

</stderr_txt>
]]>

There seems to be something about the credit system and my main rig that loves the number 237 or so. When the issue comes up, it is ALWAYS around that number. Back when I set the target runtime to 24hours, that number also popped up quite often.

jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_3hx9qc6g_924652_3_0: 455.69 credits (quite low compared with what other people are getting per decoy, but a lot closer to normal)
https://boinc.bakerlab.org/rosetta/result.php?resultid=1162935116

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_b02.xml @jgHE_b02.flags -in:file:silent jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_3hx9qc6g.silent -in:file:silent_struct_type binary -silent_gz -mute all -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_3hx9qc6g.zip @jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_3hx9qc6g.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 2863513
Starting watchdog...
Watchdog active.
======================================================
DONE ::    89 starting structures   128306 cpu seconds
This process generated     89 decoys from      89 attempts
======================================================
BOINC :: WS_max 9.58149e+08

BOINC :: Watchdog shutting down...
11:41:29 (19364): called boinc_finish(0)

</stderr_txt>
]]>

Some examples from an i7-8700 non-K CPU, which is about as powerful as my 3600 in floating-point, if only a bit weaker.

jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_5po1az2j_924646_5_0 : 175.47 credits:
https://boinc.bakerlab.org/rosetta/result.php?resultid=1164235837

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_a05.xml @jgHE_a05.flags -in:file:silent jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_5po1az2j.silent -in:file:silent_struct_type binary -silent_gz -mute all -write_failures false -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_5po1az2j.zip @jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_5po1az2j.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1321363
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
======================================================
DONE ::    14 starting structures  28111.8 cpu seconds
This process generated     14 decoys from      14 attempts
======================================================
BOINC :: WS_max 7.97266e+08

BOINC :: Watchdog shutting down...
16:12:11 (10156): called boinc_finish(0)

</stderr_txt>
]]>

jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_3ax1pq8b_924661_4_0 : 276.01 credits
https://boinc.bakerlab.org/rosetta/result.php?resultid=1163864768

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_a05.xml @jgHE_a05.flags -in:file:silent jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_3ax1pq8b.silent -in:file:silent_struct_type binary -silent_gz -mute all -write_failures false -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_3ax1pq8b.zip @jgHE_a05_SAVE_ALL_OUT_IGNORE_THE_REST_3ax1pq8b.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 2770189
Starting watchdog...
Watchdog active.
======================================================
DONE ::    14 starting structures    27483 cpu seconds
This process generated     14 decoys from      14 attempts
======================================================
BOINC :: WS_max 1.01633e+09

BOINC :: Watchdog shutting down...
02:58:58 (12164): called boinc_finish(0)

</stderr_txt>
]]>

jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_0sa5mw6o_924669_5_0 : 184.16 credits
https://boinc.bakerlab.org/rosetta/result.php?resultid=1164320766

<core_client_version>7.16.5</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.15_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol jgHE_b02.xml @jgHE_b02.flags -in:file:silent jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_0sa5mw6o.silent -in:file:silent_struct_type binary -silent_gz -mute all -silent_read_through_errors true -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_0sa5mw6o.zip @jgHE_b02_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_0sa5mw6o.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 3938748
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
======================================================
DONE ::    17 starting structures  28424.1 cpu seconds
This process generated     17 decoys from      17 attempts
======================================================
BOINC :: WS_max 7.38607e+08

BOINC :: Watchdog shutting down...
18:25:44 (7988): called boinc_finish(0)

</stderr_txt>
]]>

Could the issue have something to do with my really long target runtime not playing nice with the windows Boinc client? If it was a benchmark issue, then I would see absurdly low claimed credits on other projects, which I don't. I've seen a 2700X user who has had a similar issue, with their credit jumping between the 200s and up to the 1500s for 24-hour tasks. They speculated it may be a cache bottleneck until they realised that limiting the number of tasks did not fix the issue.

cpu governors does a lot of frequency scaling running between low frequencies and max frequencies
in terms of the boinc-client claimed credits, the cpu may be idle and hence running at low frequencies when running benchmarks is started.
i'd like to suggest running the benchmarks twice in quick succession in boinc-gui, this is so that the 2nd benchmark is run pretty much when frequencies are still high.
Or perhaps if possible find a utility to set the cpu frequencies at max frequencies prior to running the benchmarks and you can revert that to adaptive scaling shortly after

cpu governors does a lot of frequency scaling running between low frequencies and max frequencies
in terms of the boinc-client claimed credits, the cpu may be idle and hence running at low frequencies when running benchmarks is started.
i'd like to suggest running the benchmarks twice in quick succession in boinc-gui, this is so that the 2nd benchmark is run pretty much when frequencies are still high.
Or perhaps if possible find a utility to set the cpu frequencies at max frequencies prior to running the benchmarks and you can revert that to adaptive scaling shortly after

The benchmark numbers I'm getting seem to be in line with the statistics, the average 3600 on this site gets a floating-point speed of 5.13 GFlops per thread, mine gets a speed of 5.09 GFlops per thread (I can get a bit over 5.25Gflops if the benchmark happens to be run on the fastest core, but there is only a 1/6 chance of that happening), which is within the margin of error, really. The 8700 I've linked to achieved a speed of 4.36GFlops for the benchmarks, which is quite a bit lower than mine, yet that is not reflected in the credits, either.

I don't think the benchmark is to blame for my issues. If it were, I would be having issues with really low claimed credits for other projects, which I don't. I think the Windows BOINC client just isn't computing the claimed credits for extremely long-running Rosetta tasks correctly. One easy way to test this is for me to set my target runtime to something like 8 hours. The admin seems to have applied a stopgap fix, but that isn't a stable fix, nor does it address the issue. Something about my set up does not like extremely long-running Rosetta@home tasks and only Rosetta@home tasks. My guess is that the Windows BOINC client may be, for some reason, ignoring your actual runtime and defaulting to the target runtime of 8 hours when calculating the claimed credits for extremely long-running tasks.

My guess is that the Windows BOINC client may be, for some reason, ignoring your actual runtime and defaulting to the target runtime of 8 hours when calculating the claimed credits for extremely long-running tasks.

The BOINC client isn't involved in the determination of Credit as such (other than providing the benchmarks, and passing the information needed to determine Credit from the processed Task & the application used to the server).
It's up to the project's Credit routine making use of the data it gets from the science application client to figure out how much to award.

---

Grant
Darwin NT

My guess is that the Windows BOINC client may be, for some reason, ignoring your actual runtime and defaulting to the target runtime of 8 hours when calculating the claimed credits for extremely long-running tasks.

The BOINC client isn't involved in the determination of Credit as such (other than providing the benchmarks, and passing the information needed to determine Credit from the processed Task & the application used to the server).
It's up to the project's Credit routine making use of the data it gets from the science application client to figure out how much to award.

Yes, I am aware of that.
Isn't the claimed credits calculated by the BOINC client though? My understanding of the Rosetta@home credit system is that if your claimed credit is way lower than what the project calculated, then it awards you with the claimed credits.

Brilliant, now my Mac has applied for entry into the 200ish credits per 36 hours per core club.
DNAN1001_SAVE_ALL_OUT_IGNORE_THE_REST_7lw2fx9l_925093_2_0
205.20 credits in 36 hours... Even my 2016 smartphone beats that...
https://boinc.bakerlab.org/rosetta/result.php?resultid=1164224727

<core_client_version>7.16.6</core_client_version>
<![CDATA[
<stderr_txt>
command: rosetta_4.16_x86_64-apple-darwin -run:protocol jd2_scripting -parser:protocol design_filter_BOINC.xml @flags_dummy -in:file:silent DNAN1001_SAVE_ALL_OUT_IGNORE_THE_REST_7lw2fx9l.silent -in:file:silent_struct_type binary -silent_gz -mute all -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip DNAN1001_SAVE_ALL_OUT_IGNORE_THE_REST_7lw2fx9l.zip @DNAN1001_SAVE_ALL_OUT_IGNORE_THE_REST_7lw2fx9l.flags -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 3314428
Starting watchdog...
Watchdog active.
======================================================
DONE ::   218 starting structures   129461 cpu seconds
This process generated    218 decoys from     218 attempts
======================================================
BOINC :: WS_max 8.51485e+08

BOINC :: Watchdog shutting down...
17:49:22 (33188): called boinc_finish(0)

</stderr_txt>
]]>

On the other hand, my newer phone seems to be getting absurdly high credits.

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"
That seems oddly low for my devices operating 24/7 nonstop and without sleeping. I know they are not sleeping because
1) The "decoys generated" seem normal
2) In the case of my Mac... OH GAWD THE FAN, JUST TAKE OFF ALREADY!

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"
That seems oddly low for my devices operating 24/7 nonstop and without sleeping. I know they are not sleeping because
1) The "decoys generated" seem normal
2) In the case of my Mac... OH GAWD THE FAN, JUST TAKE OFF ALREADY!
3) The average processing rate in other projects are much higher.

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"

I reckon that'd be it.
As far as it's concerned your system isn't actually doing much processing during the period the Task is running, hence the low APR. APR is used for Credit calculations with Credit New- and i expect with Rosetta's Credit mechanism as well.

Now the questions are- why have the values gone funny? And why haven't they re-calibrated themselves after a few Tasks have been completed?

---

Grant
Darwin NT

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"

I reckon that'd be it.
As far as it's concerned your system isn't actually doing much processing during the period the Task is running, hence the low APR. APR is used for Credit calculations with Credit New- and i expect with Rosetta's Credit mechanism as well.

Now the questions are- why have the values gone funny? And why haven't they re-calibrated themselves after a few Tasks have been completed?

That's what I am wondering. Worse, as far as I know, those values have, in fact, gone down (this explains why my Mac has only recently started suffering from the issue). I think this HAS to have something to do with my marathon run-times.

Hmm, the default runtime is 8 hours, right?
36h/8h=4.5

4.5*0.84GFlops=3.78Gflops (A much saner value)

Now, the default runtime used to be 6 hours
36h/6h=6
6*0.84GFlops = 5.04 Gflops (much more in line with the capabilities of a 3600)

I think the APR calculations might not have caught on to the fact that longer running Rosetta tasks mean more work. Maybe, just maybe, it believes Rosetta tasks have an estimated computation size of 80,000 GFLOPs no matter what.

Now, if this is true, I think my APR should trend towards 0.62 Gflops.

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"
That seems oddly low for my devices operating 24/7 nonstop and without sleeping. I know they are not sleeping because
1) The "decoys generated" seem normal
2) In the case of my Mac... OH GAWD THE FAN, JUST TAKE OFF ALREADY!
3) The average processing rate in other projects are much higher.

I have no idea what the reason is, but why don't you set no new tasks and suspend everything for a minute, then Run CPU Benchmarks from the Tools menu.
Does the figure change? Could something have gone wrong the previous time it ran?
Just a suggestion

---

Hmm, is this the issue?
"Average processing rate 0.84 GFLOPS"
"Average processing rate 0.65 GFLOPS"
That seems oddly low for my devices operating 24/7 nonstop and without sleeping. I know they are not sleeping because
1) The "decoys generated" seem normal
2) In the case of my Mac... OH GAWD THE FAN, JUST TAKE OFF ALREADY!
3) The average processing rate in other projects are much higher.

I have no idea what the reason is, but why don't you set no new tasks and suspend everything for a minute, then Run CPU Benchmarks from the Tools menu.
Does the figure change? Could something have gone wrong the previous time it ran?
Just a suggestion

Average processing rate doesn't change. The benchmarks have nothing to do with APR. I've tried that quite a few times, and it only changes the peak device speed.

Hmm, I wonder why the APR on my newish phone is so comically high (for an ARM processor)? It apparently has an APR of 2.28 GFlops. The only setting on that device that is different from my other devices is target run-time -- that device is using the default marathon target runtime of 8 hours instead of my typical rather pedestrian 36 hours. I could change the target run-time to 8 hours as a fix, but that does not solve the issue. It would appear that a long target runtime punishes the user credit-wise.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Notice how my APR is much higher in older versions?

Rosetta 4.08 x86_64-apple-darwin
Number of tasks completed 3
Max tasks per day 503
Number of tasks today 0
Consecutive valid tasks 3
Average processing rate 3.94 GFLOPS
Average turnaround time 2.07 days

Rosetta 4.09 x86_64-apple-darwin
Number of tasks completed 111
Max tasks per day 505
Number of tasks today 0
Consecutive valid tasks 5
Average processing rate 3.72 GFLOPS
Average turnaround time 2.06 days

Rosetta 4.12 x86_64-apple-darwin
Number of tasks completed 2
Max tasks per day 502
Number of tasks today 0
Consecutive valid tasks 2
Average processing rate 0.95 GFLOPS
Average turnaround time 1.59 days

Rosetta 4.15 x86_64-apple-darwin
Number of tasks completed 9
Max tasks per day 501
Number of tasks today 0
Consecutive valid tasks 1
Average processing rate 0.65 GFLOPS
Average turnaround time 2.12 days

Rosetta 4.16 x86_64-apple-darwin
Number of tasks completed 26
Max tasks per day 516
Number of tasks today 3
Consecutive valid tasks 16
Average processing rate 0.65 GFLOPS
Average turnaround time 1.97 days

Other than different software versions, I also changed the target runtime from the default 6 hours (it was 6 hours back in those days) to 36 hours. Also, in the 4.12 days, the max target run-time was 24 hours, and it was hence set to that.

Hi,
Any definite answer as to whether longer runtimes e.g. 36 hours overall net less credit then, say, 8?
I'm trying to find that sweet spot, though I also think that benchmarks on Linux are still broken, even in the latest build - 7.16.6. Maybe Windows has followed that trend.
My 1800x seems to be getting right around what it's supposed to, though.
I'll be throwing a few more 3rd and 4th gen Intels at the project, but this is very disappointing. Not that I care too much about the credits, but I was going to be building a nice Ryzen 3 or 5 to help out even more.

I need to get Boinc on my new ish Android. I thought it was a little finicky to get working on a device running later than Android 9, or has that been fixed?

Thanks and hope you can get this issue resolved.

Hi,
Any definite answer as to whether longer runtimes e.g. 36 hours overall net less credit then, say, 8?
I'm trying to find that sweet spot, though I also think that benchmarks on Linux are still broken, even in the latest build - 7.16.6. Maybe Windows has followed that trend.
My 1800x seems to be getting right around what it's supposed to, though.
I'll be throwing a few more 3rd and 4th gen Intels at the project, but this is very disappointing. Not that I care too much about the credits, but I was going to be building a nice Ryzen 3 or 5 to help out even more.

I need to get Boinc on my new ish Android. I thought it was a little finicky to get working on a device running later than Android 9, or has that been fixed?

Thanks and hope you can get this issue resolved.

It will be normal at first, once your average processing rate drop to silly levels your credit per task will suffer. Once the problem kicks in then yeah, your 36-hour tasks will potentially net lower credits per task than 8-hour ones (and you're RAC will decrease A LOT, eventually). The faster the CPU, the more it will suffer, comparatively.
The changes the Admin recently made in an effort did delay the bug, but since it is seemingly only a stopgap measure, the problem will eventually bite...

I'm tempted to try finding the longest target runtime before the problem strikes, but I don't think it'll be worth the effort.

As for the problem with Android 9 and later, I find HTC's version of BOINC to still work somewhat (it's called Power to Give). Try manually launching BOINC every time you plug in your device.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Notice how my APR is much higher in older versions?

Yes. But mine seems to be pretty consistent (I'm actually overclocking 10% less since I changed my motherboard a month ago so I might say it's holding up surprisingly well.

I don't think a longer runtime makes any difference at all. You might say the smaller overhead on longer tasks might boost it, if anything. But I'd suggest the average credit for newer tasks might be lower on recent tasks because of a very different profile of users since they came out, with so many powerful machines transferring from Seti. Might that make a difference? Obviously I'm guessing.

My general rule is that if you've come to Rosetta for credits, expect disappointment compared to what you're used to. The rule's held up pretty well. Generally, credits seem to be awarded in inverse proportion to the significance of the project.

Other than different software versions, I also changed the target runtime from the default 6 hours (it was 6 hours back in those days) to 36 hours. Also, in the 4.12 days, the max target run-time was 24 hours, and it was hence set to that.

Probably 3 years since it was 6hrs. The 36hr option just came in last month, yes

---

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735

Notice how my APR is much higher in older versions?

Yes. But mine seems to be pretty consistent (I'm actually overclocking 10% less since I changed my motherboard a month ago so I might say it's holding up surprisingly well

Other than different software versions, I also changed the target runtime from the default 6 hours (it was 6 hours back in those days) to 36 hours. Also, in the 4.12 days, the max target run-time was 24 hours, and it was hence set to that.

Probably 3 years since it was 6hrs. The 36hr option just came in last month, yes

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

ARP SHOULDN't be affected much by target runtime since the longer you run tasks, the more work your computer does, the current ARP calculation does not seem to reflect that.

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

*Note, I just edited my previous message*

In short, whatever method is used for credits, consistency or coherence isn't going to arrive.
There might be consistency within Junior_Halfroid tasks, or r4k or r3x (or might not - they change so often) but you get what you get and any time you spend worrying about it is wasted.

---

That means the problem IS the target runtime. For each version, I had different target runtimes. 6 hours before 4.12, 24 hours on 4.12, 36hours after 4.12. Since your data suggests software version has very little effect on APR than that leaves only target runtime.
Why does increasing the target runtime to 24 hours from 6hours cause a decrease in ARP by a factor of around 4? Why does increasing the target runtime cause the ARP to drop even further?

*Note, I just edited my previous message*

In short, whatever method is used for credits, consistency or coherence isn't going to arrive.
There might be consistency within Junior_Halfroid tasks, or r4k or r3x (or might not - they change so often) but you get what you get and any time you spend worrying about it is wasted.

But a 6X different in ARP isn't normal in any sense. Why am I getting not much more, if not fewer credits per tasks for 36-hour tasks than 6-hour tasks? (I used to get around 150 per task, now I'm getting 230-240 per task, on a faster CPU, with a 36-hour run-time) It almost appears as the project thinks 36-hour tasks have a similar amount of work done as 6-hour ones, and your computer must be 6X slower because it took 6X the time for completion. If it was a 10% difference I wouldn't worry. If it is a 6X difference than something seems wrong.

have a look at this host, an Ryzen 7 2700X achieving an ARP of 10.33 GFLOPS. How's that even possible? Look at the typical runtime of the tasks, and you'll realize that the user has a pretty short target runtime.
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3684192

Besides, after Admin's tweak, I consistently got around 2000 credits for r4k tasks, but now I'm getting 230-240 credits per tasks most of the time (again). It's not a problem with consistency.

Once 4.20 drops, I may shorten my target runtime to 8 hours, just to prove a point.

Oh, look. My mac just got pulled back to normalcy... I guess it's probably on the brink of being affected by whatever issue is plaguing my main rig.

Now that 4.20 is officially out for Macs, I've adjusted my target runtime to the default value. If my theory on the issue is correct, the ARP for Rosetta 4.20 x86_64-apple-darwin should be about 2.9Gflops, and the number of credits per task should be around 270, which is still higher than what my main rig gets for 36-hour tasks.

https://boinc.bakerlab.org/rosetta/host_app_versions.php?hostid=2263735