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

In article <dcd6ot$gou$1@green.home>,
John F Hall <jfh@avondale.demon.co.uk> wrote:
In article <7b429$42e9f2ee$82a1d3bf$25024@news1.tudelft.nl>,
Patrick Vervoorn  <patrick.vervoorn@NOSPAM.perihelion.demon.nl> wrote:

No delays in sending back results yet, and I'm running BOINC without any 
special command-line switches. But as you yourself commented in your 
email, you were running an older version, so perhaps this is something 
which was changed (fixed? :) in the newer version.

Interesting.  I've done a quick grep of the source and I see a
declaration "bool return_results_immediately", I see it being set in the
command line processing when there is a "-return_results_immediately",
but I don't see it ever being tested :-).  In the previous source it was
tested in the scheduler code.

The changelog says:

 20 May 2005
   - removed "high_priority" and "return_result_immediately" attributes
       from RESULT (no changes like this without discussion!)

I'm not sure what that means.  It looks as though that flag has gone -
but will it come back?

I haven't delved deep enough into the BOINC sources to be able to comment 
on this, but looking at BOINC's behaviour on all my machines (I checked 
the stdout output of most of the clients I have running to see how my 
configuration change turned out), it seems they all return results 
immediately, and also top-off the cache when they return something.

So in my case, it looks like I always have ~4.0 days of WU's in the cache 
for all clients.

Nice, I like it that way.

I'm also running happily with 4.43, and have returned a result.  However
I haven't had a cache-fill yet - I waiting to see how much it says it's
asking for and how much it fetches.

I think I saw the clients requesting about 300,000 (a bit more) seconds of 
work when the next schedule event was executed...

Regards,

Patrick.