There is no quick return bonus at Rosetta — only at F@h. (GPUGrid has a QRB too, but not as finely grained as F@h.)10 work units required before the bonus starts to kick in
In Unix and Linux, processes have a "niceness" value assigned, which determines scheduling priority. The higher the niceness = the nicer the process is towards the rest of the system, the more often it is going to be preempted by other processes which need processor time and are not as nice. -> some more infoWhat's nice'd tasks?
BOINC, by default, launches the science applications as "nicely" as possible, with niceness +19.
They aren't really separate: Boinc client (default name of the binary:I didn't know that the boinc service was separate from the boinc client.
boinc
) can be launched manually; but practically all Linux distributions provide launching mechanisms via their systems services facility, a.k.a. init system, which is often based on systemd
these days.Separate from the client, i.e. from
boinc
, are the programs which are used to control the client:boincmgr
, a graphical control interface developed together with the client; typically also installed when the client is installed (but some distributions have it in a separate package),boinccmd
, a command line interface which is able to show a subset of client status, and to send a subset of control directives to the client; good for scripts but also for ad hoc control from the command line; developed together with the clientBoincTasks
, a 3rd party graphical control interface, available for Windows but can also run on Linux+Wine, sets itself apart from boincmgr with much better support for simultaneous control of multiple clientsboinctui
, a 3rd party control interface with text UI, for when you need something much like boincmgr but are limited to a text terminal
No; the Rosetta developers take care that useful work is done within any of the target CPU times which the user can choose, on slow hardware or fast hardware.Is their an optimal time beyond which useful science diminishes?
They are interested in short turnaround from when a WU is sent out to when the result comes back. But they still allow for 8 days turnaround, set in the task deadline. Sometimes they get a little impatient and create a duplicate task for an as yet unfinished WU, such that somebody else may return it earlier than the original host which may still be processing it. But both hosts will receive credit when they return a good result, regardless of which one completes it earlier. (source)
BTW, one thing which I wasn't aware of myself until now: When the target CPU time is changed at the user web page, and a project update is issued to the client or the client sends a scheduler request for other reasons, the target CPU times of all already downloaded tasks are adjusted, along with the target CPU times of yet to be downloaded tasks. (source)
If you have a need for a cc_config.xml, then I suggest you populate it only with the options which you really need to change, and maybe a few which you don't want to change but still want to document the current values this way.Do you have a full sample config file? cc_config.xml does not exist in the RHEL install (guessing it doesn't exist in the fedora one either).
I need to go look for a complete file with defaults. In the meantime, here is the link to the documentation once more.
Avoid running the client as root. Remember, it downloads random stuff from the internet. Therefore, best practice is to run it with the user ID of an unprivileged pseudo-user. Virtually all distributions set it up this way by default.I would first verify that everything is working with the client:
systemctl status boinc-client
Also, if you haven't explicitly given yourself permission to run the boinc executables (i.e., you run them as root), they need to be run from /var/lib/boinc. So either cd to that directory before running or use, e.g., boincmgr -e /var/lib/boinc.
The
systemctl
and service
commands however can safely be run as root. Furthermore, it is safe to run boincmgr
from your main user account.Actually, it works as follows:They always have a relatively steady "ready to send" count, and it is generally much lower than the "in progress" count. Therefore I believe they are constantly generating new jobs. But I am seeing more "No tasks sent" messages in the client logs now, which I think means that the rate of requests for new work is beginning to outpace the rate of work generation. [...]
PS,
serverstatus shows 0 tasks ready to send at this moment.
``The tasks ready to send are indeed the tasks ready to send by our feeder daemons. We try to keep this buffered to at least 15,000 or so whereas the actual queue that researchers submit to is not part of BOINC and is not shown to users other than the "Total queued jobs" on the R@h homepage. When this "tasks ready to send" buffer starts to reduce as it has been mentioned by the attentive participant, that means our internal queue is also low. This may happen from time to time as mentioned in my last post. These stats do not get updated frequently. The server status should be updated hourly so there may be a slowdown gathering the data as you note. The homepage status should be updated every 4 hours.``
(source)
Last edited: