check the Linux (in general) section for start/stop commands. scroll down to the Ubuntu/Debian section to turn off running BOINC at boot time completely.
Well that doc is quite a bit out of date. The daemon that starts boinc-client and boinc-manager isn't provided by init.d anymore.
On Ubuntu and modern OS, daemons are handled by systemctl. So the commands to start and stop turn into:
sudo systemctl status boinc-client (outputs like running, dead, stopped along with pertinent bits of the client's log)
sudo systemctl start boinc-client (starts a stopped daemon, does NOT cause a disabled daemon to autostart at boot time)
sudo systemctl stop boinc-client (stops a running daemon, does NOT prevent an enabled daemon from starting at boot time)
sudo systemctl enable boinc-client (causes daemon to autostart at boot time, does NOT stop a running daemon)
sudo systemctl disable boinc-client (prevents daemon autostart at boot time, does NOT halt a running daemon)
Know there is some limit on the number of tasks the project will allow.
Don't know what it is. But supposedly you can tell the project you have more cpus than you actually do and it allows the project to send you more work.
Change the <ncpus>-1</ncpus> line in the cc_config.xml to <ncpus>256</ncpus> and save the file and then re-read the config files in the Manager.
Know there is some limit on the number of tasks the project will allow.
Don't know what it is.
256*Number of GPUs + 32*Number of CPUs
Quote:
Change the <ncpus>-1</ncpus> line in the cc_config.xml to <ncpus>256</ncpus> and save the file and then re-read the config files in the Manager.
But there are maximum numbers, and 256 is way over the maximum number of CPUs which will influence the daily task quota calculation. I think the actual limiting value is 64, or something quite near that. I think there is also a GPU maximum, maybe 8? 256 for ncpus in particular is far beyond the actual supported range for this purpose.
There is also a qualification with a word something like "available", which turns out to mean that if you limit the number of CPUs you advise BOINC to consider available to start tasks on using the Einstein web site Preferences|Computing|Processor Usage|Use at most nn% of the processors mechanism, then the daily quota calculation will reduce the number of CPUs considered to be present.
People using this should be aware that since you are instructing BOINC to consider that it can start more tasks, that if you run CPU work and don't have another constraint mechanism in place, BOINC can indeed launch more Einstein CPU tasks than you have appropriate processing resources. If you only run GPU work this won't be the same issue.
Keith, it looks like he changed it back to the normal cpu reporting. showing 256 now (the universe stats page hasn't updated yet to reflect it). doing this was futile though, as universe has a hard limit of 1536 tasks that doesnt seem to be able to be broken.
but i think arch was referencing limits within the Einstein scheduler system, not with BOINC client-side. I think he's saying that at some core count, Einstein will stop counting more to give you more work allocation. much the same that Universe does.
But all I was wanting to do was publish that BOINC itself has a built-in function to spoof the count on ncpus in the cc_config.xml file.
The Configuration docs say this about it:
Quote:
Act as if there were N CPUs; e.g. to simulate 2 CPUs on a machine that has only 1.
Jord had this to say about the parameter:
Quote:
That option is used for testing, and is primarily for running work on more cores than you have. So you can for instance set it to 64 on a 4 core CPU and run 64 tasks (slowly, because the 4 cores will run all 64 at the same time, 16 per core)
Not as dire a situation with a true 256 core dual socket Epyc host though.
Einstein may indeed have a absolute hard limit on the number of tasks sent per day to a host.
If it's not ubuntu on an x86
)
If it's not ubuntu on an x86 cpu then it may be created/maintained by a different person who made different choices.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor)
BOINC docs are pretty clear
)
BOINC docs are pretty clear about how to start/stop the daemon. just a simple command in the terminal. is that so bad?
https://boinc.berkeley.edu/wiki/Stop_or_start_BOINC_daemon_after_boot
check the Linux (in general) section for start/stop commands. scroll down to the Ubuntu/Debian section to turn off running BOINC at boot time completely.
_________________________________________________________________________
Well that doc is quite a bit
)
Well that doc is quite a bit out of date. The daemon that starts boinc-client and boinc-manager isn't provided by init.d anymore.
On Ubuntu and modern OS, daemons are handled by systemctl. So the commands to start and stop turn into:
16.04.2021 02:55:30 |
)
What is the reason why for that?
My 4x Radeon Pro Duo transmit each 440 Sek. 16 WUs.
That will be arount 3,136 WUs/d.
Know there is some limit on
)
Know there is some limit on the number of tasks the project will allow.
Don't know what it is. But supposedly you can tell the project you have more cpus than you actually do and it allows the project to send you more work.
Change the <ncpus>-1</ncpus> line in the cc_config.xml to <ncpus>256</ncpus> and save the file and then re-read the config files in the Manager.
You should get a larger allotment of tasks then.
Thanks for your help. The
)
Thanks for your help.
The four graphics are dualcore graphics, and they are sitting on a 2P EPYC 7702 board.
I'll talk to the project, we'll see what happens. :)
Keith Myers wrote:Know there
)
256*Number of GPUs + 32*Number of CPUs
But there are maximum numbers, and 256 is way over the maximum number of CPUs which will influence the daily task quota calculation. I think the actual limiting value is 64, or something quite near that. I think there is also a GPU maximum, maybe 8? 256 for ncpus in particular is far beyond the actual supported range for this purpose.
There is also a qualification with a word something like "available", which turns out to mean that if you limit the number of CPUs you advise BOINC to consider available to start tasks on using the Einstein web site Preferences|Computing|Processor Usage|Use at most nn% of the processors mechanism, then the daily quota calculation will reduce the number of CPUs considered to be present.
People using this should be aware that since you are instructing BOINC to consider that it can start more tasks, that if you run CPU work and don't have another constraint mechanism in place, BOINC can indeed launch more Einstein CPU tasks than you have appropriate processing resources. If you only run GPU work this won't be the same issue.
I don't know but how do you
)
I don't know but how do you explain this host at Universe who is advertising 4000 processors.
They have been incrementing the count all along from its native 256 processors and kept bumping it up to keep feeding the beast.
Epyc server with 4000 processors
Keith Myers wrote: I don't
)
Keith, it looks like he changed it back to the normal cpu reporting. showing 256 now (the universe stats page hasn't updated yet to reflect it). doing this was futile though, as universe has a hard limit of 1536 tasks that doesnt seem to be able to be broken.
but i think arch was referencing limits within the Einstein scheduler system, not with BOINC client-side. I think he's saying that at some core count, Einstein will stop counting more to give you more work allocation. much the same that Universe does.
_________________________________________________________________________
I see he has reverted it to
)
I see he has reverted it to native 256 count.
But all I was wanting to do was publish that BOINC itself has a built-in function to spoof the count on ncpus in the cc_config.xml file.
The Configuration docs say this about it:
Jord had this to say about the parameter:
Not as dire a situation with a true 256 core dual socket Epyc host though.
Einstein may indeed have a absolute hard limit on the number of tasks sent per day to a host.