Come to think about it Rosetta@home is on its own a compute benchmark for cpus :)

to start off:

my pc:
CPU type: GenuineIntel Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz [Family 6 Model 60 Stepping 3]
Number of CPUs: 8
Operating System: Linux 3.11.6-4 X86_64 Opensuse 13.1
Boinc: 7.0.36
Rosetta: minirosetta_3.52_x86_64-pc-linux-gnu
Memory: 15767.95 MB
Cache: 8192 KB
Swap space: 17408 MB
Total disk space: 49.09 GB
Free Disk Space: 25.68 GB
Measured floating point speed: 3988.83 million ops/sec
Measured integer speed : 15235.01 million ops/sec
Average turnaround time 0.24 days

no GPU based processing.

------------
some 2 cents comments:
i7 4771 is actually 4 core hyper-threaded into 8 'cpus'

i'm running Linux 3.11.6-4 X86_64 64 bit X86_64 O/S.
as it turns out the X86_64 platform with boinc client 7.0.36, minirosetta_3.52_x86_64-pc-linux-gnu runs pretty stably on the system.
i've observed that for just about every job thus far it runs end to end with no errors. I noted some jobs which ran through on my pc error free has errors in MS Windows7/8 x86 for the current release of minirosetta. I'm not sure if that's a MS windows platform specific error.

However, i'd just like to say that running a 64 bits O/S has lots of benefits with crunching Rosetta@home. For one thing 64 bits O/S breaks the 4 GB 'barrier' and makes available RAM on systems installed with > 4 GB ram in a much 'natural' way. while 32 bit systems can use RAM > 4GB, u'd need to ensure u're using a PAE enabled OS. in addition, it seemed some os have additional restrictions on memory use
http://en.wikipedia.org/wiki/3_GB_barrier#Windows_version_dependencies
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%28v=vs.85%29.aspx

in addition, i read some articles which apparently shows that x86_64 number crunching apps runs faster than 32bit versions on the same platform be they AMD or Intel. The penalty being that 64 bit apps eats moderately more memory (RAM) than do their 32 bit equivalents.

my current 64 bit linux setup as i've observed boinc managed a throughput of 8 concurrent Rosetta@home jobs & utilizing the RAM well without hitting disk swap. This could have made some difference completing each compute job 'faster'.

if based on a 'perfect' estimate 3.988 Gflops translate to a max possible RAC of 3.988 * 200 = 797.6 credits RAC. it seemed that Rosetta@home is pretty much closing in on the Gflops estimate. Current RAC seen around 750, could be slightly more when next set of jobs concluded. RAC falls off soon after going idle for some time :o :)
http://boinc.berkeley.edu/wiki/computation_credit

i'm not too sure if 3.988 Gflops is a per 'cpu' Gflops, if that's true then a i7 4771 cpu is delivering about 3.988 x 8 ~ 31.9 GFlops into the distributed computing effort.

i've read that the 'older' supercomputers are clocking some 100 Gflops per node. this benchmark for a average higher end home PC is interesting as it perhaps takes 2.5 home PCs to break even the per node computation power of the 'older' per node supercomputer prowess.

for the 'overclocked' PCs it may get even closer to simply 2 home PCs

just some 2 cents blurbs :)

last RAC seen 807.78 :)
if it is a per 'cpu' figure, 807.78 / 200 ~ 4.04 Gflops
i7 4771
if rac is per 'cpu', based on 8 'cpus' (4 cores - hyperthreaded into 8): 4.04 Gflops x 8 ~ 32.3 Gflops delivered to distributed computing

last RAC seen 887.17 :)
if it is a per 'cpu' figure, 887.17 / 200 ~ 4.4358 Gflops
i7 4771
if rac is per 'cpu', based on 8 'cpus' (4 cores - hyperthreaded into 8): 4.4358 Gflops x 8 ~ 35.48 Gflops delivered to r@h distributed computing

The RAC shown on the website is Recent Average Credit granted by R@h to a specific host machine. So how you configure hyperthreading etc. won't change the figure. It's just raw work completed over the last... 14 days I think it is.

---

Rosetta Moderator: Mod.Sense

The RAC shown on the website is Recent Average Credit granted by R@h to a specific host machine. So how you configure hyperthreading etc. won't change the figure. It's just raw work completed over the last... 14 days I think it is.

hi Mod.Sense,

thanks for the reply, i guess that's how RAC can appear to exceed the 'measured' gflops :)

ok here is one more try
http://boinc.berkeley.edu/wiki/computation_credit
based on the hints:

A BOINC project gives you credit for the computations your computers perform for it. BOINC's unit of credit, the Cobblestone (named after Jeff Cobb of SETI@home), is 1/200 day of CPU time on a reference computer that does 1,000 MFLOPS based on the Whetstone benchmark

c : the number of credits granted/claimed for a particular task/job
t : the time in *days* for that particular job

gflops estimate = c / ( t * 200 )

e.g. if a particular job is granted/claimed 100 credits and the job runs for 3 hours
t = 3 / 24 = 0.125

g flops estimate = 100 / (0.125 * 200 ) = 4 gflops

if each job runs on a particular 'cpu' then this is actually a per 'cpu' throughput. hence, that can be multiplied by the number of 'cpus' (including the hyper threaded counts if it runs 1 job per thread per 'cpu').

hence if there are 8 'cpu' threads it gives an estimate of 4 x 8 ~ 32 gflops throughput.

a disclaimer here, these are basically **estimates** based on the credits granted per job and elapsed time during the run. there could be many other factors involved which i'm not sure of (e.g. network time and idle waits before running or submitting could affect the estimates as well as possible credits scaling)

I'm not sure if it is still the case, but the last time I looked into Rosetta's awarding of credit, it was based on an average per decoy.

For a task involving protein X the first person to complete the task claims 100 credits per decoy completed and receives the full amount. The next person to complete the protein X task claims 200 credits per decoy completed and receives 150 (as the average of the two results). A third person who completes the same task claims 50 credits per decoy and receives 116.67 credits (the average of the 3 results). This continues as more results are returned for the task.

A new task involving protein Y is released and the same process repeats itself from the start.


The above is a bit of a simplification of the process described in The new credit system explained (my calculations assume that each person completes 1 decoy and claims a round number of credits). It is quite an old thread now so it is possible that the system has been changed since then.

Right, sgaboinc has shown standard BOINC credit system, and this is the basis for credit "claim" by host. And the server essentially averages past claims for comparable tasks and issues "granted" credit based on the number of decoys (or models, or parachutes) times the average reported by other users. This avoids giving incentive to attempt to spoof the credit system, because the credit actually awarded to you is not based on any inflated figures.

---

Rosetta Moderator: Mod.Sense

thanks Murasaki and Mod.Sense

i think even if the credits are awards based on decoys, it is still a good (perhaps even better as it measures actual work involved) **estimate** of the gflops based on credits awarded. the credits claimed is also a useful figure since that's determined by the cpu itself. it also becomes a possible way to compare setups based on the rosetta@home workloads

working out the gflops for particular jobs makes it possible to compare against one's 'measured' gflops on the synthetic benchmarks (which is often too idealised).

if the worked gflops from granted credit / credit claimed is lower than the synthetic benchmark, it sort of measure the 'efficiency' against those idealized synthetic benchmarks. while if it is higher than the synthetic benchmarks possibly some processor specific optimizations (e.g. compiler optimization resulting in better superscalar performance) or even for that matter overclocks (e.g. Intel 'turbo boost') may have assisted/skewed the performance positively
of course this did not account for many things.

the idea here is that estimating gflops from rosetta credits (e.g. per job) provide a means to estimate the computing effectiveness of a particular host (not simply cpu), probably the full setup.

As my pc has a measured 4 gflops measured whestone benchmark per 'cpu'. i tend to see awarded / claimed credits fluctating around the 100 credits per 3 hour jobs mark. at times 90 credits and for some jobs slightly more than 100 credits. The estimated gflops as given earlier for a 3 hour job at 4 gflops per job would translate to roughly 100 credits.

if performances are worse than synthetic benchmarks, it may point to possible bottlenecks perhaps caused by inadequate memory , hitting disk swap / page file etc.

in those cases the throughput per job may possibly be simply improved running somewhat less concurrent jobs to alleviate the memory swapping issues etc or even for that matter it could be a hint to add memory and/or upgrade os to 64 bits etc. (some of the 32 bits MS Windows versions are limited to addressing 4 GB of memory).

i'd say that some of these hardware (e,g. memory), o/s upgrades could actually be beneficial for other computing purpose as well other than rosetta@home itself.

just 2 cents, cheers :)

btw i noted something rather interesting apparently.
if the jobs are reporting granted credit lower than claimed credit, it may mean the PC is 'faster than average'. while on the other hand if u see claimed credit that's higher than granted credit, it may mean your pc may be 'slower than average' :o :p :) lol

just 2 cents :)

btw i noted something rather interesting apparently.
if the jobs are reporting granted credit lower than claimed credit, it may mean the PC is 'faster than average'. while on the other hand if u see claimed credit that's higher than granted credit, it may mean your pc may be 'slower than average' :o :p :) lol

just 2 cents :)

oops typo, it should read:
while on the other hand if u see granted credit that's higher than claimed credit, it may mean your pc may be 'slower than average'

not too sure if it is true :o :p :) lol

Yes, if granted credit is consistently higher than claimed, then your machine is performing better than others out there will similar CPU benchmark. Or, perhaps I should more accurately say it is performing better than the mix of average benchmark as compared to average work produced.

You mentioned the impacts of things other than raw CPU performance that can get in the way of actual work being done... memory, L2/L3 cache size, disk IO time, efficiency of operating system, it all weighs in to overall performance. The existing method of granting credit basically automatically awards higher credit to machines that actually yield more completed results.

It's sort of like saying "Yes Mr./Mrs. consultant, I know you are very intelligent... but that is worth nothing to me if you can't communicate effectively". One attribute (CPU speed, or intelligence) does not really tell the whole story. So the existing credit system is a fairly simple way to ensure fairness across all platforms and configurations.

---

Rosetta Moderator: Mod.Sense

rather the thoughts are something like this:

As different computers process each job of an averaged fix duration (e.g. 3 hours), the faster PCs would claim more credits for the 3 hour job while the slower PCs claim less credits for the same/equivalent 3 hours jobs. claimed credits are relevant to the amount of work done hence a measure of the host's computing prowess (it is possibly a net benchmark of the full setup including cpu, ram, disk, network etc). in these cases the faster hosts processes more decoys/models while the slower hosts processes less decoys/models in the same averaged fix duration, hence the difference in credits.

rosetta@home averages that (the claimed credits) and grants credits based on the average of the similar/equivalent jobs.

in this case if rosetta@home grants less credits than claimed credits, your pc/host/cpu is running 'faster than average'

while if rosetta@home grants more credits than claimed credits, your pc/host/cpu is running 'slower than average'

it would then seem that the 'faster' hosts are 'subsidizing' the 'slower' hosts. However, i'd think that this is not really very much of an issue. it really illustrate that these are 'community' computing projects and it is after all a collective effort for the results/achievements.

i.e. even if 'average' credits is granted, collectively, rosetta@home earns more credits in the total combined boinc credits and hence progresses as a project

note that such information are not necessary negative in connotations, rather if rosetta@home is routinely awarding more credits than claims, which indicate your host being 'slower than average', an attempt may be made to identify the bottlenecks e.g. if it is possibly due to inadequate memory issues causing the processing to hit swap/pagefile which is significantly slower, which could possibly be aided by running somewhat less concurrent jobs or even a memory upgrade. however, if it is simply the cpu being slower then there's little to do about that. However, even if it is truly a slower cpu it is still contributing to the collective community distributed processing efforts so that the project gains as a whole.

the faster hosts may see a 'penalty' in the credits granted as their credits claimed would tend to be more than average (i.e. credits granted). However when rosetta@home is ranked against other projects on boinc combined credits, the sum of collective credits is conserved if a simple average is used and rosetta@home gains as a whole in the overall ranking vs all other boinc projects

While the faster hosts certainly post a high benchmark and therefore do claim high credits, they also tend to actually have features such as large L2/L3 cache which help them process R@h models efficiently. So consider a scenario something like this:

(completely made up numbers, just compare the relative measures of the two hypothetical machines)

Host: A (slow)
benchmark: 10 
Models in 3hrs: 20
Credit claimed: 90
Credit granted: 80 (4pts per model)

Host B (fast)
benchmark: 20 (2x)
Models in 3hrs: 47 (2.35x)
Credit claimed: 180 (2x)
Credit granted: 188 (4pts per model) (2.35x)

Since the slow one is actually claiming... call it "high" for the work they produce, they actually are bringing up the average credit on which the fast host is performing better than benchmarks would imply it should.

But the basic jist of it is that the benchmarks do not reflect useful work produced. The models do. If your machine can produce more models in an hour than it should be granted more credit per hour of work. If the project creates a new type of WU and a "fast" rig can only do a model an hour, but some processor nextgen can do two per hour, then, for that type of WU, credit will flow to the nextgen. But another type of WU may fall in to the strengths of "fast" rig, and so it carries it's own average and perhaps a slightly different reward level relative to any specific host.

---

Rosetta Moderator: Mod.Sense