Subject: Re: Connections to ssl.berkeley not propagated yet?
From: Patrick Vervoorn
Date: 28/07/2005, 08:57
Newsgroups: alt.sci.seti

In article <dc9jvv$7b8$1@green.home>,
John F Hall <jfh@avondale.demon.co.uk> wrote:
In article <a2a91$42e7835f$82a1d3bf$17190@news1.tudelft.nl>,
Patrick Vervoorn  <patrick.vervoorn@NOSPAM.perihelion.demon.nl> wrote:

- Why did SetiBOINC not process the WU's it had already downloaded? This 
  is a P3-733MHz machine, so those 3 WU's should have lasted it for at 
  least a day or two. Instead it decided to just sit there idling, and 
  periodically checking the Berkeley site for 'something'?

Have you checked the log?  It's quite likely that they had already been
processed, their results uploaded, and your system was waiting to tell
the scheduler, after which they would be deleted.

Which log do you mean? I didn't see anything resembling a log file in the 
local BOINC/ directory, so I assume you mean the 'log' displayed under the 
'Account' tab on SetiBOINC's website; there it showed the units had been 
sent out, but no results had been returned, so also the 'Pending validaton 
...' text was not there (which would've been an indication the WU's had 
been processed, the results returned, and I only had to wait for these 
results to be validated...

As far as I could determine, these WU's had been downloaded by me, but 
nothing had been returned and/or processed.

- When I look at my Account page, I see those 3 WU's being listed as sent 
  out for that particular machine, but since I deleted them locally, the 
  results will never be returned. Is this a problem? Is there also a way 
  for me to redownload those WU's?

Too late now.  You've prevented the upload of those results being
registered with the scheduler.

Hmmm, ok, too bad. Then the SetBOINC people will have to learn to live 
without that. :)

Anyone know of a solution for the above?

I do hope this doesn't happen more often, because it's quite a hassle. :(

Yes.  Don't interfere, but let "Deferring communication with project for
..." run its course.  :-)

I'll do that next time, but this is more or less against my principles: 
I'm donating some CPU time (I have more computers running BOINC), but when 
one of them for some fuzzy reason decided to go idle, I try to fix this, 
especially if after some investigation, it turns out there is no real 
reason to idle...

But also make sure you're running boinc with the
"-return_results_immediately" flag if you're not already doing so, and
make sure your cache size is set large enough (mine is set to 4 days).

Does that flag make a lot of difference? If I look at the stdout output 
from BOINC, it seems it's returning results rather quickly already:

2005-07-28 09:32:41 [SETI@home] Computation for result 
13mr04aa.15943.30386.29822.119_1 finished
[....]
2005-07-28 09:32:42 [SETI@home] Sending scheduler request to 
http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
2005-07-28 09:32:42 [SETI@home] Started upload of 
13mr04aa.15943.30386.29822.119_1_0
2005-07-28 09:32:43 [SETI@home] Scheduler request to 
http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
2005-07-28 09:32:44 [SETI@home] Finished upload of 
13mr04aa.15943.30386.29822.119_1_0

So that's about a 1 second delay...

And, how do I set up the cache to cache up to 4 days of work? Is this done 
by some fiddling with the 'contact SetiBOINC every ... hours/days'? If so, 
what value do I put there?

Regards,

Patrick.