What does
<b>Message from server: No work available (daily quota exceeded)</b>
mean?

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

There's a daily limit of 4 results for each host.

Tracing through to <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/result.php?resultid=573428">one of your results</a> I see that you're running BOINC development version 4.24, which requires a file signature for each downloaded file. CPDN downloads 1 exe file (which is signed) and 3 zip files (which aren't). The lack of signatures causes that version BOINC to reject the download, retry 3 times and get told to try again tomorrow.

CPDN won't be able to run with any BOINC development releases until the server side software is recompiled with the development source, so the only way you can continue to run CPDN until then is by reverting to the stable release 4.19 (which sometimes fails to parse scheduler responses correctly). If you can't do that you should detach from the project to prevent your system from using up the available workunits.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

I did as you suggested: I uninstalled 4.24 then installed 4.19.
I'm still getting:
<b>Message from server: No work available (daily quota exceeded)</b>

Can I assume this will resolve itself tomorrow?

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

&gt; I did as you suggested: I uninstalled 4.24 then installed 4.19.
&gt; I'm still getting:
&gt; <b>Message from server: No work available (daily quota exceeded)</b>
&gt;
&gt; Can I assume this will resolve itself tomorrow?
&gt;
It should.

In answer to Thyme Lawn's post. I got around this problem by having the cruncher files already installed on the system before upgrading. When I un-installed CC v4.13 prior to upgrading to v4.22, it left the projects and slots directories intact. (With CPDNs cruncher files and WUs). Installing v4.2x in the same directory will allow you to continue where you left off because it will use the EXISTING copy of the cruncher WITHOUT checking for signatures. Whether this is an undiscovered bug or done by design, I'm not sure. It seems like it ONLY checks signatures on crunchers IT has downloaded and NOT on crunchers that pre-exist in the BOINC directory from previous installations.

---

<img src="http://boinc.mundayweb.com/one/stats.php?userID=444&amp;trans=off">

&gt; In answer to Thyme Lawn's post. I got around this problem by having the
&gt; cruncher files already installed on the system before upgrading. When I
&gt; un-installed CC v4.13 prior to upgrading to v4.22, it left the projects and
&gt; slots directories intact. (With CPDNs cruncher files and WUs). Installing
&gt; v4.2x in the same directory will allow you to continue where you left off
&gt; because it will use the EXISTING copy of the cruncher WITHOUT checking for
&gt; signatures. Whether this is an undiscovered bug or done by design, I'm not
&gt; sure. It seems like it ONLY checks signatures on crunchers IT has downloaded
&gt; and NOT on crunchers that pre-exist in the BOINC directory from previous
&gt; installations.
&gt;
&gt;
I believe it is by design. Once a file gets into your system it is assumed to be safe, no need to check it again. It is just making sure the files put on your system are valid.

---

BOINC WIKI

BOINCing since 2002/12/8

&gt; In answer to Thyme Lawn's post. I got around this problem by having the
&gt; cruncher files already installed on the system before upgrading. When I
&gt; un-installed CC v4.13 prior to upgrading to v4.22, it left the projects and
&gt; slots directories intact. (With CPDNs cruncher files and WUs). Installing
&gt; v4.2x in the same directory will allow you to continue where you left off
&gt; because it will use the EXISTING copy of the cruncher WITHOUT checking for
&gt; signatures. Whether this is an undiscovered bug or done by design, I'm not
&gt; sure. It seems like it ONLY checks signatures on crunchers IT has downloaded
&gt; and NOT on crunchers that pre-exist in the BOINC directory from previous
&gt; installations.
&gt;
&gt;

I tried this, I restored the files from a backup but they are not recognized. I'm assuming I have to "register" them in the <b>client_state.xml</b> file, but I'm not sure what all the fields do and I don't want to mess with the WUs that are correctly registered to me.

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

An interesting point though... Don't you think John?

---

<img src="http://boinc.mundayweb.com/one/stats.php?userID=444&amp;trans=off">

&gt; I tried this, I restored the files from a backup but they are not recognized.
&gt; I'm assuming I have to "register" them in the <b>client_state.xml</b> file,
&gt; but I'm not sure what all the fields do and I don't want to mess with the WUs
&gt; that are correctly registered to me.
&gt;

For a full explaination of how I did this, you might like to look at <a href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=11887">this</a> message I posted in the SETI forums. In short you will have needed to preserve the directory structure that the v4.1x un-installer left behind, as you need to install v4.2x into that same location.

---

<img src="http://boinc.mundayweb.com/one/stats.php?userID=444&amp;trans=off">

fyi: I was able to restore the older WU and modify the <b>client_state.xml</b> file so that my current WU was preserved and my older WU is recognized and <i>Ready to run</i>.

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

&gt; fyi: I was able to restore the older WU and modify the
&gt; <b>client_state.xml</b> file so that my current WU was preserved and my older
&gt; WU is recognized and <i>Ready to run</i>.

You also need to make sure that your <b>slots</b> directory is properly set up for processing the results.

There should be an <b>active_task</b> section for the WU towards the bottom of the file, and the <b>slot</b> setting is its slot number. Make sure that you've got {WU}.xml and cpdnout1.zip to cpdnout5.zip files in that slot directory, otherwise the final result upload is guaranteed to fail.

Despite the names, the files are actually XML softlinks used to generate the results. If they're missing you'll need to regenerate them using the contents of your other CPDN job's slot directory and the <b>result</b> section for the WU in client_state.xml as a template. If you have any problems just ask and I'll post up an example.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

&gt; If you have any problems just ask and I'll post up an example.

I did those too and I <i>think</i> I have it all right, but I'll take you up on your offer of an example, just to be sure. I'd hate to run a WU for a month only to have it refused.

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

&gt; &gt; If you have any problems just ask and I'll post up an example.
&gt;
&gt; I did those too and I <i>think</i> I have it all right, but I'll take you up
&gt; on your offer of an example, just to be sure. I'd hate to run a WU for a
&gt; month only to have it refused.

Okay, here we go John :)

I've replaced all &lt;&gt; pairs with {} so I don't have to replace every &lt; with &amp;lt;

In client_state.xml I have the following sections:

{active_task}
{project_master_url}http://climateprediction.net/{/project_master_url}
{result_name}2kbb_100140849_1{/result_name}
{app_version_num}404{/app_version_num}
{slot}0{/slot}
{scheduler_state}2{/scheduler_state}
{checkpoint_cpu_time}2133029.250000{/checkpoint_cpu_time}
{fraction_done}0.825730{/fraction_done}
{current_cpu_time}2133029.812500{/current_cpu_time}
{/active_task}

and

{result}
{name}2kbb_100140849_1{/name}
{final_cpu_time}0.000000{/final_cpu_time}
{exit_status}0{/exit_status}
{state}2{/state}
{wu_name}2kbb_100140849{/wu_name}
{report_deadline}1132923865{/report_deadline}
{file_ref}
{file_name}2kbb_100140849_1_1.zip{/file_name}
{open_name}cpdnout1.zip{/open_name}
{/file_ref}
{file_ref}
{file_name}2kbb_100140849_1_2.zip{/file_name}
{open_name}cpdnout2.zip{/open_name}
{/file_ref}
{file_ref}
{file_name}2kbb_100140849_1_3.zip{/file_name}
{open_name}cpdnout3.zip{/open_name}
{/file_ref}
{file_ref}
{file_name}2kbb_100140849_1_4.zip{/file_name}
{open_name}cpdnout4.zip{/open_name}
{/file_ref}
{file_ref}
{file_name}2kbb_100140849_1_5.zip{/file_name}
{open_name}cpdnout5.zip{/open_name}
{/file_ref}
{/result}

These tell me that the files need to be in the directory <b>slots/0</b> and what the relationship is between the cpdnout files and the real result files. I've changed the directory separators to '/' for display reasons :)

File name <b>2kbb_100140849.zip</b> contains the line

{soft_link}../../projects/climateprediction.net/2kbb_100140849.zip{/soft_link}

and <b>cpdnout1.zip</b> contains the line

{soft_link}../../projects/climateprediction.net/2kbb_100140849_1_1.zip{/soft_link}

For cpdnout2.zip to cpdnout5.zip just replace the last '_1' with the relevant number.

I don't think the XML soft links to the downloaded files are essential, but they're the same for all CPDN models (unless the program version number has changed) so can safely be copied without alteration.

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

&gt;
&gt; Okay, here we go John :)
&gt;

Wow, I think I actually did it all right before!

Don't you think it would be a good idea, especially for these very long WUs, to have a process that would either:
1) allow the user to re-upload the WU
or
2) occasionally re-verify that the user still has the WU and if not, either re-upload it or mark it reusable for someone else.

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">

Strange that you should mention these two points John.
That IS what happens. At the moment, though, things are in a state of flux.
The BOINC people put up a TEST version, people starting using it, and when it didn't work here, got irrate.
The CPDN site has now been fixed to placate these people, but there will no doubt still be problems as people migrate.

As for your points:
1) To re-upload: in the gui, click on the Project tab, then right-click on the climateprediction.net project.
This gives you a menu. Click on Update.
If however, you mean FROM the server TO the host, (download), then the original parameter set may no longer be
available. It depends on how long it has been crunching on the host when a problem occurs.

And there are inbuilt steps the program can take to try and recover automatically.

2) Trickles should REALLY be allowed to go back to the server daily.
Unfortunately, the instructions say that only one access to the server is required, at the completion of a model.
It's been discussed before.

There is a story, which I haven't seen 'officially', that if a trickle hasn't been received by the server
in about six weeks, that the server will re-allocate the parameter set to another user, up to a limit of 5 times.
I know that re-allocation occurs, but some of this is to check on different processors, etc.

Happy crunching.

Les

&gt; Strange that you should mention these two points John.
&gt;
&gt; Happy crunching.
&gt;
&gt; Les
&gt;
&gt;
&gt;

Thanks Les!

---

<img src="http://www.boincsynergy.com/images/stats/comb-858.jpg"><img src="http://boincview.amanheis.de/boincview_small.png">