| Author | Message |
|---|
|
|
|
Two months ago 4300 RAC points would put a machine in the top ten. Now it won\'t even get you into the top 100. Glancing around at the tasks of the top 100 machines it looks like they\'re mostly running HADAM3P\'s. |
|
|
 mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Hi Belfry
HadAM3Ps do receive rather more credits per hour than the other models. However, the slightly higher credit level has to compensate for the massive uploads and downloads and the fact that if you run several of them on a multicore computer they slow each other down. If I run two together on my Core2Duo 6600 I get no more credit per hour than when running other model types. They seem to swap a lot of memory and contend for this resource. So members running these should ideally check what they download and run in tandem.
We\'ve seen a case of spectacularly low running speed with HadAM3P where a member with a 6-core hyperthreaded computer is (or certainly was) running 6 of them together.
Other model types do also vary in speed according to the computer and OS. It\'s a good idea for everybody to keep an eye on the forum News thread where we warn about potential problems.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
|
It looks like 2~3x the RAC of the \"legacy\" apps. Here are some machines that look like they\'re honest and crunching 24/7:
2P/quad-core Xeon, XPsp3 running legacy apps: 539345
Core 2 Duo, XPsp3 running HADAM3P\'s: 950312. Note how this one is knocking the Xeon out.
Core 2 Duo, XPsp2 running HADAM3P\'s: 957143. This machine has only been crunching for twenty days and is also knocking the Xeon out. Its total credit is 33211 (1660 credit per day) and RAC is 4269!
In a couple months every top 1000 machine will be exclusively crunching HADAM3P\'s. It doesn\'t much matter to me, I\'ll still be poking along with my old machine. |
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Hi again
I\'ve looked at those computers. The two C2Duos are faster than mine.
Anonymous\'s computer is by my calculations getting about 33 credits/hour for its HadAM3Ps. When it ran Mid-Holocenes it got about 34 credits/hour for them. It would probably run the HadAM3Ps faster if it didn\'t have a full load of them.
The first C2Duo you link to is getting about 31 credits/hour for its HadAM3Ps. For a fast machine that isn\'t much more than one would expect for other model types. One of its Mid-Holocenes got 33.7 credits/hour and its HadAM got 29.3.
The real comparison between models must be by credits/hour.
Members have commented recently that our RAC on CPDN is artificially high at the moment. This seems to be because on several days our credits haven\'t been exported to the stats sites. When 2 or 3 days\' worth of credits are exported all together it pushes the RAC up abnormally. We\'ll have to keep an eye on this to see whether our RAC does return to normal after a few weeks as it should if the CPDN server behaves for Milo.
My own RAC is showing as about 1880. But my slower computer has earned almost nothing for the last 10 days because it\'s been crunching for another project and CPDN Beta tasks which generated little or no credit. My C2D has earned less than usual because until about 3 days ago it was also testing Beta models that didn\'t trickle ie no credits. The most my two computers can earn per day together is about 1300 - 1350 credits.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
|
Actually this thread is mistitled, it should read \"HADAM3P\'s too much RAC weight?\".
The RAC calculation for HADAM3P is as accurate as an Enron accountant.
Here\'s two twenty-day-old machines (manually searched them out, not a lot going on today): An eight-core Xeon and the last Core 2 Duo example in my previous post. If you scroll to the bottom of the pages you can see how many credits each machine has produced in the last twenty days. The Xeon produces around 3200 per day, The Core 2 Duo around 1600. The RAC\'s are 1491 and 4269 respectively. The Xeon hasn\'t reported today and I know there have been some problems with the CPDN servers which hurts the Xeon RAC right now, but there is no way the Core 2 Duo should have that much RAC--it hasn\'t even produced 2000 credits in a single day.
I also noticed iansm posted about this earlier. If we look at his/her BoincStats page, the third chart down indicates a very steady daily credit contribution (apart from the server hiccups) but the fourth chart shows his/her RAC skyrocketing.
I am relieved this calculation only affects RAC and not total credit. But it does make shopping for a new computer harder, as RAC is now more dependent on the application being run rather than the underlying hardware. |
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Geophi and I have looked at your links and think you\'re right - there\'s something wrong with the RAC of members like iansm who\'ve run HadAM3P models. He started his first Enron models on the day they were launched, 11 March. I think the first two rises in Ian\'s RAC on 17 and 19 March may be normal, but there should have been no further rises between 20 and 23 March incl. And Ian\'s credit spike on 25 March produced no rise in RAC, which also seems abnormal.
Geophi has started a thread about this in the hidden moderators\' forum section, which Milo will see. I\'ve posted in detail there about Ian\'s graphs. For comparison I\'ve also linked to the graphs of Neil Hunter who hasn\'t run any Enrons.
The HadAM3P models themselves are innocent. I wonder whether there could be be an error in one of the trickle, credit or export scripts and it only relates to this model type.
Could everyone please note that all model types are generating the correct amount of credit.
I hope iansm and Neil Hunter don\'t mind that they\'ve been mentioned by name. I\'ll send them both PMs on Monday so they do at least know.
Belfry, thanks for delving into the problem for us. I\'ve edited the thread title to what you suggested.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
Could everyone please note that all model types are generating the correct amount of credit.
I hope iansm and Neil Hunter don\'t mind that they\'ve been mentioned by name. I\'ll send them both PMs on Monday so they do at least know.
Belfry, thanks for delving into the problem for us. I\'ve edited the thread title to what you suggested.
Hi everyone,
Well this is perfect timing to see this thread (and the PM from Mo).
I have just started a few of the new HADAM3P models just 48 hours ago. I grabbed three for my quad-core machine and two for my dual-core.
Firstly, one model crashed after just 11 hours, which forced me to do a Windows repair install which was annoying to say the least.
Secondly, they are certainly slowing down. On the Q6600 machine, they are currently running at around 5.1s/TS each, and 6.8s/TS on my 950D. I\'ll monitor how much slower they get. On the Q6600, I am running World Community Grid and Rosetta as well as two HADAM3P models plus a mid-Holocene. I hope a combination of these will be OK, as I read that running four HADAM3 models will slow the s/TS dramatically - there must be a FSB/RAM bottleneck.
Lastly, the RAC issue is weird!! The credits seem perfectly normal - but the RAC has jumped far too much in too short a space of time.
See my BoincStats page - http://boincstats.com/stats/user_graph.php?pr=cpdn&id=81594
You\'ll see my credit is normal for today (my PCs run other projects too, so credit is 1267 today, but the RAC has gone from 358 on Saturday to over 1100 in just 48 hours, despite the credits being just 79 yesterday and 1267 today!!! I would have expected a jump to maybe 450-500 maximum after just this amount of credit; it should take about 6 weeks to get the RAC up to your daily credit level I believe.
Anyway, I\'ll keep an eye on all of this, and will let you know my findings in a couple of days.
Best regards,
Neil.
____________
 |
|
|
|
|
....When 2 or 3 days\' worth of credits are exported all together it pushes the RAC up abnormally. We\'ll have to keep an eye on this to see whether our RAC does return to normal after a few weeks as it should if the CPDN server behaves for Milo....
I have to disagree here because if the credits aren\'t exported for a few days, then your RAC will drop over that period, only to return to the level it would have been at when the credits are finally exported.
The RAC is just a measure of average performance over time, as you know, so if your PC is capable of RAC=1000 for example, then you let it run 24/7 but disconnect from the internet for a week, your RAC will drop exponentially over the time disconnected to around 500 or so.
When it is reconnected, you may get 7000 credits or something crazy, but your RAC should only pop back to 1000 again; no more, no less.
Or is the RAC equation more complex than this???
Regards,
Neil
____________
|
|
|
|
|
The RAC is just a measure of average performance over time, as you know, so if your PC is capable of RAC=1000 for example, then you let it run 24/7 but disconnect from the internet for a week, your RAC will drop exponentially over the time disconnected to around 500 or so.
When it is reconnected, you may get 7000 credits or something crazy, but your RAC should only pop back to 1000 again; no more, no less.
Or is the RAC equation more complex than this???
Assuming that it is still the same formula used as listed here, then there is a higher weight attached to recent credit than older credit. If you trust my maths and the simplified cases, the following examples can show this. I\'ve assumed that credit and RAC are only calculated once per day, and that RAC was stable at the start.
Case 1 - 1000 credits per day added. RAC stays permanently at 1000
Case 2 - Upload turned off for a week. After 7 days the RAC will have dropped to 500. On day 8, 8000 credits will be added (1000 per day of running time). After the calculation on day 8 though, the RAC is now 1207.07 even though you have only produced 1000 credits per day. This will obviously decay back to 1000 over a couple of weeks.
Hope this helps
Michael |
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Hi Michael
Yes, the explanation\'s useful, but I\'m afraid the RAC of members with the new tasks isn\'t following these calculations. The RAC of people with the new models has shot up while other members not crunching them have normal RAC.
Milo doesn\'t think it can be a bug or misentered value in any of the CPDN credit scripts. He and Tolu have done things with these scripts recently, but the scripts themselves haven\'t been altered. Milo will look into the problem when he has time.
The problem could lie in how CPDN exports its stats. You\'d think all our credits would go into a single pot and be exported to the stats sites as a single homogeneous quantity. However, we already knew that this isn\'t always the case. Those of us who crunch CPDN beta models have our Beta credits transferred to CPDN and added to our CPDN accounts. But the credit originating from the Beta project doesn\'t show up on the stats sites in our RAC. Willy\'s BoincStats RAC figures include it, but the usual RAC figures don\'t. It doesn\'t get completely assimilated with our CPDN credit and somewhere along the line is treated differently.
Richard Haselgrove thinks something similar could be happening to CPDN credit from the HadAM3P models. At some stage it\'s being treated differently from credit generated by other model types.
I think Richard\'s probably right about this but I\'m not sure that his theory is a sufficient explanation.
I\'ve posted an alternative explanation here.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
|
I see what you mean by the way the new Hadam3p WU’s are effecting the RAC. Running 3 WU’s (usually 1 Hadcm3 and 2 Hadsm3mh) on 2 middling level laptops (1 duel core, 1 single core) I used to usually be somewhere around 17th or 18th on the team USA listings with an RAC in the low 600’s. For the past week I have been running 1 Hadam3p in place of one of the Hadsm3mh. My RAC is now 905(!), but, I have slipped to 29th in the rankings. I am about to add another Hadam3p (on the machine that doesn\'t have one). I wonder how high my RAC will go. :)
Oh well, I don’t really run the models for the credits or the team rankings anyway.
____________
|
|
|
|
|
Richard Haselgrove thinks something similar could be happening to CPDN credit from the HadAM3P models. At some stage it\'s being treated differently from credit generated by other model types.
I think Richard\'s probably right about this but I\'m not sure that his theory is a sufficient explanation.
It is indeed a most perplexing mystery; I can\'t think of anywhere where hadam3p would be treated differently by BOINC as entries will be in the same tables as models that aren\'t causing a problem, and as I understand it it\'s BOINC code that should be dealing with stats exports and calculating RAC. |
|
|
|
|
Richard Haselgrove thinks something similar could be happening to CPDN credit from the HadAM3P models. At some stage it\'s being treated differently from credit generated by other model types.
I think Richard\'s probably right about this but I\'m not sure that his theory is a sufficient explanation.
It is indeed a most perplexing mystery; I can\'t think of anywhere where hadam3p would be treated differently by BOINC as entries will be in the same tables as models that aren\'t causing a problem, and as I understand it it\'s BOINC code that should be dealing with stats exports and calculating RAC.
Whatever the problem is, I think we have to look close at home. When I post this message, you should see a RAC of 7,947 below my name - well, you shouldn\'t see it, because it\'s far too high, but that\'s the figure that CPDN will display for you. And if you look at my computers, you\'ll see that the sum of the four individual RACs adds up to about the same: I should be nearer 2,000 per day for all hosts combined.
So I\'m pretty certain that the errors are not occuring at the \'export\' stage. The faulty figures are in our local database long before the exports are run: the problem has to be in the RAC calculation which is performed locally on the CPDN server (as per Milo\'s link - minor typo corrected in the quote above).
CPDN must do things differently from the standard BOINC code, because of the daily \'recalculate all credit from first principles\', and I don\'t know how you handle the \'aging\' process (7 day half-life) used to define RAC. But because the issue has arisen so suddenly since the introduction of the HadAM3P models, I can only surmise that the credits from these tasks are being fed into the calculations (both host and user) at a different phase in relation to the RAC update from the inputs from other model types. |
|
|
|
|
|
Thanks mo.v, geophi, Milo & Richard for delving into this.
It looks like HADAM3P is being treated like HADAM3H in the RAC calculation. If you look at the Core 2 examples I cited above, RAC is too high by a factor approximately of 2.61, which is the ratio of HADAM3H to HADAM3P credits--5184/1983.
I\'ve contacted my Las Vegas bookie and adjusted all my bets to account for the Enron-like RAC\'s--so you can take your time fixing this. |
|
|
|
|
|
OK, here\'s my betting slip for the Enron Bookies - if you could drop it in the next time you\'re passing, please? :-)
I invoke the principle of Murphy\'s Razor - anything which can get this many people this perplaxed for so long must be simple and obvious.
I think there must be a script which examines every reported trickle to establish its credit-worthiness. It must make two calculations:
a) What it the absolute credit value of this trickle? (to be added to host, user and team totals)
b) What is the discounted (npv) credit value of the trickle [reduced by e^(-ln(2)*t / 604800)]? (to be added to the host, user and team RACs)
When the script segment for HadAM3P models was added, it was copied and pasted from the HadAM3H template. Calculation (a) was updated to reflect the base trickle value for the new model type, calculation (b) wasn\'t. |
|
|
|
|
So I\'m pretty certain that the errors are not occuring at the \'export\' stage. The faulty figures are in our local database long before the exports are run: the problem has to be in the RAC calculation which is performed locally on the CPDN server......
Has something been fixed, as I see that my RAC from yesterday in my BoincSynergy signature has dropped like a stone, or was that simply because there was a server-outage yesterday which was only fixed late on in the evening??
Assuming the source of the RAC problem is found, I guess it\'ll take another 6 weeks or so for everyone to get back to their normal (appropriate) RAC?
Best regards,
Neil.
____________
|
|
|
|
|
|
Runaway RAC Effect!
After running a single HADAM3P for a couple weeks, I'm throwing out my 2.6 factor idea. My RAC hovers around 470 for one slab model, but it's now up to 1500--with no signs of leveling off. Maybe there's no linear relationship! Maybe it's logarithmic. Has anyone running HADAM3P's seen the RAC level off?
The floor of the top 100 is now 6700, whereas it was 4300 when I started this thread. Pretty soon we'll need scientific notation to depict these numbers. |
|
|
|
|
|
Maybe RAC values aren't being deprecated by days: while a HADAM3P project is running its accumulated credit is calculated as though it was all reported yesterday. RAC is deprecated again after project completion.
I didn't do any calculations, so this is merely another guess. |
|
|
|
|
|
Yes, the RAC is still being reported incorrectly, very high, especially on the Mac's. It is many times higher than the actual output. |
|
|
|
|
|
Is there any progress on this problem?
While I am aware that the proper credit is being given, the false RAC is skewing all stats re 'Posiion by RAC'.
This has affected CPDN stats drastically, but has also affected Total Boinc stats as well, making this stat almost meaningless.
Obviously this problem is not a high priority for CPDN staff but has a fairly high annoyance rating for any crunchers trying to track their progress through the stats sites.
Note: This is not a gripe, only a query on resolution progress, and a reminder it does affect more than just this projects crunchers. |
|
|
|
|
|
I'm sure I have the wrong attitude about this credit business, but does any of it really matter in the grand scheme of things? Is any of it effecting the science in any way? Are the models being computed incorrectly because of the amount of credit given or not given?
Or am I just being a cranky old man?
____________
|
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Well, of course the credits don't affect the scientific results of the individual models. However, to the extent that credits motivate some crunchers to keep going and contribute more, they probably do help to increase the overall participation levels. And that helps the researchers.
I can understand members feeling that BOINC credits are an irrelevant bore, but I can also understand the members who enjoy the spirit of competition.
We are receiving the right number of credits for every model type including HadAM3P. It's just the recent average credit calculation done by the CPDN server that's wrong if it includes HadAM3P. We'll have to bring this problem up again with Milo.
http://boinc.berkeley.edu/dev/forum_thread.php?id=3796
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
We are receiving the right number of credits for every model type including HadAM3P. It's just the recent average credit calculation done by the CPDN server that's wrong if it includes HadAM3P. We'll have to bring this problem up again with Milo.
I am aware of this and would like to fix it. There are a couple of things getting in the way at the moment. The first is that I am not sure exactly where this problem lies and the second is that the entire credit process needs sorting out. Our current credit script is very slow with one particular part taking 5 hours to run and putting a heavy load on the database, and we really need to get this fixed. At the moment I'm trying some alternative means of performing the calculation. |
|
|
|
|
I am not sure exactly where this problem lies.
Am I even close to collecting on my bet? |
|
|
|
|
Am I even close to collecting on my bet?
Unfortunately not. |
|
|
|
|
Am I even close to collecting on my bet?
Unfortunately not.
Shucks. Thinking cap back on, then. |
|
|
|
|
I am not sure exactly where this problem lies.
Am I even close to collecting on my bet?
Is it day deprecation? Meaning a single core host producing 300 credits per day delivers this to the average credit formula:
Mon 300 Mon 300
Tues 600 Tues 300
Wed 900 when it should be ---> Wed 300
Thurs 1200 Thur 300
Fri 1500 (completion) Fri 300
Sat 300 Sat 300
(I know these numbers don't match an actual HADAM3P run--just illustrating the point.) |
|
|
|
|
|
Ahh... all is quiet on the climateapps2 board. The new scripts and hardware upgrades are working swimmingly--the admins and programmers richly deserve our appreciation and adulation.
However we still have beaucoup RAC with HADAM3P\'s!
Oh well, life is full of imperfections. It doesn\'t bother me so much because I use boincstats.com to look at monthly and weekly credit accumulations. Hopefully the newbs aren\'t too put-off by this. |
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
I think you\'re right - beaucoup trop. Since my beta models finished and I\'ve been running more HadAM3P, my blue RAC line has jumped above the red BoincStats RAC line. That\'s even though my slower AMD is only running Mid-Holocenes. I know the blue and red RACs are calculated by different formulas, but they shouldn\'t usually be way out of sync. Un mystère inexplicable.
I certainly shouldn\'t have a CPDN RAC above 2000 because my two computers together can only manage about 1450 daily max.
I\'ve noticed btw that on my C2Duo the HadAM3Ps run noticeably faster when there\'s a Mid-Holocene on the other core and not another 3P.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
|
It\'s just a minor annoyance. One could even say it spices the project up a bit.
mo.v, here\'s an early congratulations on 1,000,000 credits. Nice work!
Eric
|
|
|
|
|
|
Don\'t HADAM3P use the more advanced SSE2 instruction set on cpus? If so, they do more calculations per clock and boinc might expect that they would be awarded more credit. Just my thought on this. |
|
|
|
|
|
As has been posted many times, this project doesn\'t use the BOINC credits system.
Use the Advanced search, and set the Search limits to 1 year.
____________
Backups: Here |
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
For each model type there\'s a specific number of credits per trickle. HadSM and HadSM MH are essentially the same type so the number\'s the same. If you crunch faster and produce more frequent trickles you earn more credits.
The compilation is always designed to produce the highest quality model results, not to make the models run as fast as possible.
HadAM3P models receive their correct number of credits per trickle but produce incorrect, artificially inflated RAC (recent average credit) values. Milo has looked at this but cannot find the reason.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
.....................
HadAM3P models receive their correct number of credits per trickle but produce incorrect, artificially inflated RAC (recent average credit) values. Milo has looked at this but cannot find the reason.
This may be a very naïve remark, but, if the calculation seems correct, is there any chance the \"average credit\" weighting from HadAM3P models could be entered twice in the calculation as it seems that the RAC that should be just over 1,000, displays as just over 2,000?
I was running HadAM3P exclusively and had settled at 2,350 RAC after the replacement of servers.
Then I have been running exclusively hadsm (Holocene & Slab).
The straight line of \"Total Credit\" proves the same rates of credits have been given.
But RAC has sunk over the same 16 days and is levelling off at about 1,050.
During those 16 days total credits rose from 724,600 to 731,200.
That is an increase of 6,600.
That works out at just over 400 per day.
So, how come the RAC is calculated at the average over TWO AND A HALF DAYS.
That seems absurd.
As the RAC never seems to make any sense, it does not worry me.
I just ignore it as useless.
Quite happy aligning a ruler along the total credit graph to see delays caused by late returning or crediting of trickles.
I am just very, very curious as to what \"average\" means.
A speed is reckoned as miles per hour or feet per second.
But this mysterious RAC is just a number with no meaning.
\"Credits per day\" or \"Credits per week\" would be reasonable descriptions, but they are obviously neither of these.
Keith |
|
|
|
|
|
Well, I can tell you what RAC *should* be. It should be calculated using a moving average credits granted per day, over 7 days. The formula for this is here:
http://en.wikibooks.org/wiki/Statistics/Summary/Averages/Moving_Average
The fact that only one model miscalculates the RAC is a strange anomaly. Again, though, choose your battles. What\'s it worth time & effort to properly calculate RAC? |
|
|
|
|
Well, I can tell you what RAC *should* be. It should be calculated using a moving average credits granted per day, over 7 days. The formula for this is here:
http://en.wikibooks.org/wiki/Statistics/Summary/Averages/Moving_Average
The fact that only one model miscalculates the RAC is a strange anomaly. Again, though, choose your battles. What\'s it worth time & effort to properly calculate RAC?
OK. So, I enjoy mathematical puzzles, and this certainly is one.
It appears from that link, the average may be based on 10 days rather than on 7 days, but no matter.
The \"moving average\" whether \"weighted\" or not should be irrelevant in my case.
With minor fluctuations the total credits over 16 days were 400 per day.
This has remained steady in the period using HadAM3P exclusively, then running hadsm exclusively.
But the RAC has shown as 2,350 (nearly 6 times what it should) with HadAM3P.
Now settling down at just over 1,000 (still well over double what it should be) under hadsm.
So, I disagree that HadAM3P is the only model showing incorrect RAC.
It just is a more extreme example of inaccuracy, I think you must agree.
I agree with the formula to smooth out the curve, but wonder what values are taken for the weighting, and what happens at the \"near edges\" calculations that are mentioned.
It all seems to be a very complicated bit of work, when a straight average over the previous 14 or 28 days (total divided by the number of days) would give adequate smoothing anyway.
The \"adequate smoothing\" is provided by dividing the difference of the latest day added at one end and the day removed at the start of the average period, as this change is divided by 14 or by 28 depending on which of the 2 periods that I suggested are used.
And much, much simpler for computing (and more importantly, easily understood).
I wonder if the programmers might heed this, and think it might be worth considering?
Keith |
|
|
|
|
|
The programmers are busy with the Hi-res models and the 1200 year models.
However: \"Your input is important to us. Please call again later.\" :)
|
|
|
|
|
|
I MUST APOLOGISE.
I miscalculated the daily rate of credits as 400.
It should have been 660 per day. I misread a date on the graph.
So the period was 10 days and not 16 days as I previously said.
That could just about at a stretch be the figure the graph will finally level out.
So, I must withdraw my comment about ALL averages being way out.
Blush, blush. Sorry for not taking care to double check my calculations.
Although, if the 10 days mentioned in the link are to be believed, the graph should already have levelled out at 660 after the 10 days had elapsed.
It is still at 1,075 after 15 days on the hadsm models (which are accurately calculated?)
Keith |
|
|
|
|
|
The formula for RAC is:
Old_RAC * 0.5^(1/7) + Today\'s_credit * (1-0.5^(1/7)) = New_RAC
That is a weighted average so that more recent credit has a higher weight. It also means that your RAC has a half-life of 7 days.
If you start with a RAC of 2350 and your daily output is 660 credit, then according to the formula your RAC should be 974 after 17 days. Your current RAC seems to be 965, pretty close.
|
|
|
|
|
What\'s it worth time & effort to properly calculate RAC?
I agree--it\'s not worth the effort. But we could probably prevent a lot of head scratching by removing RAC from this site--or at least put some math violation in the script so everyone\'s RAC shows an error or zero. It\'s meaningless, so why keep advertising it as meaningful? |
|
|
|
|
The formula for RAC is:
Old_RAC * 0.5^(1/7) + Today\'s_credit * (1-0.5^(1/7)) = New_RAC
That is a weighted average so that more recent credit has a higher weight. It also means that your RAC has a half-life of 7 days.
Thanks, 3rkko, for the actual formula.
Yields a hotchpotch of historical average and current credit.
Useless information, which ends up echoing the current credits..
Totally agree with Belfry. Scrap RAC completely.
Average for past 30 days would be a good alternative (or other period).
A simple formula could be:
(Old_Av * 29 + Today\'s_Credit) / 30
It does not remove the first of the previous 30 days correctly, but would be a good compromise.
And it would be understated at start and take some time to \"die away\" on cessation of crunching.
But this can be adjusted by No-of_days and Zero_days being remembered as data each day.
What I would really like to see, is an extra line on the Total Credits graph inclusive of Pending Credits.
So that it should show a reasonably straight line for a steady work output.
That would be really great to monitor crunching progress.
The gap between the two lines plainly displaying the lag caused by the Pending Credits.
Keith |
|
|
|
|
What I would really like to see, is an extra line on the Total Credits graph inclusive of Pending Credits.
So that it should show a reasonably straight line for a steady work output.
That would be really great to monitor crunching progress.
The gap between the two lines plainly displaying the lag caused by the Pending Credits.
Keith
That might be useful for other projects but meaningless, even erroneous, for CPDN. \'Pending credit\' is not used here. Values sometimes appear but are ignored. Credit is recomputed, in total, every day (assuming the script runs), based on total Trickles received and Trickle value for different Model-types. (That\'s why all CPDN credit goes with you if you leave a team.)
____________
Greetings from coastal Washington state, the scenic US Pacific Northwest.
Important stuff no longer here: http://www.climateprediction.net/board/viewforum.php?f=44 |
|
|
|
|
What I would really like to see, is an extra line on the Total Credits graph inclusive of Pending Credits.
So that it should show a reasonably straight line for a steady work output.
That would be really great to monitor crunching progress.
The gap between the two lines plainly displaying the lag caused by the Pending Credits.
Keith
That might be useful for other projects but meaningless, even erroneous, for CPDN. \'Pending credit\' is not used here. Values sometimes appear but are ignored. Credit is recomputed, in total, every day (assuming the script runs), based on total Trickles received and Trickle value for different Model-types. (That\'s why all CPDN credit goes with you if you leave a team.)
Yes.
I was in SETI mode when I was thinking that, and should not really have put it onto my SPDN message.
I realised that some time after completing the message. You are quite right, of course.
Keith |
|
|
|
|
|
Can the problem be as simple as the HADAM3P\'s trickle more often (for a given computer) than other models? The weighted RAC algorithm may be preferentially responding to this.
Forgive me if I missed this in previous discussions. It\'s a long, rambling thread :-) |
|
|
|
|
|
Quoted
The formula for RAC is:
Old_RAC * 0.5^(1/7) + Today\'s_credit * (1-0.5^(1/7)) = New_RAC
Is this really the formula used by CPDN?
And is it applied individually to each WU type, then added for a total?
If so then then an extra zero in the equation (as below in red)for HADAM3P could explain an increase in RAC by a factor of approx 3.7 times expected for this WU type.
Old_RAC * 0.5^(1/7) + Today\'s_credit * (1-0.05^(1/7)) = New_RAC
I know Milo has checked the formulas ... but it would be easy to miss if you are not specifically looking for it.
Note: This error would not affect the normal 7 day half-life, but would cause RAC to go from Normal to more than double in just 5 days.
(I may be wrong... but it seems to match the symptoms)
Bruce |
|
|
|
|
|
Now that the Am3p’s are history (at least for the present) we can stop worrying about inflated RAC’s. Mine is sinking faster than a lead canoe. Oh well, back to an RAC of 600.
____________
|
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
A member saw CPDN\'s RAC graph and assumed the whole project was in terminal decline.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
A member saw CPDN\'s RAC graph and assumed the whole project was in terminal decline. Now that HADAM3P tasks are no longer available, I\'ve switched my hosts back to CPDN Beta. Beta credits are transferred to the main project, but RAC isn\'t - so in a few days, my red and blue lines at BOINCstats will cross.
Another reason not to take any notice of RAC. |
|
|
|
|
|
I would like to know:
Is Virtual Boss\'s elegant explanation correct?
Does the Loch Ness Monster exist?
What lies beyond the edge of the Universe? |
|
|
|
|
I would like to know:
Is Virtual Boss\'s elegant explanation correct?
Does the Loch Ness Monster exist?
What lies beyond the edge of the Universe?
Suggested answers:
I think so.
Yes, at least in theory.
The Mulitverse.
____________
Warped
 |
|
|
|
|
I know Milo has checked the formulas ... but it would be easy to miss if you are not specifically looking for it.
I\'ve been looking again and I can\'t see any sign of any such formula in the code. It looks like RAC is the expavg_credit value from the database, which our stats script derives directly from the credit per timestep. Specifically, the RAC looks like the sum of credit_per_timestep for the models run. |
|
|
|
|
|
This Boinc wiki page explains how RAC is calculated for all Boinc projects.
The official formula is:
New_RAC = Old_RAC*weight + New_Credit*(1-weight)
where weight = e^(-ln(2)*T/HL)
But if you know math you can see that e^(-ln(2)*T/HL) = 0.5^(T/HL)
where HL = half-life = 604800 seconds (7*24*60*60), and T is time since last RAC calculation.
In the formula I posted earlier in this thread I changed the time from seconds to days which means HL=7 and, because CPDN calculates credit only once a day, I set T=1, which leads to weight=0.5^(1/7). You will obviously not find this modified formula in the code. |
|
|
|
|
|
Our calculation is not the same as on the BOINC Wiki.
I\'ve been discussing this with some of the board moderators and I think that a change I\'ve made today to the stats scripts should fix things. |
|
|
|
|
|
Yes, mine looks better now. |
|
|
|
|
Our calculation is not the same as on the BOINC Wiki.
It isn\'t? That surprises me a bit. Is this a general thing or CPDN-only? Does this mean we have CPDN-RAC, which can\'t rightly be added to the RAC of other projects? Because of the apples<>oranges thingy? |
|
|
|
|
Our calculation is not the same as on the BOINC Wiki. It isn\'t? That surprises me a bit. Is this a general thing or CPDN-only? Does this mean we have CPDN-RAC, which can\'t rightly be added to the RAC of other projects? Because of the apples<>oranges thingy?
I think that what Milo means is that CPDN can\'t use the exact calculation formula listed in the Wiki, because CPDN has to handle trickles and so on.
So they have their own bit of maths in the back end, which gets the same answer as the Wiki technique, but can\'t be found by a search for the Wiki text in the source code. But it\'s comparable to other projects, and can be used to generate an aggregate for competition purposes.
At least, it can be now...... |
|
|
|
|
Our calculation is not the same as on the BOINC Wiki.
I\'ve been discussing this with some of the board moderators and I think that a change I\'ve made today to the stats scripts should fix things.
I think there\'s been some border damages : many teams have seen their credits disappeared
-91 954 777 for my team L\'Alliance Francophone. and others were impacted. Is there i\'ve understood in the wrong way?
++
lamoule
excuse my poor English but as i\'ve may have guessed, I\'m French.
____________
|
|
|
|
|
|
This resembles with me. More than -65.000 Credits drawn off. Why? What does this deal with the correction of the RAC?
____________
Wiki German Language, Wiki in deutscher Sprache
View
|
|
|
mo.vForum moderator
Send message
Joined: Sep 29 04
Posts: 2270
Credit: 5,354,415
RAC: 1,243
|
|
Bonsoir, Guten Abend, Hi to everyone
The BoincStats total credit lists for CPDN are chaotic. Some big crunchers have lost millions of credits. I posted about this an hour ago in a private forum for CPDN moderators and programmers. Milo will see my post tomorrow but he\'s doing other things this evening.
When we know what the problem is we will post in the forum News thread at the top of the Number Crunching section.
This is clearly an accident and I am sure it will be corrected.
____________
Cpdn news
5 CPDN READMEs |
|
|
|
|
This is clearly an accident and I am sure it will be corrected.
Indeed so; apologies for these problems. I\'ve only made a small change to the stats script and would not expect it to have such an effect. It should be fixed next time the stats code is run but in any case investgating it will be my first priority tomorrow.
|
|
|
|
|
|
All now seems to be working correctly - thank you for your patience. |
|
|
