...a bit confused why my config file (without the brackets) is not working.
There are lots of reasons why your file may not be working. Where did you place the file? Is it in the correct location - the Einstein project directory? Are you sure it has precisely the correct name? Did you create it with a plain text editor? Are you sure it doesn't have an extra .txt extension as part of the filename? How did you get BOINC to 'see' the contents of the file? Did you check the contents of the event log to see if the client created a log entry about the file? Are you sure there are no syntax errors? I don't leave any blank lines in mine. I'm not sure if that could cause any issues - I would hope not but you never know sometimes :-).
OK, here are some points to consider about these files and in no particular order:-
You should leave out every optional bit that's not needed.
The ONLY app suitable for your GPU has a <name> of hsgamma_FGRPB1G. You have many <name> items that are simply not correct. All those sections should be removed. They are just a waste of space.
You also have <name> items for deprecated or non-GPU apps. No point in having them in the file.
The only <app> ... </app> group you need is the very first one and even with that there are lines you don't need and parameters that wont work in an optimal manner.
If you want optimal performance, you need to budget for a CPU thread to 'support' each GPU task. There are different ways to do that but if you do it in this file you will always need <cpu_usage> to be 1.
The parameter values you set do NOT change the amount of resources a task will 'consume' when running optimally. The numbers are there just to control how BOINC budgets the resources.
Forget the idea that you will gain a lot by running lots of concurrent tasks. I'd be surprised if there is much gain in running beyond 2. If you read Archae86's posts earlier than the one I linked to in my previous message you will see that he only got a very modest improvement in output by running 2x - just before his 'problem' arose.
You should be prepared to experiment with modest settings to start with. The idea that you could use <gpu_usage> of 0.2 and <cpu_usage> of 0.25 as a first guess is just crazy. You should start with just 2 concurrent tasks and process enough of them that way to really be sure of the benefit. You could then try running 3 to see if there was any further gain. I suspect there may not be. It might even be worse. You need to test to find out.
Below is an appropriate file that you should consider starting with. Please note that you haven't indicated about CPU tasks so this file allows two GPU tasks and 'reserves' 2 CPU threads for support duties. So that leaves 10 threads that could be running CPU tasks if you allow them. In that case you don't need any other entries in the example file below.
You may find that 2xGPU and 10xCPU tasks puts quite a load on your machine. You only have 6 true cores so CPU crunch times may be rather slow if all threads are being used. There is a preference setting for the allowable % of threads that BOINC can use. You can adjust that to limit how many CPU threads can run. You could also do the same by creating extra <app> ... </app> sections for each type of Einstein CPU search you wanted to support. With the <max_concurrent> optional tag, you could control how many CPU threads for a particular app would be allowed as a maximum. It can get quite complicated, even if you aren't supporting other projects. It's relatively easy for things to get in a mess. There's a lot to be said for KISS.
You have attached to multiple projects but I'm assuming you aren't currently running any of these as they all have zero RACs. If you were to start running other projects, things could become more complicated, particularly if any of them had GPU apps.
If you set out exactly what you want to do with regards to CPU task crunching, I could help you with extra sections for the above file. If the KISS principle somehow sounds like a good idea, you could ignore the above and consider setting the GPU utilization factor for FGRP apps to 0.5 in your project preferences. If I were in your shoes, that's probably what I'd do and if I wanted CPU tasks, I would also decide to support just the O1D1 GW search and limit it to perhaps 4 concurrent CPU tasks. I would do that via the % of cores that BOINC is allowed to use. I would set that value to 50%. That way, BOINC is allowed to use 6 threads and 2 of those would be 'reserved' for GPU support. So there are just 4 CPU tasks allowed. The reasons for thinking this way are to do with power consumption, heat, and longevity of the hardware (and what might be the next exciting thing that E@H might find - continuous GW - which continues to elude detection). You may very well have different thoughts.
Making those sorts of preference adjustments are very easy compared to fiddling with app_config.xml if you are not experienced with what you are doing. The one thing you have to remember is that changes in those settings on the website are only transmitted to the client with the downloading of new tasks. It's not just a matter of clicking on 'update'. No big deal really. Just change the preferences settings on the website and then make a small increase in work cache setting and then click 'update' so the client can discover it needs new work. It only has to be a single task and then the new settings will be in play. If you're not in a hurry, you can always wait for it to occur naturally. Reverse the work cache setting once you have new work. Don't set a large cache size until you see how things turn out. You are very likely to get CPU task overfetch and the best thing is to keep work cache size as low as is comfortable for you. I use about 1 day, sometimes less.
If anything is not clear in the above, just ask.
I've just previewed the above before posting which gave me the opportunity to check for new messages. I see you (and a bunch of others) have posted further messages after I started. I only knew what you had posted in the message that I quoted at the top.
I have removed stuff warning about using the Intel GPU but I'll leave the rest even though much of it has been covered by others. Other new volunteers just getting started with GPU crunching might benefit from some of the extra details. Having created the above, I'm reluctant to just throw it all away :-). Maybe someone might make use of it.
Dougga wrote:I've tried to
)
edit: Uups, Archae86 had written all and more already.
Dougga wrote:...a bit
)
There are lots of reasons why your file may not be working. Where did you place the file? Is it in the correct location - the Einstein project directory? Are you sure it has precisely the correct name? Did you create it with a plain text editor? Are you sure it doesn't have an extra .txt extension as part of the filename? How did you get BOINC to 'see' the contents of the file? Did you check the contents of the event log to see if the client created a log entry about the file? Are you sure there are no syntax errors? I don't leave any blank lines in mine. I'm not sure if that could cause any issues - I would hope not but you never know sometimes :-).
OK, here are some points to consider about these files and in no particular order:-
You should be prepared to experiment with modest settings to start with. The idea that you could use <gpu_usage> of 0.2 and <cpu_usage> of 0.25 as a first guess is just crazy. You should start with just 2 concurrent tasks and process enough of them that way to really be sure of the benefit. You could then try running 3 to see if there was any further gain. I suspect there may not be. It might even be worse. You need to test to find out.
Below is an appropriate file that you should consider starting with. Please note that you haven't indicated about CPU tasks so this file allows two GPU tasks and 'reserves' 2 CPU threads for support duties. So that leaves 10 threads that could be running CPU tasks if you allow them. In that case you don't need any other entries in the example file below.
You may find that 2xGPU and 10xCPU tasks puts quite a load on your machine. You only have 6 true cores so CPU crunch times may be rather slow if all threads are being used. There is a preference setting for the allowable % of threads that BOINC can use. You can adjust that to limit how many CPU threads can run. You could also do the same by creating extra <app> ... </app> sections for each type of Einstein CPU search you wanted to support. With the <max_concurrent> optional tag, you could control how many CPU threads for a particular app would be allowed as a maximum. It can get quite complicated, even if you aren't supporting other projects. It's relatively easy for things to get in a mess. There's a lot to be said for KISS.
You have attached to multiple projects but I'm assuming you aren't currently running any of these as they all have zero RACs. If you were to start running other projects, things could become more complicated, particularly if any of them had GPU apps.
If you set out exactly what you want to do with regards to CPU task crunching, I could help you with extra sections for the above file. If the KISS principle somehow sounds like a good idea, you could ignore the above and consider setting the GPU utilization factor for FGRP apps to 0.5 in your project preferences. If I were in your shoes, that's probably what I'd do and if I wanted CPU tasks, I would also decide to support just the O1D1 GW search and limit it to perhaps 4 concurrent CPU tasks. I would do that via the % of cores that BOINC is allowed to use. I would set that value to 50%. That way, BOINC is allowed to use 6 threads and 2 of those would be 'reserved' for GPU support. So there are just 4 CPU tasks allowed. The reasons for thinking this way are to do with power consumption, heat, and longevity of the hardware (and what might be the next exciting thing that E@H might find - continuous GW - which continues to elude detection). You may very well have different thoughts.
Making those sorts of preference adjustments are very easy compared to fiddling with app_config.xml if you are not experienced with what you are doing. The one thing you have to remember is that changes in those settings on the website are only transmitted to the client with the downloading of new tasks. It's not just a matter of clicking on 'update'. No big deal really. Just change the preferences settings on the website and then make a small increase in work cache setting and then click 'update' so the client can discover it needs new work. It only has to be a single task and then the new settings will be in play. If you're not in a hurry, you can always wait for it to occur naturally. Reverse the work cache setting once you have new work. Don't set a large cache size until you see how things turn out. You are very likely to get CPU task overfetch and the best thing is to keep work cache size as low as is comfortable for you. I use about 1 day, sometimes less.
If anything is not clear in the above, just ask.
I've just previewed the above before posting which gave me the opportunity to check for new messages. I see you (and a bunch of others) have posted further messages after I started. I only knew what you had posted in the message that I quoted at the top.
I have removed stuff warning about using the Intel GPU but I'll leave the rest even though much of it has been covered by others. Other new volunteers just getting started with GPU crunching might benefit from some of the extra details. Having created the above, I'm reluctant to just throw it all away :-). Maybe someone might make use of it.
Cheers,
Gary.