EDIT ....Kitties are good hunters.

Need a mice@home project just for them... :-)

Typical, I just get another Quad G0 online, work dries up and caches are all but empty... This has happened every time I put a new machine online! :-(
So off to Einstein for a while...

Fairness:

If a fast system is changed abruptly from the default cache settings to large cache settings, it requests so much work that for several days it will be sent the maximum of 100 tasks per CPU. Any of those above what the system can crunch in a day is work being denied to another host which may be nearly out of work. Adjusting cache upward by 0.5 days each day would be much more polite.

Having a large cache means more "In progress" results which are just sitting there both on the host and in the project BOINC database. Database accesses are already a problem, if everybody went to large cache settings the database would really bog down.

larger RAC:

A large cache will tend to make work with shorter deadlines run first. Fast systems tend to earn more credit/time for the VHAR (Very High Angle Range) WUs with the shortest deadline of 8.68 days. So RAC will rise initially, but fall again when the host does the work with longer deadlines. Boosting cache for this purpose gives a temporary feel-good effect at most. Over longer periods the average RAC will be the same unless a small cache causes the host to go idle.

                                                                Joe

It's all fair, because everybody is treated equally. If the kitties get screwed, everybody else gets screwed also. That's why I don't waste too much time complaining about the status quo. I do like to mention when things are not working up to par, but it is what it is.
I'll crunch my cache 'till it is gone, then the kitties will hunt for something else to chew on if necessary.


EDIT ....Kitties are good hunters.

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

BUT, I do think Boinc should limit your max cache to 5 days.

It's just about that - when running optimized apps! ;-)
Just about enough to survive the major outages here @Seti.

Kiva

---

Greetings from Norway

Crunch3er & AK-V8 Inside

Fairness:

If a fast system is changed abruptly from the default cache settings to large cache settings, it requests so much work that for several days it will be sent the maximum of 100 tasks per CPU. Any of those above what the system can crunch in a day is work being denied to another host which may be nearly out of work. Adjusting cache upward by 0.5 days each day would be much more polite.

Having a large cache means more "In progress" results which are just sitting there both on the host and in the project BOINC database. Database accesses are already a problem, if everybody went to large cache settings the database would really bog down.

larger RAC:

A large cache will tend to make work with shorter deadlines run first. Fast systems tend to earn more credit/time for the VHAR (Very High Angle Range) WUs with the shortest deadline of 8.68 days. So RAC will rise initially, but fall again when the host does the work with longer deadlines. Boosting cache for this purpose gives a temporary feel-good effect at most. Over longer periods the average RAC will be the same unless a small cache causes the host to go idle.

                                                                Joe

RAC: 11685.4
Week Average: 13494.4

My RAC never SEEMS to get equal my week average credit. One would think it would over a period of extended project up time. I've been increasing my cache and it seems to help.

Your RAC will never equal your calculated average output because there's an exponential decay factor builtin to the RAC calculation.

Alinator

Ooooohhhh, I am decaying...........exponentially. LOL.

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

RAC: 11685.4
Week Average: 13494.4

My RAC never SEEMS to get equal my week average credit. One would think it would over a period of extended project up time. I've been increasing my cache and it seems to help.

Your RAC will never equal your calculated average output because there's an exponential decay factor builtin to the RAC calculation.

Alinator

Mutt, how do you figure, someone having a large cache of units is stopping other peoples RAC from climbing? Over a period of time, RAC equals out. When the units are waiting for validation your RAC wil be lower, but then as they are validated you RAC will be higher than average. you moaning over nothing.

As you've managed to maintain a RAC of over 11,000 I really don't see why your so upset. I thought Seti was about finding E.T not RAC.

RAC: 11685.4
Week Average: 13494.4

My RAC never SEEMS to get equal my week average credit. One would think it would over a period of extended project up time. I've been increasing my cache and it seems to help.

---

I’ve noticed that if you have 12 days of stored work units, for example, your RAC will be higher. I think this is because the work unit has been “aged” and by the time you turn it in your result the result has already been received from another computer and you get “instant” credit.

Do I think this is fair, NO… Will I use it…

Well it may seem that way when the project is having trouble keeping a workstream going, but the fact of the matter is when you reach equilibrium with your pendings they don't have any net effect on you RAC either way.

One thing is for sure, running out of work on a host will make it tank.

Alinator

How the hell is having a large cache unfair?

With all the ups and downs were having at the minute it seems like common sense to have one.

Why are you so bitter?

why are you so defensive dude!!!

I'm just pointing out if you want to increase your RAC this is the way to do it, and it is currently within the rules. If you ever looked at how RAC is calculated you will see and it also will keep others RAC Lower...



BUT, I do think Boinc should limit your max cache to 5 days.

---

I’ve noticed that if you have 12 days of stored work units, for example, your RAC will be higher. I think this is because the work unit has been “aged” and by the time you turn it in your result the result has already been received from another computer and you get “instant” credit.

Do I think this is fair, NO… Will I use it…

Mutt....methinks you have better things to do than post your musings on Seti. Please do continure to crunch, but save your thoughts on what's 'fair' for yourself. It's not important for your work to return 'instant credit'. Anything that goes into your pending credits is yours once validated. It may take a few days or a few weeks. Some users have slow computers, some have a large cache. Either way, the work gets done and you will not be cheated out of your credits due.

And the kitties say.......'Sit tight.........and get over it.'

---

"Learn from yesterday. Live for today. Hope for tomorrow." Albert Einstein
"With cats." kittyman

How the hell is having a large cache unfair?

With all the ups and downs were having at the minute it seems like common sense to have one.

Why are you so bitter?

From the looks of it, the "majority" of users return work within 3 days, so your pendings should be pretty much accounted for 3 days later(I.E you have 3 days banked away). Though setting a large cache will pretty much assure you're the last to return, thereby getting your validations instantly, but then you left them on hand for longer, and are making your co-cruncher wait longer.

I have been getting paired up with a lot those types lately. My Pendings are almost 3 times my RAC.

---

Calm Chaos Forum...Join Calm Chaos Now

I’ve noticed that if you have 12 days of stored work units, for example, your RAC will be higher. I think this is because the work unit has been “aged” and by the time you turn it in your result the result has already been received from another computer and you get “instant” credit.

Do I think this is fair, NO… Will I use it…

---