BOINC has a bug which caused it, more than a week ago, to download more work to my system than could be processed in a week. Since these were 7-day WUs, the server has started re-issuing to other participants the WUs for which it had received 'no reply' after 7 days. However, those same WUs __remained__ queued up in my system, and were still being processed and reported -- until I manually aborted those leftovers.


This gave me a chance to compare the "claimed credit" for a Workunit which was processed to completion by two different 'computers' that happen to have the same "CPU type" description (Athlon MP 2400+). Yet the one 'cpu' (on Windows) reports a 'Measured floating point speed' of 1519, whereas the other 'cpu' (on Linux) reports a 'Measured floating point speed' of 1011. Since these are Athlons, it is not likely that the number reported from the 'cpu' using Windows is attributable to overclocking.

The system using Windows reported about 8 hours spent on this WU (implementing the new "CPU Max Time" approach). It claimed some 117 credits. The system using Linux reported about 4 hours spent on this WU (running only a single processor, and *NOT* yet implementing the new "CPU Max Time" approach). It claimed some 24.5 credits.


For the same "CPU type" description, the system using Windows claimed more than four times the credit for twice the reported duration. Was the Windows system processing for 8 hours on BOTH processors simultaneously?

Will the Rosetta application run parts of the __same__ Workunit in PARALLEL if multiple cpus are available?
.

Will the Rosetta application run parts of the __same__ Workunit in PARALLEL if multiple cpus are available?
.

I don't believe so - the OS may run the thread on both CPUs but it will be dynamically allocated serially so no process is running on both CPUs at the same time.

---

BOINC has a bug which caused it, more than a week ago, to download more work to my system than could be processed in a week. Since these were 7-day WUs, the server has started re-issuing to other participants the WUs for which it had received 'no reply' after 7 days. However, those same WUs __remained__ queued up in my system, and were still being processed and reported -- until I manually aborted those leftovers.


This gave me a chance to compare the "claimed credit" for a Workunit which was processed to completion by two different 'computers' that happen to have the same "CPU type" description (Athlon MP 2400+). Yet the one 'cpu' (on Windows) reports a 'Measured floating point speed' of 1519, whereas the other 'cpu' (on Linux) reports a 'Measured floating point speed' of 1011. Since these are Athlons, it is not likely that the number reported from the 'cpu' using Windows is attributable to overclocking.

The system using Windows reported about 8 hours spent on this WU (implementing the new "CPU Max Time" approach). It claimed some 117 credits. The system using Linux reported about 4 hours spent on this WU (running only a single processor, and *NOT* yet implementing the new "CPU Max Time" approach). It claimed some 24.5 credits.


For the same "CPU type" description, the system using Windows claimed more than four times the credit for twice the reported duration. Was the Windows system processing for 8 hours on BOTH processors simultaneously?

Will the Rosetta application run parts of the __same__ Workunit in PARALLEL if multiple cpus are available?
.

I may not understand your question, but it is possible that one of the systems ran the WU longer than the other say 4 hours verses 8. This would cause one sytem to claim more credit, but it cannot process as many WUs as the other system.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

The Windows machine you are referring to appears to be running an optimized Boinc client.(nearly double the integer speed of my MP 2600) This inflates the benchmark score which in turn inflates the claimed credit.

TTYL
Richard

---

Click the Sig!

BOINC Wiki

The official linux boinc client will have a benchmark score that's a bit over half what the official windows client will have on the same hardware. The rosetta client runs about the same under either OS. The credit given is just the float benchmark multiplied by the CPU time. Thus, the machine running linux will get a bit over half the credit for the same work as compared to the windows machine.

That's bad, but it gets worse. Some people run so-called "optimized" boinc clients. These clients can give benchmark scores that are many times higher than the official clients. Note that the rosetta client runs at exactly the same speed no matter which boinc client is used. However the claimed credit will be many times higher, and rosetta currently grants whatever credit is claimed (as long as the WU completes successfully).

I may not understand your question, but it is possible that one of the systems ran the WU longer than the other say 4 hours verses 8. This would cause one sytem to claim more credit, but it cannot process as many WUs as the other system.

I did say that the first system reported running that WU for 8 hours, for which it claimed some 117 credits (about 14+ credits per hour). The second system reported running (using only one processor) that WU for a bit more than 4 hours, for which it claimed some 24.5 credits (about 6 credits per hour).

The RATIO of the reported running times is about 2:1. The RATIO of the claimed credits (for those runs) is more than 4:1. (The RATIO of the reported 'Measured floating point speeds' is about 3:2.)

Although I expected (for the same "CPU type") a running_time RATIO around 2:1 to result in a credits RATIO around 2:1, in this case the the credits RATIO went to TWICE AS BIG (around 4:1). If in the Windows system only one processor was working on this Workunit (and the *same* "CPU type" as mine was reported), I'm wondering: HOW COME my system is getting LESS THAN HALF AS MUCH work claimed per hour as that other system ?

--------

Can this SIGNIFICANT DIFFERENCE (more than twice as much credit/hour) be explained by the suggestion that an OPTIMIZED client was being used?

[If YES, let me suggest (! just jesting !) that simply by releasing "optimized" clients to __everyone__, the Rosetta project could bring about TWICE AS MUCH (credited work per elapsed time) being checked in by those currently using "plain" clients !! ]
.

After some playing around with a calculator, the actual equation seems to be:

credit = (float_benchmark + integer_benchmark) * CPU_seconds / (2 * 10 * 24 * 3600)

[If YES, let me suggest (! just jesting !) that simply by releasing "optimized" clients to __everyone__, the Rosetta project could bring about TWICE AS MUCH (credited work per elapsed time) being checked in by those currently using "plain" clients !! ]

Bingo! ;-)

TTYL
Richard

---

Click the Sig!

BOINC Wiki

Been reading the BOINC forums. Apparently for the SETI project, the server maintains a __table__ of the (averaged!) benchmark numbers as reported for each "CPU type". The server then uses that SINGLE internal *table value* when calculating the credit assigned for EVERY WU processed by that "CPU type", no matter which individual system reported that WU.

This seems to me to be much more "fair" than Rosetta's "blind acceptance" of the benchmark results reported by an individual system. In particular, the participant running an optimized client does NOT thereby receive a credits "bonus"; nor does someone running a Linux client thereby receive a credits "penalty" -- they are *all* credited based on that COMMON "average benchmark" for that 'CPU type'.

(The table values kept by the SETI server appear to be a "running average" -- as more recent benchmarks come in for that "CPU type", probably the same small percentage is both subtracted from the table value and added from the reported benchmark. That way, improvements in the efficiency of the client are __gradually__ "merged in" to the table values. I believe that reported benchmark values with excessive deviation from the norm are simply ignored.)
.

mikus, good idea, but I'm not sure it would translate well to Rosetta's model.

Couldn't one simply change the source of BOINC client to always report the fastest CPU available in the market (Athlon64?), even if the PC might have a Pentium-II/233 inside?

To avoid this, even with the averaged CPU benchmarks per CPU type, a BOINC project would have to waste CPU power donations, by giving out the very same WU to several PCs. Something which would mean MUCH less (1/2 or 1/3rd) science work being done, just for sake of credits.

Personally I would think that a viable method, a variation of what you suggested without reducing -50% (or worse) overall TeraFLOPS, would be the one used by F@H, i.e. assign a # of credits per WU based on an in-house benchmark for that particular type. e.g. running 10 models of HBLR_1.0 on "1di2" = 10 credits.

---

Best UFO Resources
Wikipedia R@h
How-To: Join Distributed Computing projects that benefit humanity