I noticed that my RAC was dropping and then found out that the new HadCM3 Full Resolution model gives about four times less credit/hour compared to other cpdn models. Do other users see the same low credit for this model? Not that credits matter, but it would be nice if they were in line with the other models.

...same here - 60 hours of crunching produces about 80 credits...my RAC is dropping like a rock...

There is no doubt that the CM models yield the lowest number of credits per hour. The now more or less completed Famous WU’s yielded the most per hour. The still available Regional models yield something in between. An adjustment might be in order.

---

This is also the case in my situation. I Liked the situation that there is again work available for my MAC-pro systems, so I set them up to run about 80% of the time Climateprediction and then i see that the amount of credit / day is dropping dramaticly. In average I receive for this kind of jobs between 130 and 180 credits for one day crunching. Normal this is between 500 and 700 credits for one day of work.

Have been aware of this since downloading 5 of these 40 year models so this thread prompted me to analyse my own stats data.

Results are derived from a sample of 493 completed and active models in 3 closely performing systems (i7 950, i7 920, Q6600 - all @ 3.20) which run 24/7.

1. HadAM3P (2 years): average credit per day per model = 908, average CPU days = 2.6, completed credits = 2,082
   
2. FAMOUS (200 years): av credit pd = 823, days = 7.8, credits = 6,176
   
3. HadAM3P (1 year regional): av credit pd = 637, days = 4.0, credits = 2,244 to 3,006
   
4. HadCM3L (80 years): av credit pd = 570, days = 45.0, credits = 26,127
   
5. HadSM3 (45 years): av credit pd = 245, days = 9.8, credits = 7,146
   
6. HadSM3MH (60 years): av credit pd = 202, days = 12.4, credits = 9,527
   
7. HadCM3N (40 years): av credit pd = 163, days = 20.0, credits = 3,250
   

Clearly credits awarded per model type are inconsistent. People who "like" credits may ignore low payers! HadCM3N is obviously way out of line.

Currently, I'm running 4 HadCM3L models in one machine and 5 of the HadCM3N models in another. The affect on RAC is obvious.
Compare HadCM3N with HadAM3P (regional). In my i7 920, it will take at least 4 times longer to yield a similar credit! :)

Looking at the above table I would suggest that the HadCM3L application delivers a fair credit return. Perhaps other model credits could be adjusted?
There is a precedence. In the past, both the original HadCM3 160 year types as well as HadSM3 (I think) had credits uplifted across the board including historical records.

Footnote: Just noticed that there are no HadCM3N models in the pool. Next up?

Unlike with other projects, there is no quorum here, so if/when the credit value for a model type is adjusted, everyone who has run that type gets an automatic adjustment after the next export file cycle.

The low(ish) credit rate was mentioned during beta testing, but apparently didn't get adjusted when the model was rushed to production mode.
The data is needed ASAP, so getting it out quickly was a higher priority than instant correct credits.

The pool was drained suspiciously fast, so it's possible that there's still a lot of unattended grab-and-crash computers around.
The researchers have said that a follow up batch won't be available until the results of these first spinups are completed and returned, as they are needed to start the next lot.

And the project is still short of staff. :(

---

Backups: Here

The phrase 'Low Credits' isn't strong enough by a mile. I'm getting an more than order of magnitude lower numbers.

Example: Dual core 3GHz cpu running 24/7: After 9 days I have 47 credits!
That particular CPU has been with me a while - my records show it first appeared in Jan 2009. Two months later it was at 1200 credits and has been in that area since.

Currently, after 9 days it was up to a stunning 47, now at 12 days it is *down* to 35 despite running constantly. I have several other systems with the same syndrome - crunching out numbers as fast as usual and losing ground while doing it.

I've been patient through the transition to no models and back up, but this is an insult to everyone who pays for extra electricity to run these models and provide computation that CPDN could not afford otherwise. Production and position are the *only* rewards we get, and now both of these are in the negative column.

I'm going to hang in for another two weeks, then start shifting my systems unless there is significant progress in turning this negative feedback into positive. Anyone who thinks that credit doesn't matter will be surprised by the fallout if this problem continues much longer.

Ignore this issue at CPDN's risk.

BillN

---

The message was passed to the project yesterday after iansm's post. That was a Friday and nothing is going to happen over the weekend.

All they have to do is change some rate constant and everything past and future will be up-rated. The HADCM3N project has a sequence: this batch are spin-ups for the next batch, so when the beta models ran correctly the project scientists were under some pressure to get things going with a big ensemble here on the main site. They missed the credit rate calculation done in beta - and will presumably correct it now that the anomaly has been pointed out.

Scratch that: no trickles are being recorded beyond 10 years. Will pass that on to the project team - this is a common problem when model lengths are switched from 10 to 40 years.

We just have to change something in the database to get the trickles processed. We'll do this tomorrow. (The trickles have been recorded but not processed - this was something that happened in beta as well and was quickly rectified).

The credits problem : we're looking into it.

Hi,
I'd like to second what Neil has said.
Correcting the problems with the credits is on our list of things to do.
The low credit score for a given model is something that can be corrected in a straightforward manner.

The trickles issue is 'known' and we have a solution.

Please accept my apologies for the annoyance this causes you - I will be correcting the issues over the course of the coming week, when I will be doing another round of maintenance on the project's database servers.

Hang in there, chaps, the project relies upon your efforts.

Jonathan
interim CPDN IT support

I really do believe that there needs to be a credit adjustment with regard to the CM models. I am not usually an avid credit watcher, but, since March 11 my RAC has dropped by nearly 50% from 950 to under 500! This is due to my choosing to run a Hadcm3n model.

I know that credits awarded for the Hadam3p regional models were set high to compensate for the larger share of computer resources that they consume. Maybe it is time to place the CM models on the same level of compensation because of the much greater commitment of time involved in running them.

---

Jim, that's what has just been said is going to happen!

Please be patient.

I will reaffirm previous statements that the various credit issues that have arisen recently will be addressed very shortly during the next phase of work on the CPDN databases.

This work will be carried out within the next 7 days.

The database contains all the information from which user credits are calculated, so it is imperative that the database is running as it should.

During the maintenance I will make the appropriate corrections to credit rates for the HadCM3 Full Resolution model, and when the user credits are re-calculated those who have run these models will be rewarded appropriately.

INTERESTING CPDN FACTOID: The database that holds all the records of user-contributed data is about 0.5 TB in size, and allows us to keep track of the 80 TB of data that CPDN supporters have produced.

The forthcoming work on the database will involve adding a second database server to take some of the load off the main server, allowing us to manage the huge amount of data that the community so kindly provides for us.

The staff at CPDN do appreciate all the work that is put in by the community, and I hope you can see that we do respond to feedback from our users (though I admit in recent months the response time has been slow due to lack of staff).

Please hang in there, chaps.

Jonathan
Interim CPDN IT Support

These folks are as good as their word, and fast too. As of 12Apr2011, I have jumped up about 2500 points since yesterday.

My compliments on the fast work. Thanks for the extra effort.

BillN

---

The credit issue seems to be fixed now, I got +21,000 credits today. Thank you.

HadCM3n credits have been "upgraded" to 12,441.60 for a completed model (40 year trickles @ 311.04).

Previously just 3,249.60 (40 x 81.24).

Thank you Jonathan!

Well, I spoke too soon. A few of the 12 systems I run jumped up, and I expected the others to follow. They did not.

Based on my records, taken each day on all systems, from Apr 24th thru 30th, all systems have reverted back to the previous LOW numbers and despite most systems running 24/7, the totals are now stepping down slowly, with two exceptions not running the new codes.

Apparently the code fix for tiny credits has been pulled or reverted without any notice that I have seen. Once again I request that this problem be officially placed on the fix list, hopefully this time fixed for good.

With all the work and changes going on, I'm not completely surprised given the excessively small staff and the very large job and set of responsibilities that they carry. But I do hope for a complete and permanent fix this time around.

<sigh>
Bill Nicholls
[/b]

---

Bill,

What stats are you looking at? Looking at the trickles, hadcm3n's are receiving 311 per trickle, or 12441 per model run. This is 4 times what iansm calculated per run back when they were first put out. So, if a Phenom II 955 runs 4 of them in 20 days, that's 2500 credits per day for that PC. I don't think that has changed since the credits were upped for this type of model.

The s/TS for 2 of the models on the Phenom are very erratic. Perhaps indicitive of bad data.

hadcm3n_p7my_1900_40_007227482_1

hadcm3n_p70u_1900_40_007226686_2

---

Backups: Here