Richard: Exactly what I was looking for. No wonder it eluded me!
The formula is a bit different than I guessed. It will take me a bit to see if my hypothesized "slight penalty" really exists, but I suspect not. :(
I don't think it does: RAC depends on the absolute time the last calculation was done, not on the number of updates.
That unofficial Wiki entry had a spreadsheet example attached: I don't know whether the WayBack machine archived that, but I must have a copy somewhere - I had to salvage the url from question about wiki RAC spreadsheet. I may have to hunt around my discarded hard disk box...
Edit - Success, and with the same minor edit it runs in Excel 2003 too. Let me know if you'd like a copy (PM me your email address).
The formula is a bit different than I guessed. It will take me a bit to see if my hypothesized "slight penalty" really exists, but I suspect not. :(
I don't think it does: RAC depends on the absolute time the last calculation was done, not on the number of updates.
Humm.. to be a bit pedantic, but also practical.
RAC systematically discounts older credits--based on the time they are credited.
So--if you want a temporary spike well above your actual average level, the trick is to pick an application for which other participants typically respond long before the deadline (and an application with a nice long deadline), pack your queue to the gills to the maximum you can process within deadline, in as short a period as feasible, and without returning any results.
Then you cut off communication, processing full time but returning nothing, until just before deadline. Then report all, watch the great majority of the results get immediate credit, and celebrate as your RAC (temporarily) surges appreciably above your actual rate of production.
Of course the decay law applies to the slug of suddenly reported work, so the spike will be devalued a factor of two per week, just as with an already reported work.
Stan, I understand this does not speak directly to your original point as stated, but perhaps pondering the particulars will add a bit of RAC understanding to some.
Also this is not actually hypothetical. A person representing himself as an Intel marketing person actually did almost exactly this more than once over at SETI years ago. I (a former Intel employee) despised him for it. He was counting on people not understanding how RAC works to be deluded into thinking his configuration under test was faster than it really was.
Also this is not actually hypothetical. A person representing himself as an Intel marketing person actually did almost exactly this more than once over at SETI years ago. I (a former Intel employee) despised him for it. He was counting on people not understanding how RAC works to be deluded into thinking his configuration under test was faster than it really was.
Yes, I remember the events in question. He was promoting one particular CPU/motherboard combination (which incidentally seems to have disappear without trace, along with the marketeer), and claimed that it could outperform the GPUs which were just beginning to come into use at the time. When I went out and bought a real GPU, and started posting verifiable statistics, he went quiet. Thank goodness. And we don't even need to mention the vapourware...
Richard: Exactly what I was looking for. No wonder it eluded me!
The formula is a bit different than I guessed. It will take me a bit to see if my hypothesized "slight penalty" really exists, but I suspect not. :(
I don't think it does: RAC depends on the absolute time the last calculation was done, not on the number of updates. ...
Right! However, by grouping the credits differently, the "absolute time" is applied to all in a group, and so the decay for them is delayed. To see whether this actually affects the calculation I must look at a few examples. My intuition doesn't work well with exponential functions! I hoped to do it Wednesday, but my day was spent trekking out of town to get a ring designed for my Bride. The session was fun, and the result should be "one of a kind." After putting up with me for 53 years, she deserves it! :) (Needless to say, it will affect my discretionary hardware spending, as it could buy a nice workstation level cruncher!) And Thursday won't be much better. But maybe the predicted rain will eliminate my obligation to spend time manicuring the grass.
Thanks for the "war stories." I'm sure that the hacker inclination came out in several individuals. That someone would try to make some brand of gear look better than it really was is worse than playful hacking though. :(
Richard: Exactly what I was looking for. No wonder it eluded me!
The formula is a bit different than I guessed. It will take me a bit to see if my hypothesized "slight penalty" really exists, but I suspect not. :(
I don't think it does: RAC depends on the absolute time the last calculation was done, not on the number of updates. ...
Right! However, by grouping the credits differently, the "absolute time" is applied to all in a group, and so the decay for them is delayed. To see whether this actually affects the calculation I must look at a few examples. My intuition doesn't work well with exponential functions! I hoped to do it Wednesday, but my day was spent trekking out of town to get a ring designed for my Bride. The session was fun, and the result should be "one of a kind." After putting up with me for 53 years, she deserves it! :) (Needless to say, it will affect my discretionary hardware spending, as it could buy a nice workstation level cruncher!) And Thursday won't be much better. But maybe the predicted rain will eliminate my obligation to spend time manicuring the grass.
Thanks for the "war stories." I'm sure that the hacker inclination came out in several individuals. That someone would try to make some brand of gear look better than it really was is worse than playful hacking though. :(
The rains came! If I have interpreted the formula in the archived WIKI correctly, there is, indeed, no penalty for updating too frequently.
There are some issues with the formula when applied exactly as written in the WIKI, and the example spreadsheet does not expose the problem because it computes daily using the new credit for one day. If credit is accumulated for 2 days before recalculation, the resulting RAC is much larger than if the RAC is recalculated daily. Using the average daily new credit instead of the total new credit produces consistent results.
Here are the relevant text from the WIKI:
Quote:
Each time new Credit granted, the following function is used to update the Recent Average Credit of the Computer, Participant, or Team:
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 Recent Average Credit recalculation.
d(t) = e^(-ln(2)*t / 604800)
To simplify matters, assume daily production of 100 credit units, computed first for t=86400 seconds (1 day) and then for t=172800 (2 days).
When calculating for 1 day intervals, the decay function value is (rounded) 0.9057 for each day and is applied to new credit of 100 for each day. For 2 day interval, it is 0.8203 and applied to the total new credit of 200. (From there, the calculations are easy.)
The explanation of the issue is that the formula (as described in the WIKI) adds a decayed average (old RAC) and a decayed total (new credit) ... "mixing apples and oranges". Restating it to add a decayed average (old RAC) and a decayed average (of new credit) resolves the issue, and RAC's track properly independent of recalculation frequency.
I have not examined the case when daily production varies, e.g. 90 credits for the first day and 110 credits for the next and 100 for the third day. Is the new RAC after 3 days the same whether recalculated once each day versus recalculating only after 3 days? Probably not.
I looked into a similar set of questions for Climate Prediction (CPDN) several years ago. They have huge (multi-month) tasks, so they report 'progress so far' via a mechanism called a "trickle": for the purposes of credit and RAC they calculate new values daily ab initio for each trickle stored in their database - actually only from the latest trickle received for each task.
Their 'Credit' is a fixed numeric value for each 'timestep' performed by the task (a measure of progress) - the current timestep value is reported in the trickle. Their 'Weight' (our RAC) is the same value, decayed by the RAC formula over the time interval since the trickle was received. It's a different way of doing things, but I'm pretty sure it ends up in the same place.
The formulae are:
In CPDN's server script
...
SELECT t.resultid,
0.10 * sum(exp(-(abs(unix_timestamp()-t.trickledate)*0.69314718/604800.0))) * m.trickle_timestep * m.credit_per_timestep weight,
max((t.phase-1)*m.timestep + t.timestep) * m.credit_per_timestep total_credit
FROM cpdnexpt.trickle t, cpdnexpt.model m, result r
...
or, as I transleted it into the form of SQL used by Microsoft Access,
Well that explains how someone who was 49 K (total RAC 485K) behind me on the RAC all of a sudden jumped 50K and passed me (total RAC 530K) while only returning 44000 total productivity today...
Yeah, it will change tomorrow but it definitely show how someone can milk the system.
The best description was probably in the old Unofficial BOINC Wiki. That's been allowed to lapse, and the domain name has been taken over by a squatter, but it can still be found in the Wayback Machine archive.
I would like to correct an error on that old website. The formula should say rate instead of credit. The following is correct... RAC(new) = RAC(old)*d(t) + (1-d(t))*rate(new)
d(t) = e^(-ln(2)*t / 604800)
where rate(new) = credit(new) / t * secondsPerDay is the credit per day since last RAC update, and t is the time since last RAC update in seconds. The formula on the old website makes no sense.
mikey & Richard: Thank you,
)
mikey & Richard: Thank you, gents!
Richard: Exactly what I was looking for. No wonder it eluded me!
The formula is a bit different than I guessed. It will take me a bit to see if my hypothesized "slight penalty" really exists, but I suspect not. :(
Stan
RE: mikey & Richard: Thank
)
I don't think it does: RAC depends on the absolute time the last calculation was done, not on the number of updates.
That unofficial Wiki entry had a spreadsheet example attached: I don't know whether the WayBack machine archived that, but I must have a copy somewhere - I had to salvage the url from question about wiki RAC spreadsheet. I may have to hunt around my discarded hard disk box...
Edit - Success, and with the same minor edit it runs in Excel 2003 too. Let me know if you'd like a copy (PM me your email address).
It also depends on your
)
It also depends on your *Pending credit*
I see this happen once in a while where my RAC drops only because of the large amount of finished tasks on the *Pending credit* list.
(such as the 151 I have right now and this has been going on for the last couple weeks for me and I imagine others that do lots of GPU tasks)
RE: RE: The formula is a
)
Humm.. to be a bit pedantic, but also practical.
RAC systematically discounts older credits--based on the time they are credited.
So--if you want a temporary spike well above your actual average level, the trick is to pick an application for which other participants typically respond long before the deadline (and an application with a nice long deadline), pack your queue to the gills to the maximum you can process within deadline, in as short a period as feasible, and without returning any results.
Then you cut off communication, processing full time but returning nothing, until just before deadline. Then report all, watch the great majority of the results get immediate credit, and celebrate as your RAC (temporarily) surges appreciably above your actual rate of production.
Of course the decay law applies to the slug of suddenly reported work, so the spike will be devalued a factor of two per week, just as with an already reported work.
Stan, I understand this does not speak directly to your original point as stated, but perhaps pondering the particulars will add a bit of RAC understanding to some.
Also this is not actually hypothetical. A person representing himself as an Intel marketing person actually did almost exactly this more than once over at SETI years ago. I (a former Intel employee) despised him for it. He was counting on people not understanding how RAC works to be deluded into thinking his configuration under test was faster than it really was.
RE: Also this is not
)
Yes, I remember the events in question. He was promoting one particular CPU/motherboard combination (which incidentally seems to have disappear without trace, along with the marketeer), and claimed that it could outperform the GPUs which were just beginning to come into use at the time. When I went out and bought a real GPU, and started posting verifiable statistics, he went quiet. Thank goodness. And we don't even need to mention the vapourware...
RE: RE: mikey & Richard:
)
Right! However, by grouping the credits differently, the "absolute time" is applied to all in a group, and so the decay for them is delayed. To see whether this actually affects the calculation I must look at a few examples. My intuition doesn't work well with exponential functions! I hoped to do it Wednesday, but my day was spent trekking out of town to get a ring designed for my Bride. The session was fun, and the result should be "one of a kind." After putting up with me for 53 years, she deserves it! :) (Needless to say, it will affect my discretionary hardware spending, as it could buy a nice workstation level cruncher!) And Thursday won't be much better. But maybe the predicted rain will eliminate my obligation to spend time manicuring the grass.
Thanks for the "war stories." I'm sure that the hacker inclination came out in several individuals. That someone would try to make some brand of gear look better than it really was is worse than playful hacking though. :(
Stan
RE: RE: RE: mikey &
)
The rains came! If I have interpreted the formula in the archived WIKI correctly, there is, indeed, no penalty for updating too frequently.
There are some issues with the formula when applied exactly as written in the WIKI, and the example spreadsheet does not expose the problem because it computes daily using the new credit for one day. If credit is accumulated for 2 days before recalculation, the resulting RAC is much larger than if the RAC is recalculated daily. Using the average daily new credit instead of the total new credit produces consistent results.
Here are the relevant text from the WIKI:
To simplify matters, assume daily production of 100 credit units, computed first for t=86400 seconds (1 day) and then for t=172800 (2 days).
When calculating for 1 day intervals, the decay function value is (rounded) 0.9057 for each day and is applied to new credit of 100 for each day. For 2 day interval, it is 0.8203 and applied to the total new credit of 200. (From there, the calculations are easy.)
The explanation of the issue is that the formula (as described in the WIKI) adds a decayed average (old RAC) and a decayed total (new credit) ... "mixing apples and oranges". Restating it to add a decayed average (old RAC) and a decayed average (of new credit) resolves the issue, and RAC's track properly independent of recalculation frequency.
I have not examined the case when daily production varies, e.g. 90 credits for the first day and 110 credits for the next and 100 for the third day. Is the new RAC after 3 days the same whether recalculated once each day versus recalculating only after 3 days? Probably not.
Stan
I looked into a similar set
)
I looked into a similar set of questions for Climate Prediction (CPDN) several years ago. They have huge (multi-month) tasks, so they report 'progress so far' via a mechanism called a "trickle": for the purposes of credit and RAC they calculate new values daily ab initio for each trickle stored in their database - actually only from the latest trickle received for each task.
Their 'Credit' is a fixed numeric value for each 'timestep' performed by the task (a measure of progress) - the current timestep value is reported in the trickle. Their 'Weight' (our RAC) is the same value, decayed by the RAC formula over the time interval since the trickle was received. It's a different way of doing things, but I'm pretty sure it ends up in the same place.
The formulae are:
In CPDN's server script
... SELECT t.resultid, 0.10 * sum(exp(-(abs(unix_timestamp()-t.trickledate)*0.69314718/604800.0))) * m.trickle_timestep * m.credit_per_timestep weight, max((t.phase-1)*m.timestep + t.timestep) * m.credit_per_timestep total_credit FROM cpdnexpt.trickle t, cpdnexpt.model m, result r ...or, as I transleted it into the form of SQL used by Microsoft Access,
weight: Sum(0.1*(Exp(-(Abs(DateDiff("s",Now(),[trickledate]))*0.69314718/604800)))*[trickle_timestep]*[credit_per_timestep])total_credit: Max((([Phase]-1)*[model].[timestep]+[trickle].[timestep])*[credit_per_timestep])
That's not necessarily any clearer, but it seems to work: the database allows you to see RAC decaying in real time as you refresh the query.
Well that explains how
)
Well that explains how someone who was 49 K (total RAC 485K) behind me on the RAC all of a sudden jumped 50K and passed me (total RAC 530K) while only returning 44000 total productivity today...
Yeah, it will change tomorrow but it definitely show how someone can milk the system.
Richard Haselgrove
)
I would like to correct an error on that old website. The formula should say rate instead of credit. The following is correct...
RAC(new) = RAC(old)*d(t) + (1-d(t))*rate(new)
d(t) = e^(-ln(2)*t / 604800)
where rate(new) = credit(new) / t * secondsPerDay is the credit per day since last RAC update, and t is the time since last RAC update in seconds. The formula on the old website makes no sense.
BOINC's code does things correctly: https://github.com/BOINC/boinc/blob/827d4c77d5b5ed704b793cb0466528b18445cb3e/lib/util.cpp#L237