I just noticed that my Ryzen 5 3600 seems to be netting quite a bit fewer credits per core per hour than comparable, or even much slower systems.

For example, for Rosetta 4.15/4.16 tasks, my 3600 is netting 200-300 credits per core per 36 hours, whilst my phone from 2016 is getting 200-500 credits per core per 36 hours, and my 2015 13 inch Macbook Pro is getting about 1000 credits per core per 36 hours. I don't get it, my Ryzen system seems to be consistently generating way more "Decoys" per WU than my Macbook Pro, so why are the credits way lower?

Is that just a fluke, since this issue does not seem to be reflected in my RAC for each computer. Or does that indicate a problem with my Ryzen system?

Rosetta mini tasks seem to behave normally, with my Ryzen system consistently netting 1700-2000 credits per core per 36 hours.

Thanks!

Is that just a fluke, since this issue does not seem to be reflected in my RAC for each computer. Or does that indicate a problem with my Ryzen system?

It's just the way the Credit mechanism is. Different work mixes on different systems will give a different amount of Credit. Overall, they should end up fairly (sort of, mostly) similar, but there are always ups & down with Credit granted even for WUs that have been around for a while, a mix of new & old WUs & different hardware then the ups & downs tend to be bigger than usual.

---

Grant
Darwin NT

Is that just a fluke, since this issue does not seem to be reflected in my RAC for each computer. Or does that indicate a problem with my Ryzen system?

It's just the way the Credit mechanism is. Different work mixes on different systems will give a different amount of Credit. Overall, they should end up fairly (sort of, mostly) similar, but there are always ups & down with Credit granted even for WUs that have been around for a while, a mix of new & old WUs & different hardware then the ups & downs tend to be bigger than usual.

Welp, it still feels weird to have your main rig rather consistently beaten by much older ARM an Bulldozer CPUs. I just do not understand how the credit system works.

An example is this:
My phone got 396.06 on this WU (r4k_10886_fold_SAVE_ALL_OUT_920986_87_0)

<core_client_version>7.4.39</core_client_version>
<![CDATA[
<stderr_txt>
command: ../../projects/boinc.bakerlab.org_rosetta/rosetta_4.15_arm-android-linux-gnu -abinitio::fastrelax 1 -ex2aro 1 -frag3 00001.200.3mers.index -in:file:native 00001.pdb -silent_gz 1 -frag9 00001.200.9mers.index -out:file:silent default.out -ex1 1 -abinitio::rsd_wt_loop 0.5 -relax::default_repeats 5 -abinitio::use_filters false -abinitio::increase_cycles 10 -abinitio::rsd_wt_helix 0.5 -beta 1 -abinitio::rg_reweight 0.5 -in:file:boinc_wu_zip r4k_10886_data.zip -out:file:silent default.out -silent_gz -mute all -nstruct 10000 -cpu_run_time 28800 -watchdog -boinc:max_nstruct 5000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 2942914
======================================================
DONE ::     1 starting structures   128071 cpu seconds
This process generated     54 decoys from      54 attempts
======================================================
BOINC :: WS_max 0
 called boinc_finish(0)

</stderr_txt>
]]>

While my main rig got only 271.31 credits on this WU (r4k_16816_fold_SAVE_ALL_OUT_921555_181_0) despite generating 6X the "Decoys"

<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 -abinitio::fastrelax 1 -ex2aro 1 -frag3 00001.200.3mers.index -in:file:native 00001.pdb -silent_gz 1 -frag9 00001.200.9mers.index -out:file:silent default.out -ex1 1 -abinitio::rsd_wt_loop 0.5 -relax::default_repeats 5 -abinitio::use_filters false -abinitio::increase_cycles 10 -abinitio::rsd_wt_helix 0.5 -beta 1 -abinitio::rg_reweight 0.5 -in:file:boinc_wu_zip r4k_16816_data.zip -out:file:silent default.out -silent_gz -mute all -nstruct 10000 -cpu_run_time 28800 -watchdog -boinc:max_nstruct 5000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 2083630
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.
======================================================
DONE ::     1 starting structures   129490 cpu seconds
This process generated    331 decoys from     331 attempts
======================================================
BOINC :: WS_max 4.32751e+08

BOINC :: Watchdog shutting down...
02:36:22 (10952): called boinc_finish(0)

</stderr_txt>
]]>

Furthermore, it appears to me that every other rig I've had a look at seems to only get slightly lower (around 200) credits per task at the default run time of 8 hours than my main rig does per task at 36 hours.
I'm tempted to change my target run-time to the default of 8 hours and see how that affects my RAC.

Is that just a fluke, since this issue does not seem to be reflected in my RAC for each computer. Or does that indicate a problem with my Ryzen system?

It's just the way the Credit mechanism is. Different work mixes on different systems will give a different amount of Credit. Overall, they should end up fairly (sort of, mostly) similar, but there are always ups & down with Credit granted even for WUs that have been around for a while, a mix of new & old WUs & different hardware then the ups & downs tend to be bigger than usual.

I just do not understand how the credit system works.

To be honest, i don't think anyone does.
Rosetta uses their own system. It was a response to the original BOINC Credit system (which was seriously broken) and developed before Credit New came out (which is also broken beyond in belief, just in different ways to the original system). And apparently under certain circumstances the present Rosetta Credit mechanism reverts back to using the underlying BOINC Credit New system (did i mention that Credit New is extremely broken?). So while the Credit allocated is generally (mostly, sort of) relatively consistent, there are circumstances that result in rather large deviations (up, down & sideways).

I'm tempted to change my target run-time to the default of 8 hours and see how that affects my RAC.

It would be interesting to see what the results are (the biggest problem being the long Runtime of Rosetta Tasks, and the continually changing mix of Tasks, as well as the continually changing types of Tasks makes direct comparisons pretty much near impossible (and with a well working Credit system that wouldn't be the case). But if the changes are significant enough, then some conclusions could reasonably be drawn).

---

Grant
Darwin NT

And apparently under certain circumstances the present Rosetta Credit mechanism reverts back to using the underlying BOINC Credit New system (did i mention that Credit New is extremely broken?).

That was what I was suspecting. A lot of the time I fail to see much of a difference between the credits per task on my main rig and those of others. And that is with a 28 hour run-time difference and my CPU being the much faster one, in many cases.

I know for sure that my Macbook Pro and my phones seem to be free from this issue (at least for recent tasks). Since I've increase my run-time from 12 hours to 36 hours on my Mac, and it got a 2X-ish increase in credits per task, which is to be expected.

Maybe this issue might be limited to Rosetta for Windows (Rosetta mini seems fine) that have a really long target run-time? I need to try messing with the target run-time on my main rig.

Since big bad proteins are coming to Rosetta, this is gonna be fun...

The worst protein I've seen so far took 36 hours of crunching on my main rig to generate 11 "decoys", it achieved a peak working set size of 2,802.30 MB and a peak swap size of 3,462.16 MB. I cannot imagine what an actual big bad protein would do...

My apologies since I've been busy with other things to look into this until now. There indeed is an issue that I will soon fix. Your machine is generating more than the maximum allowable credit but this is our fault. I will adjust our server accordingly.

---

My apologies since I've been busy with other things to look into this until now. There indeed is an issue that I will soon fix. Your machine is generating more than the maximum allowable credit but this is our fault. I will adjust our server accordingly.

Ah, that explains everything.
Thanks!

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

---

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

Thanks, it appears to have been fixed.

Just got 2,010.91 credits for a task, now THAT'S more like it.

Time to stand back and watch my RAC explode...

It is odd that you were reporting back such low claimed credit. I'm not sure what is going on with your BOINC client. Typically the claimed credit is somewhat in line with the credit our validator calculates based on the credit/decoy average.

So it wasn't completely a fault of our settings, for some reason your boinc client is reporting very low credit based on the client benchmarks etc.

---

It is odd that you were reporting back such low claimed credit. I'm not sure what is going on with your BOINC client. Typically the claimed credit is somewhat in line with the credit our validator calculates based on the credit/decoy average.

So it wasn't completely a fault of our settings, for some reason your boinc client is reporting very low credit based on the client benchmarks etc.

I'm running BOINC Manager 7.16.5 (x64) for Windows. Given the fact that my other devices don't have this problem, maybe it's an issue with that particular version?

Maybe my marathon run-times also have something to do with it? I don't know how the "claimed credit" works. I don't even know were to see that stat.

What I do know is that for Rosetta tasks, the estimated computation size is always 80,000 GFLOPs, regardless of target run-time.

What was happening with your jobs was that there is a check that makes sure that (the credit/model average from our server) * (the number of models your computer generated) is not greater than X*(claimed credit reported back from your BOINC client) where X is a parameter we have set. Since your computer was reporting back relatively low credit (like < 300), and was thus not passing the above criteria, our validator was just giving you the claimed credit.

---

What was happening with your jobs was that there is a check that makes sure that (the credit/model average from our server) * (the number of models your computer generated) is not greater than X*(claimed credit reported back from your BOINC client) where X is a parameter we have set. Since your computer was reporting back relatively low credit (like < 300), and was thus not passing the above criteria, our validator was just giving you the claimed credit.

Hmm, is the claimed credits based on estimated computing size? Because the estimated computation size seems to be 80,000 GFLOPs for Rosetta tasks, regardless of target run-time.

https://boinc.berkeley.edu/trac/wiki/CreditOptions

---

Credit options
Made it clickable.

---

Grant
Darwin NT

The credit claim is reported by the BOINC Manager, and basically is a measurement of FLOPS used to complete the WU. But the BOINC Manager estimates this based on the machine's benchmarks. Here is what the website presently shows for your two main hosts' benchmarks:

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3754624
12 CPUs 16GB
Measured floating point speed 5096.8 million ops/sec
Measured integer speed 19562.16 million ops/sec

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=2263735
4 CPUs 8GB
Measured floating point speed 5713.75 million ops/sec
Measured integer speed 13258.92 million ops/sec

So why would your 12 CPU machine report less FLOPS than your 4 CPU machine? There must have been some other major tasks running the last time BOINC Manager ran the benchmarks.

---

Rosetta Moderator: Mod.Sense

So why would your 12 CPU machine report less FLOPS than your 4 CPU machine? There must have been some other major tasks running the last time BOINC Manager ran the benchmarks.

I think the question is why are the reported benchmarks for the i5-5287U CPU so high??? It outperforms my i7-8700Ks at 4.3GHz by a considerable amount.
Overclocked to within an inch of it's life?

---

Grant
Darwin NT

The credit claim is reported by the BOINC Manager, and basically is a measurement of FLOPS used to complete the WU. But the BOINC Manager estimates this based on the machine's benchmarks. Here is what the website presently shows for your two main hosts' benchmarks:

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3754624
12 CPUs 16GB
Measured floating point speed 5096.8 million ops/sec
Measured integer speed 19562.16 million ops/sec

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=2263735
4 CPUs 8GB
Measured floating point speed 5713.75 million ops/sec
Measured integer speed 13258.92 million ops/sec

So why would your 12 CPU machine report less FLOPS than your 4 CPU machine? There must have been some other major tasks running the last time BOINC Manager ran the benchmarks.

Wait, isn't that number for single thread, not multi-thread? The numbers I am getting seem to be normal, since the slightly higher clocked 3600X has a floating point speed of 5.27 billion ops/sec according to the statistics on this site. I reran the BOINC benchmark, ensuring that there are as little background processes as there can be and with all tasks suspended, but the benchmark results didn't improve.

Besides, if "1 unit of credit = 1/200 day runtime on a CPU whose Whetstone benchmark is 1 GFLOPS. " according to the BOINC https://boinc.berkeley.edu/trac/wiki/CreditOptions page is true, then my rig should be claiming 1500 credits per task, not under 300.

So why would your 12 CPU machine report less FLOPS than your 4 CPU machine? There must have been some other major tasks running the last time BOINC Manager ran the benchmarks.

I think the question is why are the reported benchmarks for the i5-5287U CPU so high??? It outperforms my i7-8700Ks at 4.3GHz by a considerable amount.
Overclocked to within an inch of it's life?

I have absolutely no idea... The BOINC benchmarks reported a 6.1 GFlops for my piddly i5-5287U stuffed in a glorified lap warmer 13-inch Macbook Pro on a good day... Which is a terrifying amount of GFlops for a machine that can barely run Chrome.

In case you're wondering, 6.1GFlops floating point is i9-9900K territory according to the statistics page.

I think it is safe to say there is something odd going on with BOINC's benchmarks... at least for my laptop. Unless i got miracle class silicon in my laptop boosting to 5 GHz (on regular nitrogen)...

---

I think it is safe to say there is something odd going on with BOINC's benchmarks... at least for my laptop. Unless i got miracle class silicon in my laptop boosting to 5 GHz (on regular nitrogen)...

I just noticed, different operating systems.
It shouldn't make any difference at all, but there's a good chance it does.

Edit- and cache sizes between systems, at least what is reported.
I'm thinking different L1 & L2 caches. L1 in particular. Shouldn't be a fact in benchmark results, but undoubtedly is. Even though the desktop systems have a much larger total cache, the L1 & L2 caches per core are probably smaller.

---

Grant
Darwin NT