Too short crunching time, less and unequal credit


advanced search

Message boards : Number crunching : Too short crunching time, less and unequal credit

Reply to this thread
Subscribe to this thread
Sort
AuthorMessage
M. Rossbach User profile image
private message
Joined: Oct 20, 2010
Posts: 1
ID: 27239
Credit: 106,290
RAC: 47
Message 2921 - Posted 28 Mar 2014 18:57:13 UTC
Last modified: 28 Mar 2014 19:02:35 UTC

First I want to stay out that I am usually not the guy who moans about less credit granting projects. And -whatever I state out below- will not diminish my commitment in the leiden classical project.
In my opinion the Leiden project is very mean with the granting credits. For example I picked up a result of two computers; the A6 is mine but I also have an quite equal FX-8150 as the other volunteer in this example has.
A FX-8120 with a floating point speed of 2618.62 million operations per second (megaflops) and
8314.87 million integer operations per sec (mips) needed 8337.61 seconds and claimed 51.97 credits
My A6-3420M with 1455.91 megaflops and 3913.09 mips needed 10355.21 seconds and claimed 32.17 credits.
Outcome: For each of them 32.17 credits were granted. Questions:
1) Why wasn’t the FX-8120 much faster than my mobile A6 ? I think both of us didn’t play a hardware intensive 3D-game in parallel but only do some office work or watching a video in the background while crunching
2) Why is it always the same that the less claimed credit is granted – some other projects are going to grand the higher one or even grand a ‘goody’ in top the higher one
3) And in general the claimed / granted credit is quite less. If I compare this with other projects who use ‘single-cpu work units’ (and without GPU of cause) e.g. POEM I get 70 credits for 8763.54 seconds CPU runtime / crunching time. By the way POEM is not one the ‘credit boosters’ like primegrid, collatz conjuctur, milkyway or similar.
4) How is the ‘claimed credit’ calculated – seems not to have something to do with the capability of the CPU and the predicted GFLOPs of the work unit but more like a random number between 30 and 70, isn’t it?
Another point of critics is the very short time period you have to calculate (crunch) a work unit. I show sympathy for the students / projects and their wish for fast results, but I think 4 days is quite short if you don’t have a machine in 24/7 operation mode. If you only let your PC crunch 1-2 hours a day (in the evening after work) you can’t effort a day off without risking a delay and zero credit at the end. What do you guys out there and the project admin’s think about longer grace period of e.g. a whole week?
Overall I think Leiden could have much more participants with other rules in this topic(s).
Wish you all a good progress in all your projects and a nice crunching time,
Michael

m.somers User profile image
Forum moderator
Project administrator
Project developer
Project tester
Volunteer developer
Volunteer tester
Project scientist
Avatar
private message
Joined: Nov 14, 2005
Posts: 662
ID: 1
Credit: 1,417,572
RAC: 2
Message 2922 - Posted 1 Apr 2014 7:45:53 UTC

Hi,

I'm sorry you have issues with the short dead-lines and the way BOINC grants credit.

The way I understand credit granting works in BOINC is that when two workunits are sent out (homogeneous redundancy) and computed by slightly different but binary compatible hosts, both hosts request a certain amount of credit based on a whetstone benchmark performed by the BOINC client during install (the server also specifies a certain amount of FLOPS to a workunit indep of the hosts involved, but this is only used in scheduling algorithms on the client). The BOINC server then grants the lowest amount of credit these hosts report to BOTH hosts. So statistically this averages out again. Sometimes you are shot, sometimes you are lucky and get more.

In your particular case I think that your A6 did the whetstone benchmark and somehow was 'graded' much slower; despite the Classical code performing not that much worse compared to the FX. We conclude thus (again) that a whetstone benchmark is perhaps not the most representative measure for the actual scientific codes people run?

None the less; this is something embedded deep in the architecture of the BOINC client and therefore as a simple project admin, somewhat out of my reach to change. Fixing the amount of credit is also not an option as some calculations are submitted by students and we cannot know how much time / credit you need to associate with them a priory. We estimate the FLOPS and use the whetstone benchmark mechanism as best as we can.

m.
____________
M.F. Somers

Reply to this thread

Message boards : Number crunching : Too short crunching time, less and unequal credit



Return to Leiden Classical main page


Copyright © 2017 Leiden University - Leiden Institute of Chemistry - Theoretical Chemistry Department