Hello,

I run 4 projects at the moment, one of which hardly ever has any data to process. I have all 4 projects set to priority 100 (25% of the available CPU time each).

However, one of the projects (Einstein actually) is eating up more than it's 25% share. I figured each project might jump to 33% each due to the lack of data in the 4th projects, but Einstein has gone through the roof. Check my stats for the last 24 hours:



More info here.

Anyone have any idea why this is happening?

Thanks in advance! :-)

---

FishSponge
http://distributed.mongeese.co.uk/

Also, if it makes a difference, i have two computers, one with 2 CPUs. That makes 3 CPUs total. I can't believe that makes a difference though, surely?

---

FishSponge
http://distributed.mongeese.co.uk/

G'day Richard

Not all projects grant credits equally. To give you an idea my P4 3GHz with HT recently averaged the following credits per hour.

Einstein	12.33946986
Malaria Control	5.970613795
Predictor	8.059973325
QMC	5.926754475
Seti	14.52466187
Simap	7.150868528
WCG	5.6497175
XtremLab	5.972476377

The other point to consider is that Einstein has a quorum of two as opposed to Seti which has a quorum of three. A quorum will reached quicker on Einstein than Seti (on average) so pending credits will be turned in to granted credits quicker on Einstein.

The bottom line is that you can't look at your credits as a measure of work share.

---

CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1

ah, thank you! that explains it :-)

---

FishSponge
http://distributed.mongeese.co.uk/

Another reason may be is that the resource share is honored in the long run. Weeks rather than days.

It really does even out in the long run.

---

Kathryn :o)

There is something wrong with Einstein workunits currently, and I can vouch for the discrephancy.

Einstein WU's are forcing EDF even with very small cache sizes. This really needs to be looked into.

---

EDF?

---

FishSponge
http://distributed.mongeese.co.uk/

There is something wrong with Einstein workunits currently, and I can vouch for the discrephancy.

Einstein WU's are forcing EDF even with very small cache sizes. This really needs to be looked into.

G'day Aaron

There are a number of things to look at, are you running a standard client? Were you running one of Akos' apps for s4? What is your result duration correction factor? Are you getting long or short wu's?

Any one or a combination could have a bearing on what you are seeing. Here's a quick example - if you have a pretty fast machine and were running one of Akos' apps your DCF would be quite low. This translates over to the new s5 wu's (slowly it corrects itself) so you would be drastically underestimating the time needed to complete these wu's. This would mean you would download way more than you should and this would put you into EDF.

---

CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1

Over the last few days, I've been noticing something odd, it's not just einstein WU's, boincsimap's wu's are doing this also. It's making me wonder if it's a problem with the 5.4.9 version of Boinc.

---