how i can send completed WU on linux? on windows is verys simple... but in linux?

---

http://boinc.berkeley.edu/client_unix.php
<p>
http://noether.vassar.edu/~myers/help/boinc/unix.html
<p>
in german

http://boinc.de/bslinux.htm

To elaborate a bit: You dont have to do anything manually - it will be sent automatically at some poin (usually when the client requests new work).

But the links that Guido provided are good in the case where you want to force the report to be sent.

To send results automatically as soon as they're processed, use:

./boinc -return_results_immdeiately

I'm not sure if the will return any results already waiting immediately or when the next result finished, but I run with this switch all the time.

Also,

./boinc -update_prefs http://setiathome.berkeley.edu

will do like it says, update your prefs. Similar to the update command on the gui in windows I assume.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

boinc sends the result back when the wu is finished. it doesn't wait for something.

the result will not be shown in the statistic until you connect to the scheduler with ./boinc -update_prefs http://setiathome.berkeley.edu

---

> boinc sends the result back when the wu is finished. it doesn't wait for
> something.
>
> the result will not be shown in the statistic until you connect to the
> scheduler with ./boinc -update_prefs http://setiathome.berkeley.edu

Ultimately, BOINC runs quite happily without any switches whatsoever. "Ready to report" WUs will get cleared up as soon as the client connects to request more work. That's good enough for me. Why people feel the need to force connections all the time is beyond me.

Back-off periods and the like are all built into the client to ensure that when a project has some hiccups, clients will reconnect in a staggered fashion (and not overwhelm the server in the process). Letting BOINC clear up its "Ready to report" units is similar because it reduces the number of overall server/database connections required to process all of the client's RPCs.

My suggestion is to just sit back and watch the client do its thing. It really does know what's best, and a few hours of "dead time" sure won't bother your computer's fans!

---