Hello,

surfing through the cp sites I found one interesting host:

<a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/results.php?hostid=79040">http://climateapps2.oucs.ox.ac.uk/cpdnboinc/results.php?hostid=79040</a>

this host loads wus and is crashing them permanently. Is there any way to reject this host from getting new work from the project side? This may be an interesting point in cases of workunit shortage.

ciao, tom

---

The best source for asking problems with BOINC and the ClimatePrediction client

Hi tom,

i'm afraid this host doesn't meet CPDN requirements; 350MHz Pentium is propably not up to CPDN project which is quite demanding. I would suggest to try another BOINC project with this machine.

See Recommended System Requirements
http://climateapps2.oucs.ox.ac.uk/cpdnboinc/tech_faq_boinc.php


&gt; Hello,
&gt;
&gt; surfing through the cp sites I found one interesting host:
&gt;
&gt; <a> href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/results.php?hostid=79040"&gt;http://climateapps2.oucs.ox.ac.uk/cpdnboinc/results.php?hostid=79040</a>
&gt;
&gt; this host loads wus and is crashing them permanently. Is there any way to
&gt; reject this host from getting new work from the project side? This may be an
&gt; interesting point in cases of workunit shortage.
&gt;
&gt; ciao, tom
&gt;

Hi Honza,

for information: this host belongs not to me *g*. It belongs to user <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/show_user.php?userid=33275">fenix</a>.

ciao, tom

---

The best source for asking problems with BOINC and the ClimatePrediction client

Some sort of filter may need to be implemented for the coupled ocean model if people are going to ignore
the minimum hardware requirements.
In which case in would probably apply to all model types.
'fenix' appears to be running automaticly, without checking what's happening.

For now, an email from the admins is the only answer.

Les

I was initially opposed to enforcing a minimum requirement when BOINC was launched, because we have had a few people successfully completing runs in Classic with very slow computers. Carl was not sure whether the BOINC version would be more or less demanding, and part of the purpose of the project is to educate people about climate. None of wanted to unnecessarily exclude people just because they could not afford a new machine.

It may be, though, that the team should do so now, but I don't know whether it is practicable for them to establish whether there are underpowered machines that are succeeding in running without problems. The other aspect is that there are many reasons why WUs might fail repeatedly, besides lack of cycles. I think this has arisen in SETI as well. A daily download limit does not screen these out and I wonder whether there might not be another solution. For example, flagging up those who had exceeded a limit over a longer period.

---

<a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/show_user.php?userid=4309"> This user</a> has a similar problem on several computers.
One very slow machine, but also others, including a 3.2G laptop.

Are well. :( I'm not involved in the science side of this.

Les

&gt; I was initially opposed to enforcing a minimum requirement when BOINC was
&gt; launched, because we have had a few people successfully completing runs in
&gt; Classic with very slow computers. Carl was not sure whether the BOINC version
&gt; would be more or less demanding, and part of the purpose of the project is to
&gt; educate people about climate. None of wanted to unnecessarily exclude people
&gt; just because they could not afford a new machine.
&gt; It may be, though, that the team should do so now, but I don't know whether it
&gt; is practicable for them to establish whether there are underpowered machines
&gt; that are succeeding in running without problems. The other aspect is that
&gt; there are many reasons why WUs might fail repeatedly, besides lack of cycles.
&gt; I think this has arisen in SETI as well. A daily download limit does not
&gt; screen these out and I wonder whether there might not be another solution. For
&gt; example, flagging up those who had exceeded a limit over a longer period.

They seem to have something like it over @Einstein. At least that's the way I read <a href="http://einstein.phys.uwm.edu/forum_thread.php?id=603">this thread.</a>

---

Grüße vom Sänger

&gt; They seem to have something like it over @Einstein. At least that's the way I read <a href="http://einstein.phys.uwm.edu/forum_thread.php?id=603">this thread.</a>
&gt;

Not sure about that. That thread seems to be discussing the rejection of clients that will not complete work before a deadline. That is a very unreliable measure, and anyway the user may well respond by upgrading/leaving their machine on longer/give up when they realise how long a CPDN unit is likely to take. The server cannot have that conversation with the CPDN user!

I seem to recall that there is the facility in BOINC for the server to refuse to allocate WUs to a client with less than the minimum CPU specification, just as it does now if there is insufficient disk space. My concern is whether the project has sufficient information on which to base that limit. Set it too low and it will do little good. Set it too high, and you will rightly get complaints from people who have spent xx months completing a run and who are then told that their help is no longer welcome. It would be sensible to set limits on participation in the coupled ocean or even sulphur experiments, as Les Bayliss suggested, but less powered machines would not be excluded by that from participating altogether. And we would still have the problems of the powerful machines that are still not able to run CPDN, as Les also points out.

---

&gt; I seem to recall that there is the facility in BOINC for the server to refuse
&gt; to allocate WUs to a client with less than the minimum CPU specification, just
&gt; as it does now if there is insufficient disk space. My concern is whether the
&gt; project has sufficient information on which to base that limit. Set it too low
&gt; and it will do little good. Set it too high, and you will rightly get
&gt; complaints from people who have spent xx months completing a run and who are
&gt; then told that their help is no longer welcome. It would be sensible to set
&gt; limits on participation in the coupled ocean or even sulphur experiments, as
&gt; Les Bayliss suggested, but less powered machines would not be excluded by that
&gt; from participating altogether. And we would still have the problems of the
&gt; powerful machines that are still not able to run CPDN, as Les also points out.
&gt;

So it seems for me that there exists only one way to solve this kind of problem: Hosts that causes wus to crash permanently and that never send back trickles are most likely to not fulfil the minimum hardware requirements and should therefore locked out at least temporary from getting further work units.

But on thinking about this I'm asking is this really a serious problem? Perhaps, but perhaps not.

ciao, tom

---

The best source for asking problems with BOINC and the ClimatePrediction client

&gt; &gt; I seem to recall that there is the facility in BOINC for the server to
&gt; refuse
&gt; &gt; to allocate WUs to a client with less than the minimum CPU specification,
&gt; just
&gt; &gt; as it does now if there is insufficient disk space. My concern is whether
&gt; the
&gt; &gt; project has sufficient information on which to base that limit. Set it
&gt; too low
&gt; &gt; and it will do little good. Set it too high, and you will rightly get
&gt; &gt; complaints from people who have spent xx months completing a run and who
&gt; are
&gt; &gt; then told that their help is no longer welcome. It would be sensible to
&gt; set
&gt; &gt; limits on participation in the coupled ocean or even sulphur experiments,
&gt; as
&gt; &gt; Les Bayliss suggested, but less powered machines would not be excluded by
&gt; that
&gt; &gt; from participating altogether. And we would still have the problems of
&gt; the
&gt; &gt; powerful machines that are still not able to run CPDN, as Les also points
&gt; out.
&gt; &gt;
&gt;
&gt; So it seems for me that there exists only one way to solve this kind of
&gt; problem: Hosts that causes wus to crash permanently and that never send back
&gt; trickles are most likely to not fulfil the minimum hardware requirements and
&gt; should therefore locked out at least temporary from getting further work
&gt; units.
&gt;
&gt; But on thinking about this I'm asking is this really a serious problem?
&gt; Perhaps, but perhaps not.
&gt;
&gt; ciao, tom
&gt;

Boinc runs exponential backoff when clients fail to connect to servers to prevent a massive buildup of pent up comms demand swamping the servers when they come back up. Could the maximum number of WU also be made to back off exponentially? I.e. five today, only three tomorrow, just one the next day, another one two days later, and no more for a week, etc. This way, machines that simply chew up WUs would soon be timed out for quite long periods. On the other hand, machines with temporary problems that are quite quickly fixed would soon get back on track.

---

That's an idea, KeeperC.

I thought of something after last posting: Have access to the new models be through a notice page:
First, give an example time for completion on a reasonably fast machine.
Then say that overclocking is known to cause instability in processing, so don't do it.
Recommend that the models be the only dc project running on that computer
etc
Finally, say that the 'standard' model could still be run by those with slow computers.

And insert the button to access the download at the bottom of the page. That way, users would have little excuse
to complain about crashes. Which would probably not stop some. :(

Les