... it wasn't going as fast as I thought, so I took readings again, and again this morning. Now instead of 22-38% faster, concurrent tasks only give me 7-15% faster. How odd - was the GPU getting tired? It wasn't overheating. I think I'll go back to single tasks per GPU.
You need to slow down a bit and stop jumping to wrong conclusions :-). Try reading this thread. The full thread covers two separate changes in the nature of the data (or more likely how that data is crunched) that have caused significant changes in crunch time. The most recent entries in that thread (25/26 May) cover the second change - a very significant slowdown. So if you go back to single task crunching, you are going to be quite disappointed in the outcome.
Peter Hucker wrote:
I have kept though in the config files the CPU usage as measured by me for every type of GPU task, as the ones supplied by the server are completely off. Then I've lowered Boinc's number of CPU cores it's allowed to use until the CPU isn't maxed out, so I know it'll never throttle a GPU.
Just be aware that the <cpu_usage> setting in app_config.xml has absolutely zero effect or control over what CPU resources a GPU task will consume. A GPU task will take what it needs for support, irrespective of what value you insert. Your only concern should be to have a number that allows the correct number of CPU tasks such that GPU performance isn't compromised. You need to perform careful experiments to really know that for sure. My experience has been that for AMD GPUs (nVidia are quite different) you need one unloaded CPU core for supporting two or three concurrent GPU tasks. I'm talking about Einstein GPU tasks combined with Einstein CPU tasks. For different projects and mixes, it could be different.
Another point to consider with 1+1 at Einstein, that hasn't been specifically mentioned in this discussion, is the fact that there are daily limits on task downloads that have become quite restrictive for fast GPUs. I very recently increased my current cache setting of 0.9+0 to 1.1+0 which is really a quite modest increase. A couple of the fastest machines (not really very fast by today's standards) hit the daily limit and had communications suspended for the remainder of the day. I had expected this might happen as I had timed the cache increase to be close to the end of the project 'day' (8AM locally) when the daily limit was already largely used up, so any backoff would be relatively short and not a problem. A 1 day hysteresis increase could be a much more dramatic disturbance (and random as to timing) for BOINC to deal with.
I always try not to waste server resources in the way I configure my hosts. Without the freely donated volunteer computing contributions, projects couldn't process the phenomenal amount of data that they do. If projects need the work done, the least they can do is to attempt to provide the appropriate level of infrastructure to accommodate the load. If they don't have the funding or manpower for that, perhaps they need to scale down their expectations. I don't think it should be up to volunteers to be overly paranoid about their impact on the project servers.
I'm running 1+1 cache and it works well. I have Milkyway as my top priority GPU project, with Einstein second. Asteroids is my top priority CPU project, with Milkyway second. Milkyway has a limit of about an hour of tasks per GPU, but that works fine, I end up with 1 day of Einstein cache and 1 hour of Milkyway. When the Milkyways are done, it downloads another hour of them. The Milkyway server is often down, so I've got a day of Einstein sat there it'll crunch through. Sure, it does sometimes fill it right up to 2 days of Einstein, but so what? It's always busy doing something, and correctly prioritising the project I want it to. I don't think it really matters what cache you give Boinc, as long as you never run out of work, your computer is being productive. And I still think it's best not to pester the server for downloads too often, so I like a large hysteresis, in fact I'm annoyed at the way Boinc always uploads individual results immediately instead of waiting until it has several. If they've got a 7 day deadline, why the rush to upload them? I also noticed Milkyway doesn't seem to do uploads - perhaps the "answer" to each WU is contained in the reporting and no upload of a file is needed?
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
You need to slow down a bit and stop jumping to wrong conclusions :-).
Too many dr.... er... alcohol?
Gary Roberts wrote:
Try reading this thread. The full thread covers two separate changes in the nature of the data (or more likely how that data is crunched) that have caused significant changes in crunch time. The most recent entries in that thread (25/26 May) cover the second change - a very significant slowdown. So if you go back to single task crunching, you are going to be quite disappointed in the outcome.
I measured the speed of the same task while I ran 1 or 2 at once. The increase in productivity on the R9 290 was minimal for running the second one. And on one card (the RX 560) it actually slowed it down significantly. I'm sticking to single tasks per GPU.
Gary Roberts wrote:
Just be aware that the <cpu_usage> setting in app_config.xml has absolutely zero effect or control over what CPU resources a GPU task will consume. A GPU task will take what it needs for support, irrespective of what value you insert. Your only concern should be to have a number that allows the correct number of CPU tasks such that GPU performance isn't compromised. You need to perform careful experiments to really know that for sure. My experience has been that for AMD GPUs (nVidia are quite different) you need one unloaded CPU core for supporting two or three concurrent GPU tasks. I'm talking about Einstein GPU tasks combined with Einstein CPU tasks. For different projects and mixes, it could be different.
Yes I'm using that setting to keep the GPUs busy. What I do is run the GPUs with no CPU tasks on at all. I check how much CPU is required for each GPU task in Windows task manager, and input that into app_config.xml. Then I adjust Boinc's setting to vary the number of CPU tasks until there's some headroom (I try to have total CPU usage around 80%). Since app_config.xml knows that certain GPU tasks need more CPU, it will now automatically use less CPUs for CPU WUs when necessary, leaving the correct headroom for GPU assistance. Boinc really should test how much CPU is really used for a GPU task, as at the moment it just seems to use a server estimate. I've had Einstein tasks say they need 1 CPU when they really need 0.2, and tasks from other projects say they need 0.1 when they need 0.8.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Peter Hucker wrote:... it
)
You need to slow down a bit and stop jumping to wrong conclusions :-). Try reading this thread. The full thread covers two separate changes in the nature of the data (or more likely how that data is crunched) that have caused significant changes in crunch time. The most recent entries in that thread (25/26 May) cover the second change - a very significant slowdown. So if you go back to single task crunching, you are going to be quite disappointed in the outcome.
Just be aware that the <cpu_usage> setting in app_config.xml has absolutely zero effect or control over what CPU resources a GPU task will consume. A GPU task will take what it needs for support, irrespective of what value you insert. Your only concern should be to have a number that allows the correct number of CPU tasks such that GPU performance isn't compromised. You need to perform careful experiments to really know that for sure. My experience has been that for AMD GPUs (nVidia are quite different) you need one unloaded CPU core for supporting two or three concurrent GPU tasks. I'm talking about Einstein GPU tasks combined with Einstein CPU tasks. For different projects and mixes, it could be different.
Cheers,
Gary.
Gary Roberts wrote:Another
)
I'm running 1+1 cache and it works well. I have Milkyway as my top priority GPU project, with Einstein second. Asteroids is my top priority CPU project, with Milkyway second. Milkyway has a limit of about an hour of tasks per GPU, but that works fine, I end up with 1 day of Einstein cache and 1 hour of Milkyway. When the Milkyways are done, it downloads another hour of them. The Milkyway server is often down, so I've got a day of Einstein sat there it'll crunch through. Sure, it does sometimes fill it right up to 2 days of Einstein, but so what? It's always busy doing something, and correctly prioritising the project I want it to. I don't think it really matters what cache you give Boinc, as long as you never run out of work, your computer is being productive. And I still think it's best not to pester the server for downloads too often, so I like a large hysteresis, in fact I'm annoyed at the way Boinc always uploads individual results immediately instead of waiting until it has several. If they've got a 7 day deadline, why the rush to upload them? I also noticed Milkyway doesn't seem to do uploads - perhaps the "answer" to each WU is contained in the reporting and no upload of a file is needed?
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.
Gary Roberts wrote:You need
)
Too many dr.... er... alcohol?
I measured the speed of the same task while I ran 1 or 2 at once. The increase in productivity on the R9 290 was minimal for running the second one. And on one card (the RX 560) it actually slowed it down significantly. I'm sticking to single tasks per GPU.
Yes I'm using that setting to keep the GPUs busy. What I do is run the GPUs with no CPU tasks on at all. I check how much CPU is required for each GPU task in Windows task manager, and input that into app_config.xml. Then I adjust Boinc's setting to vary the number of CPU tasks until there's some headroom (I try to have total CPU usage around 80%). Since app_config.xml knows that certain GPU tasks need more CPU, it will now automatically use less CPUs for CPU WUs when necessary, leaving the correct headroom for GPU assistance. Boinc really should test how much CPU is really used for a GPU task, as at the moment it just seems to use a server estimate. I've had Einstein tasks say they need 1 CPU when they really need 0.2, and tasks from other projects say they need 0.1 when they need 0.8.
If this page takes an hour to load, reduce posts per page to 20 in your settings, then the tinpot 486 Einstein uses can handle it.