Limit # of WU of a specific project

[MindCrime]

Running multiple Atlas@home has caused errors for me so I've limited to 1 via app_config with <max_concurrent...

This is working fine but I will still download 20 WUs based on the fact the machine in question has 24 threads. They sit idle for a long time, no problem, but I think they are factored into the scheduler in a way other than 1 max concurrent. Basically when I have atlas UNsuspended it counts as a lot of cpu time for the scheduler and other projects won't fetch much work. The machine doesn't run dry but whenever I update any project without atlas suspended/[no atlas work] it'll always say "not requesting CPU work, don't need"

It seemed like there would be an app_config argument to limit the total number tasks not just the max in progress but I can't find anything. Anyone have ideas or experience with something like this?

[Maxwell]

I've experienced the same thing, but haven't had enough of a problem to figure out a solution.

My best guess: See if you can use an app_config file to pass a "--fetch_minimal_work" command via command line. No clue if that will work, but it might be worth a shot for you...

[Mumps]

But, I bet even that doesn't work well. IIRC, fetch_minimal_work will grab 1 WU per core. So he'll still have 24 Atlas WU's onboard. 23 of which will occupy cache. Meaning many hours of work the system won't request from other projects. And potentially, Atlas being enabled will lead to "Not requesting work, project not highest priority."

I was just wishing for a similar option, but as a percentage. "Don't allow projects to consume more than x% of the work hours to cache." So, if I have a Single-Core system, and am configured for a 1 day (86,400 seconds) cache, 25% would mean BOINC would never request more than 21,600 seconds of work from a given project. Or one would hope the devs could see to implementing a better caching plan. Say, a work request would never ask for more than the projects resource shares worth of the total cache duration. As it stands, it seems like the work request looks at the total seconds the cache should be, and requests enough work to reach that target each time it contacts any project for a work request. It should know better than to fill the cache with any single project.

It should also ignore it's own internal concept of "The highest priority project" if I'm highlighting a project and hitting update. When I'm hitting update, if the project isn't NNT or Suspended, I want to download work if there's any available!

This ends my rant much better posted to the Dev mailing list.

[zombie67]

Here is one option:

- Assume you want to run just 1 task on an 8-thread machine
- set native BOINC client to 12.5% (1 thread)
- Set ATLAS to zero resource share, so it asks for only one task at any given time.
- Run a VM, and set the BOINC client of that VM to 87.5% (7 threads)

[MindCrime]

It should also ignore it's own internal concept of "The highest priority project" if I'm highlighting a project and hitting update. When I'm hitting update, if the project isn't NNT or Suspended, I want to download work if there's any available!

Couldn't agree more, it would be so nice that if the update button behaved like that and grabbed a workload based on our settings. Worst thing that happens is you grab too much work and things deadline.

i think what I'll do first is stop running it on the 24t machine and put it on a 8t machine which is significantly faster per core 3.9ghz over 2.9ghz of the 24t. Also this really isn't much of an issue other than when I'm trying to load up a bunker or grab a lot of work from a project that does limited/intermittent work.

Thanks for all the input. One could run atlas in a vm, if it were to have another instance of vbox installed in that vm? Even if this is doable, i don't think I would want to try it.

[zombie67]

One could run atlas in a vm, if it were to have another instance of vbox installed in that vm?

No, you cannot run ATLAS in a system VM. It is a VM project, each task running in its own VM. You cant run a VM inside a VM, as far as I know. So it can run only on native BOINC sessions.