Stats show a huge difference between model years and completed runs (>300 years per run).

My personal experience has been positive. Boinc is around 10% faster on my home machine.
Plus the suspend network activity is probably the solution to the only problem I had with Classic:
It wasted my archives (couldn\'t find file... Deleted it instead!), and gave me only short runs apparently after one run finished while I wasn\'t connected.
So I\'m surprised at the low rate of success so far.
Classic CPDN had short runs vs completed runs.
Can we have something similar?
Or has anyone got info on the success rate?
Is it going up after the expected teething trouble or whatever?

There seems to be a general problem with BOINC losing track of the work done at restarts ocasionally (client_state.xml gets corrupted), this seems to have a bigger impact on CPDN than other projects. Exiting the client manually before shut down/restart seems to help some in this case.

It also seems like CPDN takes a bit longer to get started than other projects. When a suspend of some type occurs during this startup period it seems to corrupt the workunit.

These are my personal observations and are not backed up with any good data.
<br>John Keck -- BOINCing since 2002/12/08 -- <a href="http://www.boinc.dk/index.php?page=user_statistics&amp;project=cpdn&amp;userid=191"><img border="0" height="80" src="http://191.cpdn.sig.boinc.dk?188"></a>

&gt; There seems to be a general problem with BOINC losing track of the work done
&gt; at restarts ocasionally (client_state.xml gets corrupted), this seems to have
&gt; a bigger impact on CPDN than other projects. Exiting the client manually
&gt; before shut down/restart seems to help some in this case.
&gt;
&gt; It also seems like CPDN takes a bit longer to get started than other projects.
&gt; When a suspend of some type occurs during this startup period it seems to
&gt; corrupt the workunit.
&gt;
&gt; These are my personal observations and are not backed up with any good data.
&gt;
I think most of the corruptions are coming with overclocking, bad hardware or high vibrations in the system. It happens with the other projects too but the projects arent so long - few hours in SETI vs. 3-4 weeks in CPDN.
One of the sollutions is to always have a good backup of the project and not to be connected to the internet during the resuming of the project.
Just a thought.

<img src="http://boinc.mundayweb.com/cpdn/stats.php?userID=70">

To illustrate my point about the success rate
Latest stats
(Generated on 2004-10-06 11:26:36 UTC)

Total HadSM3-equivalent Model-Years 332188.39
Completed Runs 1119
So the latest ratio is:
years/completed runs 296.86

That figure takes no account of ongoing models - there are now 20,200 CP-boinc machines trickling, say they were all an average of 50% through their latest model, ie. 22.5 model years, that would be 20,200 * 22.5 = 454,500 model years plus 1,119 * 45 = 50,355 model years for completed models - a total of over 500,000 model years which we haven't reached as yet. (50% average for all ongoing models is obviously too high a figure.) Not much effort has been wasted on short runs by the look of it to me...

<a href="http://www.nmvs.dsl.pipex.com/"><img src="http://boinc.mundayweb.com/cpdn/stats.php?userID=6&amp;team=off&amp;trans=off"></a>

To add to UK_Nick's point, many people are using BOINC multi-project (as it is designed). So it may take much longer for WUs to be returned than under classic CPDN.

Getting better.
Generated on 2004-10-07 05:37:34 UTC
Total HadSM3-equivalent Model-Years 341863,93
Completed Runs 1200
years/completed runs 284,89

I've lost about 4-10 minutes worth of work on BOINC CPDN, and it becomes critical as I don't run BOINC often (only when SETI@home classic's servers go out). When you only have 1/2 an hour of CPU time, these problems do need to be resolved. I suspect it's due to the ultra-large bits of data CPDN sends out (It's large when you see that SETI@home's data bit is only 340 kb, while CPDN's is about 40 mb), or that BOINC doesn't write the data to the hard drive often enough.

&gt; I've lost about 4-10 minutes worth of work on BOINC CPDN, and it becomes
&gt; critical as I don't run BOINC often (only when SETI@home classic's servers go
&gt; out). When you only have 1/2 an hour of CPU time, these problems do need to be
&gt; resolved.

Well, I don't want to discourage anyone from joining CPDN, but with a 2.4GHz Pentium a WU is going to take about 600 hours running time to process. This isn't a 'fault' - modelling the earth's climate is a heavy duty application.

The data you have observed isn't sent out by the CPDN server, either. It is generated by the program. The WU sent out is actually very small.

Saving more often would be possible. It happens once every three model days, which is obviously more frequent on a fast machine than a slow one. But it is a question of balance; the program is fairly disk intensive anyway and CPDN is really for machines that can run it for significant periods of time.

Why not give SETI classic a rest and try CPDN for a few weeks? You might get hooked.

---

Depending on your PC, data is indeed saved every 4-10 minutes.
You can check this in your BOINC projects CPDN model id dataout directory.
the thist and restart day files show the timestamps for the latest save.
So when I have to do maintenance and don't want to lose the 7 minutes or so on my machine, I have a look at that.
But I totally agree with Andrew that CPDN isn't a half-hour project. Ii is very different from the other BOINC projects in model size and hardware usage. But it's perfectly OK to share with other projects if your machine is up to the task.

---

Forum search Site search

&gt; I've lost about 4-10 minutes worth of work on BOINC CPDN, and it becomes
&gt; critical as I don't run BOINC often (only when SETI@home classic's servers go
&gt; out). When you only have 1/2 an hour of CPU time, these problems do need to be
&gt; resolved. I suspect it's due to the ultra-large bits of data CPDN sends out
&gt; (It's large when you see that SETI@home's data bit is only 340 kb, while
&gt; CPDN's is about 40 mb), or that BOINC doesn't write the data to the hard drive
&gt; often enough.
&gt;
What brings the '1/2 an hour of CPU time' to an end?

If it is that you want to turn off the computer, then there is little than can be done about the loss of upto 143 timesteps each time.

If it is due to switching back to seti with PC on 24/7, then the leave in memory while suspended should work.

If it is exiting BOINC to do some intensive work, then try just suspending BOINC rather than exiting (with leave in memory while suspended set to yes).

---

Visit BOINC WIKI for help

And join BOINC Synergy for all the news in one place.