Development for LHC@home

Some project configuration parameters have been changed to help avoid hosts being swamped with tasks and to back off problem hosts.

<daily_result_quota> 2 </daily_result_quota>

<max_wus_in_progress> 1 </max_wus_in_progress>

<max_wus_to_send> 1 </max_wus_to_send>

<min_sendwork_interval> 60 </min_sendwork_interval>

Note that the values are multiplied by the number of cores and we estimate tasks lasting for at least 12 hours.

Ref: https://boinc.berkeley.edu/trac/wiki/ProjectOptions

Please post if this causes any problems for anyone.

Not sure, if this is the cause of the error I get:

vLHCathome-dev 03 May 22:03:39 update requested by user
vLHCathome-dev 03 May 22:03:42 Sending scheduler request: Requested by user.
vLHCathome-dev 03 May 22:03:42 Reporting 2 completed tasks
vLHCathome-dev 03 May 22:03:42 Not requesting tasks: "no new tasks" requested via Manager
vLHCathome-dev 03 May 22:03:43 Scheduler request completed
vLHCathome-dev 03 May 22:03:43 Server can't open log file (../log_boincai05/scheduler.log)

The project update fails.

Thanks for the report. I have fixed this.

Error gone and update successful. Thanks!

When there was a credentials problem, the tasks errored out after a few minutes.
This would very quickly ruin the daily quota, resulting in not being able to get work.

Would "abandoned task" count as error towards the daily quota?

As far as I understand the documentation, tasks aborted by the user don't count but the credential problem would have done. The idea being that if there are issues, it is better that the host backs off and looks for work elsewhere. If there is a general infrastructure issue, these values can be reset on the server.

<min_sendwork_interval> 60 </min_sendwork_interval>

I suggest to set this higher(maybe 900sec)

This would also have the benefit of spacing off CMS-tasks, that they do not upload at the same time. I know, there is no guarantee,but if tasks are started with an offset to each other, there is a better chance.

<min_sendwork_interval> 60 </min_sendwork_interval>

The way I always understood this setting, it does not separate tasks to start, but an request for more work will be refused by the server during this period.
The update will restart the interval period.
When you're allowed to request new work, the server will send enough to fill your cache, except when there is a limit task set on the server per host or per core.

Good news: The daily quota works.

Bad news: i already hit it.

Good news: The daily quota works.

Bad news: i already hit it.

Is that glass half-full or half-empty?

---

As long as i can fill it up again, half full.

After cleaning all tasks running and installed the Windows 10 update, I restarted BOINC Manager and dowwnloaded 4 vLHCathome-dev tasks. But only one is running, the other three are ready to start. I have 4 cores and there are no other tasks running, except two Einstein@home GPU tasks, one of which is running.
Tullio

... and dowwnloaded 4 vLHCathome-dev tasks. But only one is running, the other three are ready to start. I have 4 cores and there are no other tasks running, ...
Tullio

Is this just information or do you have a question?

Yes, why only one has started? If I download Atlas@home all 4 tasks start. Is this related to the app_config.xml file which was downloaded?
Tullio

Yes, why only one has started? If I download Atlas@home all 4 tasks start. Is this related to the app_config.xml file which was downloaded?
Tullio

Yes, that is the reason.

Thanks Ben. So vLHCathome-dev gets at most one core, the other 3 of my AMD A10-6700 are free for other projects, plus one GPU task, either Einstein@home or SETI@home, which offer GPU tasks both on the Nvidia board of the Windows PC and the AMD/ATI board of the older Linux box, nicknamed "Old Faithful". Only the 32-bit HP Linux box is still getting vLHC@home tasks and contributing to MCPLOTS.
Tullio

---

Yes, why only one has started? If I download Atlas@home all 4 tasks start. Is this related to the app_config.xml file which was downloaded?
Tullio

Yes, that's to avoid overloading hosts without resources to run several tasks at once. You can edit the file to allow more, and then reload config files to bring it into effect.

---

Yes, that's to avoid overloading hosts without resources to run several tasks at once. You can edit the file to allow more, and then reload config files to bring it into effect.

By resources, are you talking only about memory? Or also CPU threads?

What are the maximum resources any give task could require? That will help us decide the maximum number of tasks to run at a time.

Thanks!

---

Reno, NV
Team: SETI.USA

Yes, that's to avoid overloading hosts without resources to run several tasks at once. You can edit the file to allow more, and then reload config files to bring it into effect.

By resources, are you talking only about memory? Or also CPU threads?

What are the maximum resources any give task could require? That will help us decide the maximum number of tasks to run at a time.

Thanks!

For CMS@Home, mainly memory. The VM is nominally 2 GB. E.g., if I try to run four on my 8 GB Linux box, then I start to swap memory and performance drops so much that I can't get any keyboard response to kill one off. :-( On the other hand, I'm happily running five on a 12-core 64 GB host, together with seven SETI@Home jobs.

---

Every time BOINC starts I get four notices from it:

Your app_config.xml file refers to an unknown application 'LHCb'. Known applications: 'CMS'

The other three are for ALICE, ATLAS and Theory.

This is my app_config:

<app_config>
<project_max_concurrent>2</project_max_concurrent>
<app>
<name>ATLAS</name>
<max_concurrent>2</max_concurrent>
</app>
<app>
<name>ALICE</name>
<max_concurrent>2</max_concurrent>
</app>
<app>
<name>CMS</name>
<max_concurrent>2</max_concurrent>
</app>
<app>
<name>LHCb</name>
<max_concurrent>2</max_concurrent>
</app>
<app>
<name>Theory</name>
<max_concurrent>2</max_concurrent>
</app>
</app_config>