WU / Berk.eley....get a life...I`m annoyed. I never understood RAC, today I was pointed to the Wiki about it...

Crap..absolute unadulterated crap.

How can our average (for a day)be less than anything we`ve done in the past 7 days or so...

Are you trying BS baffles brains with your equations, have you a serious superiority complex which means you try to make things more complex than they are ?

Take 7 day`s results, divide by 7 this will give an average...no need to take the earths rotation and gravitational force into account or even the colour of your socks today.....

Stop talking bollox it don`t impress. #

A man takes 5 goes at darts his total score 500....his average per go 100....but according to you it`d be about 78...???? WTF ????

It`s a scoreboard for crying out loud.....Do you waste cycles working all that crap out or does the naughty student get to stay behind and do the work !

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

WU / Berk.eley

Just to clarify; RAC is a UCB invention, part of BOINC, not something WU came up with.

I have no idea why they made it so complicated; because of the timing issues, it's pretty meaningless at the project site. I'm showing 176.92 at the project, and 173.8 at BOINC Synergy, which is _probably_ more "correct", as they use a fixed date/time to do the calculation. All this really tells me is that I'm doing ABOUT half as much Rosetta as you are with your RAC of 343. (Trying to hit a goal on Einstein, very close now...) Regardless, you're correct in deducing that it's, um, flawed... :-)

Still, I can see that the current system (if it could be debugged a bit) would be "more stable" than just a moving 7-days average, and does have _some_ advantages; your method wouldn't work before someone had done 7 days work, for example, and if someone stopped work, would drop by 1/7 per day, be at 0 in a week. With EDF mode and long term debts, it can easily be more than a week before you "come back" to a project; RAC won't drop all that much in the interim, where a simple moving average would.

No, RAC isn't going to go away - what I _would_ like to see is for either BOINC or the stats sites to add a moving average IN ADDITION TO the current RAC.

---

I calculate 7-day averages here and if you go to the individual user page it has a 28 day average too..

I thought Zain did that too, but I might be mistaken.

Bok

---

Free-DC

Stats for all projects

Custom Stats

Recent :

Of, belonging to, or occurring at a time immediately before the present.


Average :

A number that typifies a set of numbers of which it is a function.



Not rocket science is it ?

Now being as the scoreboard shows 7 days one would accept that as recent, it also gives new members a reasonable RAC...

I hate nonsense that is invented for itself and is a waste, I know it`s crap every other cruncher I know knows it`s crap or just doesn`t understand it all....Fubar...

Thanks for that bok...

Bill if your machines work 6 days instead of 7 and do 700 wu`s your average per day is 100...simple mate, it`s a scoreboard that`s all no need for complicated Earths rotation equations. Who looks at the RAC...me or the scientist looking for a cure ? My method would simply give an average taken over a week...which people understand, THEY DO NOT UNDERSTAND THIS so therefore it`s worthless.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

I calculate 7-day averages

Hm... quite nice... says my 7-day avg is 236. I just looked at both BOINC Synergy and BOINCStats, and if it's done at either of those, I can find it.

Carl - at least what you're after IS available. Just not from the source that it should be. And I agree about the difficulty in understanding RAC. It's a mess, and even if the "design" were perfect, because of some known flaws, it flat doesn't "work". I'm just saying that a 7-day average is not "the" answer either. MORE choices to me is always better; give me both!

---

I agree Bill choice is nice, but I hate to see work for works sake when no one understands it anyway.

Now boks site show`s me a lot more than the other, I can see more of what`s been going on with my machines.

We`re crunchers Bill, though pretty good with PC`s we maybe....THIS

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

Where d(t) is the decay function, and t is the time (in seconds) since the last RAC recalculation.

d(t)=e^(-ln(2*t)/604800)

Means Fanny Adams to the AVERAGE .... whether recent or not.

A 7 day average may not be the answer but it is understandable !

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

Bok, you got yourself some converts....the Teddies will be using your stats I think from now on, much plainer to see, more info and well laid out.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

Yup, I second that!

---

Thanks,

I only just added the host stats for Rosetta, so there is still some work to do on that..

Personally I also use Zain's stats for some things I don't handle well :)

Bok

---

Free-DC

Stats for all projects

Custom Stats

All looks fine to me, we`re obliged

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

The problem with a moving average is that you would have to have a DB look-up to calculate an accurate value. And this every time you did an update. In a sense, that is the intent of RAC, but it does not rely on a look up at all. I do not understand the mathematics behind the formulation, it does work "somewhat", and therefore, as Bill said, unlikely to be changed. Especially as you would have to come up with a way that "costs" as little.

There have been discussions off and on about tweaking it a little, and there have been corrections to the basic formulation. Again, not being a mathematician I cannot say how good/bad these fixes are ...

A useful "wind guage", but not for making sweeping statements or pronouncements ...

---

In a sense, that is the intent of RAC, but it does not rely on a look up at all.

So Paul if it doesn`t require a look up how does it come by it`s figures ?

and how is this

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

easier ?

A wind guage or a wind-up ? A waste if you ask me, no one would use those figures as a base for anything unless a scientist knows different ?

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

carl, I think the look-up being 'less' in the case of Boinc-RAC.
It only looks at 'old RAC' and 'new credit' so only 2 lookups are needed. A 7 day moving average needs 7 lookups (each of the 6 past days and today).

But I agree it meaningless for what it tries to be.
If it was called 'Avearge Credit' I may let it off, but it is missrepresented by calling it recent.

There are projects I haven't sent or had a job from since well before christmas (i.e. not recently) still claim I have recent average credit, which is of course bollocks.


So what if your Proper-RAC reaches zero <hugh> just means you havn't sent any credit in recently and gives a 'real' indication of your recent credit.

Ok so projects would need to be able to set the time period in case they have long running jobs and no trickle feedback in between so that it is relevant to their timescales.

Although if you did calculation like

Initial
Add up 7 days (store as TotalForAve)
Calc RAC (TotalForAve/7)

Then
The next day TotalForAve = TotalForAve-Credit7DayAgo+CreditToday
Calc RAC (TotalForAve/7)

This would reduce the lookups.

---

Team mauisun.org

... how is this

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

easier ?

OK, it is easier to calculate as it does not need any stored stats apart from the figures you already have. That does not mean it is easy to use!

What is does is obvious to some scientists & medics who have seen the formulae for half lives (*) but totally unclear to anyone else.

The idea is that if you have a huge credit a long time ago it is as good for RAC as a small credit recently. If you suddenly stop crunching your RAC will drop to half its value in a certain length of time, then halve again in the same time, halve again in the same time again, and so on. Mathematically it never goes completely to zero - in practice it gets too small to show in the stats.

In my opinion there is an error in the formula used - I think it should be

RAC(new) = RAC(old) * d(t) + (new credit added).

This would rise at first proportionally to the work done, but level off at a certain level which would depend on the form of d(t). I think it is that factor of (1-d(t)) that makes the outcome so jittery, but I am writing this from memory so I may have got this wrong.

I agree that for most users 'credit in last 7 days' or 'credit in the last 28 days' would be easier to grasp, and I agree the projects should try to do this.

To avoid needing to keep the time each item was granted, another way to do this is to collect stats from midnight UTC sat/sun to midnight UTC sat/sun. Then the stats would be total so far; total last week; total this week so far. This simply needs a job to be run once a week on a timer to move the 'this week so far' figure to last week, and zero the this week so far figure.

regards,
River~~

----
(*) physicists use 'half life' to mean the time it takes for half the atoms in a radioactive sample to decay, medics use 'half life' to mean the time it takes a drug to lose half its concentration from the blood stream

---

Better or not, good or not. I doubt it is going to change. This is why I point people to the stat sites for the numbers as they are more reasonable.

The current formulation has one read and one update, anything that does more than that, or requires more than that is not going to fly ...

Honest guys, I used to do databases, if there was a way to do this I probably would have thought of it by now ...

To be honest, with all the trouble is causes, I almost wish they did not have it at all ...

---

River~~ I understand Half-Life well.....I`ve visited Black Mesa many times....

All I`m saying is it really means nothing to anyone, it is a job for jobs sake and a recent 7 average would be better widely received if anything has to be at all.

Stats hounds like to know where they are and who they`re going to overtake or how much more they will have to buy...not that a guy was crunching two years ago and still has a RAC of 1.3676860909.

It`s complex, say`s little of worth to the users who care and a waste of space.

---

Not all Czech`s bounce but I`d like to try with Barbar ;-)

Make no mistake This IS the TEDDIES TEAM.

River~~ I understand Half-Life well.....I`ve visited Black Mesa many times....

All I`m saying is it really means nothing to anyone, it is a job for jobs sake and a recent 7 average would be better widely received if anything has to be at all.

Stats hounds like to know where they are and who they`re going to overtake or how much more they will have to buy...not that a guy was crunching two years ago and still has a RAC of 1.3676860909.

It`s complex, say`s little of worth to the users who care and a waste of space.

If the look-ups are so complicated one has to wonder where stats site like Boinc Stats and FreeDC get the data to show daily credits for the last 30 days for any user on any project.
Kind of makes you go Hummm.

Just wondering

Regards
Phil

---

We Must look for intelligent life on other planets as,
it is becoming increasingly apparent we will not find any on our own.

If the look-ups are so complicated one has to wonder where stats site like Boinc Stats and FreeDC get the data to show daily credits for the last 30 days for any user on any project.
Kind of makes you go Hummm.

If I understand it correctly, the stats sites get a "once or twice a day" XML feed from each project, with the _current_ credits of each participant. (I've heard that the SETI XML takes over two hours to generate. It's publicly available if you want to look at it; I've never been that interested.) They then store this data in their own database, which makes it easy to subtract "current" from "yesterday" to get "amount done today". They do their own calculation of RAC and store that as well.

The stats sites run this process every "x" hours, and the data is static otherwise; the project sites are running in "real time" - every time the validator awards credit for a WU, the total credits and RAC for those hosts and participants and teams is recalculated. The projects _main_ focus is on the WUs; _that_ data is critical to them. The entire "hosts and participants and teams" area of the database is only there to satisfy the participants, and to attract new ones. The stats sites main focus is providing pretty graphs and data for their team members, etc., and they can do as much as they have the server capacity and interest in doing. The projects don't have staff that isn't already overloaded with _project_ issues, so "credit" issues come in a very distant second place.

---

To only add to what Bill said as I agree with all of it ...

The Stat sites also only store a limited amount of data, the last 30 days. The data is relatively static and the only activitiy is us looking up our pages. The project is dynamically updating the web pages, the work as it is issued, returned, validated, and so on ...

I will also point out that the processing of the input data file takes hours to update the stat site databases ...

I will also suggest that I did propose a more complex data architecture in the BOINC Beta but it was not felt that it was necessary at the time. More compelling was the argument that MySQL was not ready with all the needed features to support (easily) the proposal. The good news is that MySQL 5 does seem to have the core features needed, but this would require some significant work to create the ability to migrate a project from the MySQL 3/4 versions to the 5 with the underlying code changes ...

Again, a potentially significant amount of work for perhaps minimal gains in usability. A point I have tried to make in the past with people, usually unsuccessfully, is that the project is not about *US*, but, about getting work done for the project at minimal cost. Adding a moving average sounds great to us, but does nothing for the project except increase the cost of operation ...

---

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

---

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)