Just to add to this, Everyone is correct. I'm also a part time DBA (Oracle & DB2) and I totally understand the reasons for not doing multiple lookups and how boinc stores the data. RAC in this case is the only way to do this 'cheaply'. I think it's also why boinc actively encourages 3rd party stats.

Many years ago when I first started writing stats, I used to have a table which was keyed on name + date, this rapidly got very large which is not really a problem as disk is cheap.

However the displaying last 30 days of data became very cumbersome as it would involve at least 30 selects.

I made a decision after asking for input to only store the last 30 days of data. What I additionally did was to store it all in a single row, which makes the updates slightly more expensive, but the display of the data is then much less costly.. including finding averages, last x days etc etc.

FYI, parsing the XML stats and updating all the info, calculating movements/milestones etc for R@H takes roughly 12 mins on my stats box. On a Dual xeon 3.6 I have at home it takes only 7 mins. The scripts are all perl based and a mysql backend.

Bok

---

Free-DC

Stats for all projects

Custom Stats

I can come across somewhat abrasive when I`m trying to get at something.

No problem, so can I - you should see some of the things Ive written!

And I am glad you asked, because for every person who is willing to make a posting saying that X is daft, there are 100 out there thinking it - and about 20 of them will be using words you kept away from in your post.

Short answer is that not many people like RAC, but we are stuck with it as a compromise between what we'd really like and what can be made to go fast enough.

Thanks for the question.
R~~

---

Guy`s, guy`s ease back now, my lads asked me in a nice sort of way to pull out. I can come across somewhat abrasive when I`m trying to get at something.

Neither thought you were abrasive, ot that you should pull out. If you don't understand, well, that is what *I* live for ...

The only bad part is that we had to tell you that we cannot have what we want. I would much prefer a moving average myself (though I would want a 30-day) ... :)

---

Must be time again to mention the use of "hobbyist" databases (MySQL) instead of real ones (Informix, et al).

As soon as you agree to pay the licence cost for all projects that want to use BOINC, I am sure they will all be willing to move to Oracle. Until then, MySQL is free, and does the job ...

Old phrase comes to mind - "You get what you pay for."

Did anyone ASK IBM if they would donate or seriously subsidize something like Informix Server Express? (I wouldn't ask Oracle for the time of day - probably come back null anyway)

I'll still stand behind my opinion - REAL databases need REAL database engines.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Speaking from experience, I wouldn't give Informix the time of day. Mysql doesn't do some of the things Oracle/DB2 do, but if it's set up correctly, for what Boinc needs, it is just as fast.

Benchmark figures for Oracle and DB2 are almost always done with cutting edge raid arrays, more often than not using fibre connections whereas mysql benchmarks are usually on either single channel or perhaps a simple RAID 5.

As was mentioned earlier in the thread, databases are usually constrained by IO to the disk (or they are designed very badly). Lots of memory helps with cacheing (along with a properly tuned DB to make use of it) but this is exactly the same as enterprise databases. I've seen Oracle databases which perform horribly on 8-way sun machines with 16Gb ram because the SGA has only been allocated 512Mb.

Bok

---

Free-DC

Stats for all projects

Custom Stats

In my opinion it would be much simpler to just change the name from
RAC - Recent Average Credit
to
AC - Average Credit

(or maybe a soon to be Average Points)

A) as it is not recent,
proof, I have a team mate that hasn't returned a job in over a month, still has 2000+ RAC

I also know there is discussion of name changes, so may as well add another one. It it not labeled correctly at the moment.

Unfortunatly all the name changes give Paul more work to do :(

---

Team mauisun.org

A) as it is not recent,
proof, I have a team mate that hasn't returned a job in over a month, still has 2000+ RAC

As has already been mentioned, RAC is normally only updated when new credit is given, to not give unneccessary load on projects database.

A project can choose to update RAC for all users whenever they wants, but only a few projects does this, and Rosetta@home is not one of them.

The projects relies on the stats-websites decays RAC, but apparently not all bothers to do this as they should.


So, looking on Rosetta@home's stats, FatJack that haven't returned anything keeps his RAC as of last time returned anything of 2607.86

Looking on BoincStats he's showing-up with RAC 2608, clearly showing BoincStats haven't bothered re-calculating RAC as they should have been doing. This is the same stats-site that managed to get an increase in #active users in LHC@home at a time no-one was getting any work or credit... :roll-eyes:

But, looking on BoincSynergy he's suddenly showing-up with RAC of 68.50, showing RAC is dropping over time as it should be doing.

Unfortunatly all the name changes give Paul more work to do :(

Don't mind the work ... I can still do changes like this because it is mechanical and does not require the heavy effort of new material. That is hard ...

The whole reason I have been trying to get a community wide documentation resource so we can update all documentation at one whack ... one of the nice things about the Wiki is it gives nice page reference lists so you can trace back usages ...

---

If this is usefull for the Wiki too, please use it:

This is based on my understanding of RAC and I hope it is close to the truth. :-)

-------------------------------------

RAC is an "infinit sum" like this:

1 + 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 + 1/128...

If we make a simple program that calculates this (in Basic)

10 x_now = 0

20 X_Fraction = 1

30 x_now = x_now + x_Fraction

40 x_Fraction = X_Fraction/2

50 goto 30

Each time the loop 30-40-50 runs a smaler fraction is added, but in each loop you only add 2 numbers.

X_now holds the values (a sum) of every previous calculation.

This is how the RAC works.


RAC(new)=RAC(old)*d(t)+ (1-d(t))*credit(new)

This part "RAC(old)*d(t)" holds the result of all previous calculations of the RAC back to the very first RAc given based on the first credit.

The value of the RAC(old) is multiplicated by a value "d(t)" less than 0.5.

If RAC(old) is long ago "d(t)" will be very small (like .012).

"(1-d(t))*credit(new)" is the amount of credit added from the new credit, to RAC.

As you can see it is multiplicated by "(1-d(t))". In the above example the value will be:

(1- d(t)) = (1-.012)= .988

This means that the new credit will allmost exclusivly decided by the size of the new Credit.

Like this:

RAC(new)=RAC(old)*d(t)+ (1-d(t))*credit(new)

RAC(new)=RAC(old)*.012+ .988*credit(new)

If, on the other hand, the last credit was very recent, the d(t) numbers would be different and the numbers could end up like this(I guess):


RAC(new)=RAC(old)*d(t)+ (1-d(t))*credit(new)

RAC(new)=RAC(old)*.488+ .512*credit(new)

-------------------------------------


I hope this makes RAC more easily understood.

If I am very wrong, please correct me!

A) as it is not recent,
proof, I have a team mate that hasn't returned a job in over a month, still has 2000+ RAC

As has already been mentioned, RAC is normally only updated when new credit is given, to not give unneccessary load on projects database.

A project can choose to update RAC for all users whenever they wants, but only a few projects does this, and Rosetta@home is not one of them.

The projects relies on the stats-websites decays RAC, but apparently not all bothers to do this as they should.


So, looking on Rosetta@home's stats, FatJack that haven't returned anything keeps his RAC as of last time returned anything of 2607.86

Looking on BoincStats he's showing-up with RAC 2608, clearly showing BoincStats haven't bothered re-calculating RAC as they should have been doing. This is the same stats-site that managed to get an increase in #active users in LHC@home at a time no-one was getting any work or credit... :roll-eyes:

But, looking on BoincSynergy he's suddenly showing-up with RAC of 68.50, showing RAC is dropping over time as it should be doing.

Hence why I was suggesting the dropping of the R in RAC ;-) (proof just there for context)

Thanks for the other tid bits of info :-)

---

Team mauisun.org