Questions and Answers :
Unix/Linux :
another restart for me
Message board moderation
Author | Message |
---|---|
Send message Joined: 26 Aug 04 Posts: 24 Credit: 857,133 RAC: 0 |
I run __OFFLINE__. BOINC does not give me the controls I need to communicate client->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 !!! |
Send message Joined: 5 Sep 04 Posts: 7629 Credit: 24,240,330 RAC: 0 |
The Oxford upload server has been offline since Thursday. The problem is being discussed <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=1963"> here</a>. Les |
Send message Joined: 26 Aug 04 Posts: 24 Credit: 857,133 RAC: 0 |
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. |
Send message Joined: 17 Aug 04 Posts: 753 Credit: 9,804,700 RAC: 0 |
BOINC (it's not the CPDN element) has caused frustration to dial up users, and I'm not clear whether all the problems have been fixed in the forthcoming release. As DC projects go, CPDN is better suited to dial up than most. As for the problem with one server, I share the feeling but they have been much more reliable than other projects so far. |
Send message Joined: 26 Aug 04 Posts: 24 Credit: 857,133 RAC: 0 |
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". |
Send message Joined: 16 Aug 04 Posts: 156 Credit: 9,035,872 RAC: 2,928 |
There is a workaround for this irritating "deferring...blahblah.." Stop the client. Open client_state.xml with a text editor. Go down 53 lines to min_rpc_time and change the value to 0(zero). Start the client and it will connect immediately. I do this nearly every day. I can't understand why they don't fix this :-[ |
Send message Joined: 5 Aug 04 Posts: 1283 Credit: 15,824,334 RAC: 0 |
> There is a workaround for this irritating "deferring...blahblah.." > > I can't understand why they don't fix this :-[ It's a bug in BOINC 4.19 which has been fixed in the development version. But you won't be able to download work for CPDN if you switch to using that version because it requires file signatures on all downloads (only the controller program for CPDN has one at the moment, and that'll continue to be the case until the server side BOINC software is rebuilt using the BOINC development source). Full discussion is in <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=1955">this thread</a> if you need further background information. "The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer |
Send message Joined: 16 Aug 04 Posts: 156 Credit: 9,035,872 RAC: 2,928 |
Thanks Thyme Lawn, sounds good :) |
Send message Joined: 16 Aug 04 Posts: 156 Credit: 9,035,872 RAC: 2,928 |
> > There is a workaround for this irritating "deferring...blahblah.." > > > > I can't understand why they don't fix this :-[ > > It's a bug in BOINC 4.19 which has been fixed in the development version. But > you won't be able to download work for CPDN if you switch to using that > version because it requires file signatures on all downloads (only the > controller program for CPDN has one at the moment, and that'll continue to be > the case until the server side BOINC software is rebuilt using the BOINC > development source). > > Full discussion is in <a> href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/forum_thread.php?id=1955">this > thread</a> if you need further background information. > Nah, I checked out your link and that is about proxies and a bug in 4.19. What I mean is that the Linux client never have had offline possibilities like in Windows where you truly can crunch offline by "suspend network activity" then activate it and make "update" to send in your trickles. This has been a problem and complained about since August. BTW Team Picard come on now, Phoenix Rising is soon out of sight:) |
Send message Joined: 5 Aug 04 Posts: 1283 Credit: 15,824,334 RAC: 0 |
> Nah, I checked out your link and that is about proxies and a bug in 4.19. > What I mean is that the Linux client never have had offline possibilities like > in Windows where you truly can crunch offline by "suspend network activity" > then activate it and make "update" to send in your trickles. > This has been a problem and complained about since August. The bug wasn't actually anything to do with proxies. It was traced to a particular variation in the HTML sequence that caused BOINC to fail to parse the scheduler reply correctly. Proxies were originally implicated because users sitting behind them tend to have more machines running BOINC where the problem might be spotted (and are, arguably, more likely to do so than casual users). It was particularly apparent in the sulphur cycle alpha trial, where the participants obviously had a closer eye on what was going on than normal. > BTW Team Picard come on now, Phoenix Rising is soon out of sight:) Ooooo, another taunt :D "The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer |
©2024 cpdn.org