In article <73182$42e8e099$82a1d3bf$9377@news1.tudelft.nl>,
Patrick Vervoorn  <patrick.vervoorn@NOSPAM.perihelion.demon.nl> wrote:

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.

I also have "boinc" as a user that runs the boinc and seti programs, and
I login as boinc to monitor what's happening, but the program is started
by root using, as I said:  su boinc -c "...".

The same scripts without that would run as the normal user, though it
might be a good idea to include a "nohup" so that it isn't stopped if you
logout.  You could also 'if [ "$UID" = "0" ] ; then ...' or similar to
choose the right start-up command :-).

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.

Quite - that's why I didn't tell you what it meant :-).

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.

If you try it with and without you'll see the difference.

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.

No, the caching makes quite separate scheduler calls from those
returning results:

  2005-07-26 23:36:14 [---] May run out of work in 4.00 days; requesting more
  2005-07-26 23:36:14 [SETI@home] Requesting 343675 seconds of work
  2005-07-26 23:36:14 [SETI@home] Sending request to scheduler:
    http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
  2005-07-26 23:39:23 [SETI@home] Scheduler RPC to
    http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed
  2005-07-26 23:39:23 [SETI@home] No schedulers responded

Well, that was when the scheduler went and hid at a different address
:-).  Eventually:

  2005-07-27 18:03:35 [---] May run out of work in 4.00 days; requesting more
  2005-07-27 18:03:35 [SETI@home] Requesting 478754 seconds of work
  2005-07-27 18:03:35 [SETI@home] Sending request to scheduler:
    http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
  2005-07-27 18:03:36 [SETI@home] Scheduler RPC to
    http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded

Note that when it did connect, it had decided it needed more :-).
Actually I see those are 3.97 days and 5.54 days, so perhaps I've got it
wrong.  It looks as though it wants to top up to 6 days work, and then
to top up again when the cache has dropped to the minimum 4 days.  Yet
that time it downloaded 8 units - 72 hours - and that is all I currently
have in my cache apart from the one being processed which is older.  I
expect there to be more downloads soon :-).  Something doesn't quite add
up - I guess I'll look at the program source sometime :-).

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. :)

OK.  I'll leave you to digest them and see what you need to do for your
system.  I assume you're familiar with shell and bash scripts.

-- 
John F Hall