climateprediction.net home page
Posts by old_user1329

Posts by old_user1329

1) Questions and Answers : Unix/Linux : platform \"x86_64-pc-linux-gnu\" not found (Message 30464)
Posted 9 Sep 2007 by old_user1329
Post:
Answered in another section.

There was one person writing this, but (presumably) multiple people reading this.

In the interest of saving \"searching time\" for the visitors, it would have been helpful to put in a pointer to that \'another section\'. [I looked where \"Cpdn news, announcements, and the 4 project READMEs\" points (it\'s the only link in the quoted message), but I did not find information about server updates.]
.
2) Questions and Answers : Unix/Linux : platform \"x86_64-pc-linux-gnu\" not found (Message 29484)
Posted 9 Jul 2007 by old_user1329
Post:
Sorry Mikus. No anonymous either. I don\'t know what will be acceptable when the software gets updated, or when that will happen.


In that case, where do I file a bug report about this ?


I think that there are numerous people who would like to use a 64-bit boinc client with Climate Prediction. If the existing Climate Prediction servers support neither a \'x86_64\' platform nor an \'anonymous\' platform, that __forces__ participants in the Climate Prediction project to use a 32-bit boinc client. At the least, Climate Prediction should upgrade its servers to the latest boinc version (which supports <alt_platform>).

I think limiting Climate Prediction participants (particularly if they have an otherwise-state-of-the-art system) to no other choice than using a boinc client compiled for 32 bits -- that is a bug.
.
3) Questions and Answers : Unix/Linux : platform \"x86_64-pc-linux-gnu\" not found (Message 29483)
Posted 9 Jul 2007 by old_user1329
Post:
Running a 64-bit system does not mean that one has to use the 64-bit boinc client. Before the linux 64-bit boinc client became available, I was using the berkeley linux 32-bit boinc client on my 64-bit Ubuntu 7.04 system (which *does* have the 32-bit compatibility libraries installed). Since my boinc client then was 32-bit, it identified its platform as \'i686-pc-linux-gnu\' -- and the various projects downloaded their corresponding 32-bit linux application executables.

[In fact, I was able to use the app_info.xml facility \"in reverse\", requesting the ABC project to download its native 64-bit application executables (which ran faster!), even though the boinc client I was using to run those applications was only 32-bit.]

[Note: The current 64-bit Linux BOINC package from berkeley, while it supplies a 64-bit \'boinc\' executable, includes only a 32-bit \'boincmgr\' executable. So it appears that \"mix and match\" is being officially blessed.]

mikus



p.s. Forgot to mention that with app_info.xml , it is the _user_ at the target system who specifies *which* executables to download. This *bypasses* \"automatic\" updating of executables by the project. The _user_ has to track the application versions available from the project, and has to manually change app_info.xml each time that newer executables become available.
.
4) Questions and Answers : Unix/Linux : platform \"x86_64-pc-linux-gnu\" not found (Message 29481)
Posted 9 Jul 2007 by old_user1329
Post:
On my system with 64-bit SuSE 10.1, I\'m currently running Climate Prediction using the berkeley 32-bit linux client. But when my current workunit finishes, I\'m planning to switch to using the 64-bit linux client (which recently became available). At that time, I will be faced with the same problem you now have.

What I am planning to do is to create an app_info.xml file -- the description can be found on http://boinc.berkeley.edu/trac/wiki/AnonymousPlatform . When this file is put into the ./BOINC/projects/climateprediction.net/ directory (I\'m describing linux here), the client (after being restarted) identifies its platform as \'anonymous\' instead of as \'x86_64\'.

I am assuming that the Climate Prediction servers support a platform being reported as \'anonymous\'. If not, both you and I would be out of luck trying to use the 64-bit boinc client with Climate Prediction.

mikus



p.s. On my 64-bit Ubuntu 7.04 system (which *does* have the 32-bit compatibility libraries installed), I *am* currently using the 64-bit linux client with the Einstein project, which (same as Climate Prediction) does not \"find\" the \'x86_64\' platform. FYI, the actual app_info.xml file that I have supplied for the Einstein project is:

<app_info>
<app>
<name>einstein_S5R2</name>
</app>
<file_info>
<name>einstein_S5R2_4.21_i686-pc-linux-gnu</name>
<executable/>
</file_info>
<file_info>
<name>einstein_S5R2_4.21_i686-pc-linux-gnu.so</name>
</file_info>
<app_version>
<app_name>einstein_S5R2</app_name>
<version_num>421</version_num>
<platform>x86_64-pc-linux-gnu</platform>
<file_ref>
<file_name>einstein_S5R2_4.21_i686-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>einstein_S5R2_4.21_i686-pc-linux-gnu.so</file_name>
</file_ref>
</app_version>
</app_info>

.
5) Questions and Answers : Unix/Linux : Deleting crashed results in profile (Message 17027)
Posted 7 Nov 2005 by old_user1329
Post:
Because of the long times involved in this project, where there is a possibility that they may be still waiting on a computer to be processed, they stay there for a few years, as do unused computers.


That is reasonable for how the __server__ behaves.

However, if the __participant__ knows that there is ZERO chance that any results will ever be submitted for an assigned but wiped_out/crashed workunit, there ought to be a way to either:

(1) RETURN the workunit to the server, for it to dispose of as it will, or
(2) REFETCH the workunit starting data, so that the original assignee can try working on it again, from the beginning.
.

6) Questions and Answers : Wish list : Recycling WUs (Message 16503)
Posted 9 Oct 2005 by old_user1329
Post:
Data sets are marked for re-assignment by the server if there is no message from the model, (i.e. a trickle), for about 6 weeks.

So the models in your list may have been given to someone else by now.

What you say leads me to believe that CP was not held back by me being unable to work on these WUs.

But although CP __never__ received any trickles from me for these WUs, they are STILL shown as \"In process\" in my \'Results\' list. Why show them there, six months without trickles later, if they HAVE been re-assigned to someone else by now ?

This situation still makes me WISH that I could from the __webpage__ \'re-cycle\' WUs (for which NO trickles have ever been received by CP) to either myself or back to the CP pool. These never-handled-by-me WUs do NOT belong in my \"In process\" list.
.
7) Questions and Answers : Wish list : Recycling WUs (Message 16492)
Posted 8 Oct 2005 by old_user1329
Post:
Half a year ago I had trouble communicating between client and server, and dropped out from doing processing. I\'ve now started participating again. I notice in my \"Results List\" that there are a LARGE number of WUs assigned to me from that time as \"In process\". I either never received those WUs, or else lost them completely at my end.

I WISH there was a way for me, from the __webpage__, to either \'recycle\' those WUs back to the \"generally assignable\" pool at the server; or else for me myself to RE-FETCH those WUs with my current client setup.

mikus
8) Questions and Answers : Unix/Linux : no work from project (Message 9915)
Posted 24 Feb 2005 by old_user1329
Post:
Did not think this could be involved here, but I just had trouble doing a "shutdown" -- so it might be a hardware problem, after all.

It sure would be nice if somewhere I could look up what error code 251 meant.
9) Questions and Answers : Unix/Linux : another restart for me (Message 9914)
Posted 24 Feb 2005 by old_user1329
Post:
Don't understand how this could arise, but I'll assume that something has gone wrong with the hardware on my system. Just had trouble completing a "shutdown".

10) Questions and Answers : Unix/Linux : no work from project (Message 9892)
Posted 24 Feb 2005 by old_user1329
Post:
Got the message "no work from project -- daily quota exceeded".

The last three or so days my system has spent mostly idle. [It's sitting there doing nothing right now.]

A number of workunits have been downloaded to my client, but they all have quickly failed with error code 251. [WHAT CAUSES THIS ERROR ?]

----

I am trying to be a "good faith" participant. From my perspective, it is the *software* I downloaded that has had problems (error code 251). But now the project appears to be penalizing *me* because it is on my system that the software problems show up.

I guess the project was set up to run in a "perfect" world. And users whose experience is not "perfect" are to be shunned. [What a way to run a railroad!]

mikus (4.19, AMD CPU, Suse 9.2]

11) Questions and Answers : Unix/Linux : another restart for me (Message 9820)
Posted 23 Feb 2005 by old_user1329
Post:
Once again the __new__ model got error code 251. [WHAT CAUSES THIS ERROR??] And there appears to be a server problem - so now the Oxford end won't talk to my system.

Before joining CPDN, I *carefully* read its notices, and saw that it claimed to be suitable for dial-up users. But the situation I have now gotten myself into -- server doesn't seem to be up; client is sitting there idle; the next communiction attempt from my client to the server has been schedules for three hours from now -- LEAVES ME ANGRY.

[What a way to run a railroad!] I am *not* going to set my alarm clock for four am just so I can then dial up so the client can make its (futile?) next scheduled attempt to contact the server.
12) Questions and Answers : Unix/Linux : another restart for me (Message 9760)
Posted 22 Feb 2005 by old_user1329
Post:
I run __OFFLINE__. BOINC does not give me the controls I need to communicate client-&gt;server. And BOINC does not even explain how to use the few options it does provide. [Running 4.19 on an AMD CPU, SuSE 9.2]

Once before my client got into a state where it was unable to communicate with the server. I ended up detaching from CPDN. One of the gurus said: "you should not have done that". Well -- what SHOULD I have done? I'm sitting there with an idle machine, and a client that is unable to communicate with the CPDN server. Once again, my question is "what should I have done?"

Just now, the whole scenario repeated itself. The client (I presume at the end of phase II) crashed with error code 251. [WHAT CAUSES THIS ERROR??] When I intervened manually, I got only the familiar "No server responded" messages. Trickles had already been deferred 'til sometime later in the week. The model results upload kept rescheduling itself for ever-longer intervals. In other words, my machine was sitting there idle, and it FAILED every time it tried to communicate with the CPDN server. [By the way, what the client was valiantly attempting to do was to fetch more work -- let me suggest that UPLOADING the results is more important to the project.] Looking at the whole mess, I said "to HELL with it" and detached from CPDN (thereby wiping out a fortnight's worth of trickles and results). TOO BAD !!!
13) Message boards : Number crunching : Model 346646 uploaded, but not Complete (Message 8648)
Posted 4 Feb 2005 by old_user1329
Post:
Loch Dhu asks: Mikus says something about a "follow on trickle". What is this?

I was referring to the post on 2 Feb by 'mavau', who says:
&gt; When I finish a model it stays in 'work' in the BOINC GUI till the next time
&gt; it connects (at the first trickle from the next model). That's when the result
&gt; changes to completed.

[By the way, in my case because the '-attach_project' wiped out the client's knowledge of the previous workunit, that model's status at the server NEVER changed to completed, although I've now uploaded the first trickles from the next model.]


Comment to the post on 3 Feb by 'mavau': I'm running Linux (CLI interface). I have __no__ GUI file menu in which to check/uncheck settings. And on Linux, the ONLY (as far as I know) update option I have is '-update_prefs' -- the trickle update schedule seems to be unaffected by that option.
.
14) Message boards : Number crunching : Model 346646 uploaded, but not Complete (Message 8513)
Posted 3 Feb 2005 by old_user1329
Post:
I'm a dial-up user. Running Linux (CLI interface). Often, there is no connection when the client wants to communicate with the server, so the client *schedules* another communication attempt at a future time.

Something (I don't know what) went wrong, such that client uploads of trickles were no longer successful. (Instead, a message was typed by the client: "No server responding".) But the client dutifully kept __scheduling__ "contact" times, the last of which happened to be a week in the future.

I let the workunit complete phase 3. When my computer went idle (it couldn't successfully download new work, either) I manually restarted with '-update prefs' -- that resulted in the five results files being uploaded.

When I couldn't "brute force" the client to upload its stacked-up trickles (it still gave me "No server responding"), I detached from the CPDN project, then re-attached. That threw away all previous trickles, etc., but re-downloaded the hadsm3 stuff. The client is now running (without any problems, as far as I can tell) on a new workunit.

--------

My reason for posting is: The present BOINC design places undue importance on the transmission of trickles. Even if I did not have the upload problem, I would have had to wait a WEEK for the servers to finally mark the previous unit as 'complete'. PLEASE, PLEASE, PLEASE, when the final results files have been uploaded, do the processing for 'complete' then and there. As my case showed, there may __never__ occur that "follow-on" trickle on which the present BOINC design depends.
.
15) Questions and Answers : Unix/Linux : no server response (Message 8331)
Posted 1 Feb 2005 by old_user1329
Post:
I really have NO IDEA as to what was going on. Typing what you said into a browser got the response you said - but the CPDN client would NOT complete any transfers - it always claimed "no server responded" and waited some more.

I let things run until my computer went idle (because phase 3 had finished). Then I restarted with -update_prefs, which allowed it to upload the five results files. I manually changed client_state.xml to "short-circuit" its wait, but it STILL claimed it had no server response, and did not send the accumulated trickles.

I said "enough of this", and detached from the CPDN project. When I re-attached, the client made no mention of any leftover trickles.

Applications that "require no user input" are fine if they work, but when things go wrong they are a bitch. '-update_prefs' is NOT enough, when it does not FORCE a "stuck" trickle to become "unstuck".
16) Questions and Answers : Unix/Linux : no server response (Message 8078)
Posted 29 Jan 2005 by old_user1329
Post:
I'm on a dial-up line. For more than a day now, whenever I am connected to the internet and my client attempts to connect, that attempt fails for lack of a response from the server end.

Typical console messages:

Scheculer RPC to http://climateapps2.oucs.ox.ac.uk/cpdnboinc_cgi/cgi failed.
No scheduler responded

I tried manually 'ping' to the above site and to climateprediction.net. No response there, either. I don't know if you have 'ping' turned off, or if the path is down.

mikus
.
17) Questions and Answers : Unix/Linux : Unrecoverable error code 251 (Message 7218)
Posted 8 Jan 2005 by old_user1329
Post:
This just occurred again. WHAT CAUSES THIS PROBLEM ??

Previous time was when the running workunit had finished phase two. This time it was when the running workunit had finished phase three.

The waiting workunit (the one that is supposed to be started when the previous workunit is complete) is terminated with code 251 before it has accumulated any run time.

The computer is either totally off-line, or its connection to the internet is congested. Using BOINC 4.13, AMD Barton, SuSE 9.2.

mikus
.

18) Message boards : Number crunching : Excessive deferred communications (Message 7059)
Posted 24 Dec 2004 by old_user1329
Post:
&gt; &gt; Chilcotin:
&gt; &gt; Sorry, I'm running a Mac, so I'm running command line - no GUI. Should
&gt; have
&gt; &gt; mentioned that earlier...
&gt; &gt; C
&gt;
&gt; stop BOINC, then start it from the command line as usual, only with the
&gt; switch
&gt;
&gt; -update_prefs http://climateprediction.net
&gt;

On Linux, '-update_prefs' will send any files the client has ready, but will NOT affect any trickles the client has accumulated. After I've done the start with '-update_prefs', the Linux BOINC V4.13 client __still__ continues the "Deferring communication for 4 days ..." countdown.

mikus
.
19) Questions and Answers : Unix/Linux : My computer goes to idle (Message 5283)
Posted 12 Oct 2004 by old_user1329
Post:
Since I had not received any information that would have helped me with this problem, I decided to start all over again with a clean slate. I detached from the project, and erased all the climateprediction-related files from my harddisk. I then forced a new download of all the files used by the client. Although I had never been overclocked, I deliberately reduced the clock frequency of my AMD Barton chip.

I have now been running more than 24 hours without the climateprediction client going into an idle state. Hopefully, I've made the problem go away.

mikus
20) Questions and Answers : Unix/Linux : My computer goes to idle (Message 5126)
Posted 7 Oct 2004 by old_user1329
Post:
Happened to look at 'top'. This time there was __no__ hadsm3um_4.04_i process - neither running nor defunct. But stderr had a "deferring communication for 21 minutes 43 seconds" message. NOTE: the previous message (in same interval of there being no path to the server) was "deferring communication for 37 minutes 15 seconds". Meaning that the client had REDUCED the "deferring" amount (presumably at the time hadsm3um_4.04_i vanished).

Although my system was idle, I decided to wait until the end of the "deferred" 21 minutes. (In the meantime I set up the relay to the server, which had not existed in the preceding three hours.) When the "deferred" period expired, the client communicated with the server and started a new hadsm3um-4.04_i process.

Curiouser and curiouser.

mikus


Next 20

©2024 climateprediction.net