Well you are doing your part in retiring the "bad" tasks as fast as possible then. Thanks.

mmonnin,

Will this this multiple instances on boinc in windows do what i wanted to do in the original post?

"My much more simplified goal is to dedicate one client to each of these MW classes: n body CPU, NVIDIA GPU separation, and AMD GPU separation."

The issue is, I get unwanted CPU separation tasks when I run NVIDIA and AMD separation. Will your scheme stop that?

Each running client should be maintained in its own directory. So only need to make multiple BOINC folders with all the normal default files. BOINC1, BOINC2, BOINC3, BOINC4 etc. etc.

The only necessary files and folders in the copied BOINC directories are the 5 main executables. boinc, boincmgr,boinccmd, boincscr and switcher. Also the sub-folders should be created also, projects, docs, skins and locales. Don't have to put anything into them, the projects will fill them as necessary.

This was not clear in the overclock instructions.


looks like our postings overlapped.

You don't understand the system apparently. For a long while, the admins have used BOINC's "known reliable host" mechanism whereby a task returned by such a designated host is validated without a wingman task.
https://boinc.berkeley.edu/trac/wiki/ProjectOptions#Acceleratingretries

So if your host returns validated results consistently against a wingman task, it gets designated as reliable and can be validated with just the one task. BOINC then periodically checks the host by sending out another task to a different host to test whether the host is still reliable.

If the two tasks match and validate, the "known reliable host" designation is maintained. If the host suddenly errors out a large amount of work, it loses the designation and will need to build up its reputation again with a long session of validated against wingmen results.

No, that is up to your own settings and the initial ETA/runtime of the tasks.

Actually it happens to me all the time with many projects. Boinc is absolutely useless at working out times. I just got 2 weeks of work from LHC with my buffer set to 1 day!

To really confuse it, put a limit on how many of a certain task (say nbody) can run at once in your app config file. Boinc will senselessly keep downloading thousands of them then realising it's not allowed to run them, then get something from another project, then it will get more and more again and again.

Currently the status says Workunits waiting for validation 675900

any guesses at what number the system will starting having problems? So far I'm getting plenty of WUs to run, and the website isn't slow.

Thank you for the explanation.

RAC is down approximately 14 % over six days, and that rate is constant, meaning it will continue to fall for a couple more days, at least. Is that expected? How much change in RAC do you anticipate due to the new bundling, alone?

To get higher utilization of the gpu would require rewriting the application to be more efficient. The application is in need of more parallelization and get rid of unnecessary timing delays in the coding to get up to 100% utilization . Very few projects have skilled enough developers to use all of a gpu capabilities.

I only know of 4 projects that ever utilized up to 100% of a gpu. That was Seti with the special app, GPUGrid and Minecraft and now Einstein with the improved 1.28 application.

That improvement was from our Team developer who also wrote the Seti special application. We would need Petri to get interested in Milkyway and have the source code for the gpu application made available to him.