Message boards : Questions and problems : Push out an initial app_config.xml when a user attaches?
Message board moderation
Author | Message |
---|---|
![]() Send message Joined: 29 Mar 17 Posts: 4 ![]() |
Is something like this possible? Several Sourcefinder members have been having performance issues when first attaching to the project because they get sent miles too many work units. I'd like to be able to push out an initial app_config.xml that limits the number of work units a client will accept initially, and allow clients to opt in to receiving more work units if they'd like to. If this isn't possible, then are there any other ways I can safely limit the number of work units a client receives initially (to avoid performance problems), while still allowing clients to grab more work units if they so desire? The project's work unit config is as follows: <max_wus_to_send>1</max_wus_to_send> <max_wus_in_progress>3</max_wus_in_progress> <max_ncpus>16</max_ncpus> Which, to my knowledge, should result in an absolute maximum of 48 work units per client. |
![]() Send message Joined: 29 Aug 05 Posts: 15636 ![]() |
The application configuration file is always user made, and just there for advanced users to use. It cannot be sent out by the project (as far as I know). But in the case of your tasks, how many is too many? How long do your tasks run for? You can also use the <code>daily_result_quota</code>, see https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Joblimits for the description. I think by using <code>max_ncpus</code> that you're restricting users to use a maximum of 16 cores - for those systems with more than 16 cores. |
Send message Joined: 4 Jul 12 Posts: 321 ![]() |
If performance is the problem than it is not an issue of how many tasks are send out but how many tasks are running at the same time. This is what you restrict with an app_config.xml and which can also be set from a project side with a config_aux.xml (see Jord's link under Job limits). It seems you are having the same problems with VMs as LHC@Home had some months ago. I can't find a link to the discussion right now but they also wanted to restrict the amount of initial work and let the volunteer later decide to allow more tasks. You should better ask this on the boinc_projects mailing list as the LHC admins can respond and tell you what they have done. |
![]() Send message Joined: 29 Aug 05 Posts: 15636 ![]() |
Thank you, Christian. In case the link to the BOINC Projects email list is unknown, see https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects. PS, Christian, did you mean this link: Feature suggestion: staggered start of VM jobs on slow storage? |
Send message Joined: 4 Jul 12 Posts: 321 ![]() |
PS, Christian, did you mean this link: Feature suggestion: staggered start of VM jobs on slow storage? No, there was a discussion with Laurence Field about technical possibilities. But there was also a discussion on one of the LHC@Home projects and some news entries from before the three projects where merged. I don't have the time but someone could comb through the official news of the LHC VM projects and probably find something. It must have been within the last 12 months I think. |
![]() Send message Joined: 29 Mar 17 Posts: 4 ![]() |
Thank you everyone for your help. I'm currently looking at tweaking my job limits settings, and setting up an appropriate config_aux.xml. |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.