In article <dcakd4$th0$1@green.home>,
John F Hall <jfh@avondale.demon.co.uk> wrote:

In article <51c9b$42e89002$82a1d3bf$3947@news1.tudelft.nl>,
Patrick Vervoorn  <patrick.vervoorn@NOSPAM.perihelion.demon.nl> wrote:

Ah, on looking deeper I see it's the standard output of boinc.  My
startup command, buried deep within /etc.rc.d/rc.boinc, captures that:

[some snippage]

I usually have a "tail -f boinc.log" running on one of my virtual
terminals to keep an eye on what's happening :-).  (I've upped the
inittab commands to give myself 10 such, rather than the default 6.)

Ah, OK, I see what you mean. I'm running BOINC as a 'normal' user on 
several Linux machines. Only for one of those (the one at home, and at 
which one this problem occured) do I have the rights to fiddle with the 
etc.rc/etc files.

Since I don't want to mess with that, I'm running them in screen 0 of GNU 
screen sessions, which worked quite nicely for setiathome (I ran the plain 
command-line version), and will probably (hopefully) work even better with 
BOINC and it's built-in caching-mechanism...

There's also relevant info in the client_state.xml file, though I
haven't fully analysed that.

I've browsed through, but in it's 'raw' form it doesn't seem to meant for 
a human being. Perhaps with some XML processing something useful could be 
made from it.

I'd better start by saying I'm only another user, so everything I say is
found by observation and by my struggles to get it running as I want,
not by special knowledge.

No problem; I'm also just a simple user, who recently decided to switch 
from classic Seti (user since the end of 1999) to BOINC, because I had the 
idea classic was going to end 'Real Soon Now'.  It actually still hasn't 
ended, but I've removed all traces of it from all of the systems I was 
running it on, except for a lowly P1-133 which is deemed not powerful 
enough (not enough memory) by the BOINC schedular (it has 64MB, but that's 
before Windoze 98 loads).

The processing sequence seems to be:

[info snipped, I agree, that's my impression also]

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:

Before I included that flag I found that the final step of contacting
the scheduler didn't seem to start until the cache was drained a bit (to
half-full?).  The documentation (boinc_public/doc/client_unix.php) says:

 "-return_results_immediately",
     "Contact scheduler as soon as any result done."

Perhaps this behaviour becomes more promiment once I increase the 
cache-size.

Presumably it depends on how big a cache you're running.

I'll increase it, and see what happens. :) If I see significant delays in 
returning results, I'll modify my invocations of BOINC with the 
"-return_results_immediately"-flag.

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?

Under the "general preferences" on the "your account" web page there is
a "Connect to network about every:" question.  I have set it to 4 days,
which seems for me to give a reasonable compromise between having
workunits in reserve and not being the last in returning them.  I used
to run classic with a 20 workunit cache, about a week, but after
experimenting I settled on 4 days for boinc.  The effect seems to be
that the cache is topped up every time the cache is half empty - about 5
or 6 units every two days.  If a breakdown happened at the wrong time I
would just have 2 days work and could run out, but that hasn't happened
yet - if it did I suppose I would change to 5 days :-).

Does it even do the above if you enable the "-return_results_immediately" 
flag? I'd expect it to then top-up the cache to 4 days of work when it 
contacts the scheduler to return a resulst? I.e., you maintain a cache 
filled with 4 days of work.

When you change that setting it won't take effect until you next contact
the scheduler.  There are ways of forcing a connection, but if you've
used the return_results_immediately flag that will be next time a
workunit completes which should be soon enough (as long as seti is the
master project).  If you're running more than one project, it's the one
defined as the "master_url" in the client_state, and as "master.html",
that matters - that should be the project you started first, as long as
you didn't stop it.

I'm in no hurry to see the changes to this, all machines are currently 
crunching along quite happily. But after I finish typing up this response, 
I'll visit my account page and change the mentioned value, and start 
observing what my SetiBOINC machines are going to do. :)

I've tried to see where I got my boinc.rc from.  I seem to have got an
"init.d-boinc" that is Red Hat specific from somewhere, and hacked it to
form a "boinc.rc" for my Slackware system.  If it would help I can email
you copies (my email address above is valid).

Mine is also valid (minus the NOSPAM), so feel free to mail it. Since I 
can only implement this on one of the Linux machines, I'm not sure I'm 
going to implement it. But it will hopefully be helpful and enlightening 
to see it. :)

I hope this all helps :-).

Going to do some testing right away! :)

Regards,

Patrick.