Running multiple WUs on Ryzen 1800x paired with rx570?

The O2AS GPU tasks are test tasks and (hopefully) you shouldn't get any unless you have also changed settings to allow beta test tasks as well.  I would strongly advise against doing that.  The two searches are unlikely to play well together and there are unresolved problems with the test app. Until you have a much better understanding of the full implications and until the new app is working much more reliably, you should really stay out of the GW GPU app.

All I can do is tell you exactly what my experience has taught me.  That 7-10% figure is based on the behaviour of a large number of hosts running 2x on various models of AMD GPUs.  My RX 570s all show close to 10% improvement.

When you first posted, you didn't mention anything about other projects.  Because you weren't running any Einstein CPU tasks (only GPU) I wondered at the time if your intention was perhaps to use Einstein for the GPU stuff and other projects for all the CPU threads.  It didn't occur to me that you might be trying to run other projects on the GPU as well.  It's difficult to give reliable advice if the full picture isn't provided.

I have no experience with running other GPU projects along with Einstein.  Around 2010, I started running Milkyway only on a group of machines with HD 4850 GPUs.  I've never tried sharing a GPU between projects.  When Milkyway stopped providing tasks that could run on a HD 4850, I stopped running Milkyway.  My gut feeling is that it can be a source of anguish trying to get different science applications sharing the one set of hardware.  For that reason, I tend to stick to the project I'm most interested in.  If I want to try a new project, I'll tend to dedicate a machine solely to it until I learn how it behaves.

Why do you worry about these things?  You can't really change the behaviour of any specific science app.  You would hope that the programmer is sufficiently skilled to have written code that best makes use of the hardware.  All you can do is tweak your settings to optimise the output of the given code.  You just need to decide what you want to support - hopefully based on the importance (as you see it) of the project's potential contribution to science.  Once you decide that, you could always suggest improvements to the code if you think there are glaring deficiencies.

Nothing is "recommended" - there are going to be two separate science objectives and it's up to you to choose what you want to support.  However, based on what your various comments suggest, you seem to want efficient, well behaved, maximised output.  Unless you want to help with testing and have no problem with seeing inefficient use of resources and perhaps lots of problems with valid results, the only Einstein GPU app that 'fits your bill' is FGRPB1G.  It's suitable for both GPUs you mention at 2x.  For the GTX 1080, you may get a further small improvement at 3x or even 4x - I have no experience - but you would need to verify that for yourself through experiment.  nVidia GPUs really need a full CPU thread for each concurrent GPU task.  The CPU support needed for AMD GPUs is significantly less and you may have no problem with just one thread supporting both tasks but once again, you need to test for your particular setup.

There are various ways of thinking about optimal performance.  For me, I want to support Einstein and I'd like to maximise output but not at the expense of excess power use and heat.   Potentially GPUs will achieve that so I don't run any CPU tasks on hosts that have a crunching GPU - virtually all hosts these days.  This neatly side-steps any issue around having adequate CPU support for whatever the number of GPU tasks being crunched.  I've essentially doubled my output for the same sort of power input.

My ultimate aim is to run the GW GPU app when it's ready for 'production'.  I've done a limited amount of testing - with a high fraction of invalid results so far - so all my hosts are now back running FGRPB1G until there is something new to test.  It might be quite a while before there is a version that is both efficient and gives reliable results.  However, in the end, the first detection of the continuous GW emissions that must be there is the 'holy grail' this project seeks for, and to be a small part of that is what motivates me.  Reliability is far more important to me than efficiency so it won't bother me if the new app doesn't make fully efficient use of the GPU.

Already it's more 'efficient' to crunch an O2AS task on a GPU rather than on a CPU.  I'm just waiting to see what's needed for it to become reliable.  It's just the 'nature of the beast' that the search algorithm will have fluctuations in how intensively the hardware is used.  Some parts of each computational 'loop' are more easily 'parallelized' than others and probably some things can't be parallelized at all.  I'm sure the Devs are doing their best to achieve the best use possible.

If you are using the GPU utilization factor method to run multiple GPU tasks, that automatically 'reserves' (or budgets for) a full CPU thread to 'support' each running GPU task.  You don't need to do this separately by using the setting for % of cores BOINC is allowed to use.  So, as an example, if you had a 16 thread processor and a GPU running FGRPB1G tasks 2x, BOINC would 'see' just 14 threads (16-2) available for CPU tasks with 2 threads 'reserved' for GPU support.

If you also set the % of cores BOINC is allowed to use to less than 100%, you may further reduce the number of CPU tasks that BOINC is allowed to run.  For example, if you set 50%, I believe the 14 from above would be reduced to 7.  It gets more murky if the % doesn't give an integer number of cores.  I could easily be wrong (since I don't remember ever properly testing this) but if you were to set the 93% you mentioned previously with 2 GPU tasks running, the calculation would give 14x0.93=13.02.  It may be that this would be rounded down to 13 as the maximum number of CPU tasks that could be running but I have this sneaking suspicion that BOINC would allow the 14th CPU task just because it can see a tiny fraction of a core not budgeted for and therefore available to be used for that 14th task.  I could easily be wrong.

I think you're just describing standard behaviour.  By default your first tasks were 'branded' as requiring 1 CPU + 1 GPU.  Once issued, that 'branding' doesn't change but the crunching behaviour easily can.  If you change the GPU utilization factor to 0.5, all new tasks will come with the new branding but the branding of the 'old' tasks won't be changed.  Your BOINC client will respect the new branding (for all tasks including the old ones) just as soon as it is advised of the change by the downloading of new tasks.  The downloading of new work is the only way the client is advised of the change.  Updating the project (without getting new work) will not do it.

That's the sort of figure that I see on mine as well.  Looks good!

That's an old and low end GPU that is not really suitable for crunching these days.  That time seems very slow but it's probably what you would expect.  I have nothing to compare it with.  My oldest GPU is a HD 7770 from around 2011 still running current tasks successfully.  It does tasks singly in about 36 mins.  You might be able to pick up one extremely cheaply.  You'd improve your output enormously with one of those in place of the 6450 :-)

Good on you for not being discouraged and for following your passion.  I can really empathize with that attitude.  I was always impressed by the sheer dedication and foresight of all those scientists involved in the conceptualization, the design, the initial construction and ultimate upgrading and refinement of the LIGO observatories.  I didn't really understand (at the start) just how mind-blowingly awesome the whole deal was.

It really sank in with the detection of the first BH-BH merger event.  Then there was the NS-NS merger a couple of years later and all the other flow-on benefits that came from that GW detection.  The source location was able to be pin-pointed in the sky for other EM observatories to gather huge amounts of data from the afterglow.  Those events spurred me to dig deeper for more information about what questions now had better answers so I've become even more inspired to contribute to the eventual detection of continuous GW emissions - something that Einstein@Home is well placed to be a part of.  If anyone wants to get a 15 min tour of what the study of the NS-NS merger is delivering, take a look at this video.  It's written and presented by an Australian, so I'm a bit biased :-).

You're most welcome and it's good to know you're satisfied with the outcome.

It's not the Ryzen CPU.  It's the Vega 10 GPU that's doing the fast crunching.  So yes, your 660Ti will be looking very much like a snail in comparison.  You could probably get 6+ times your current output for something like an RX 570 replacing your 660Ti.

Be aware that it's the FGRPB1G app that does so well on modern AMD GPUs.  Things might be a bit different different when the GW GPU app eventually gets sorted out.  It's likely that a fast CPU may be necessary to get the most out of a modern GPU.  Older hosts (like both yours and mine) will probably be rather dismal performers :-).

https://www.amd.com/en/support/kb/release-notes/rn-rad-win-19-9-2

AMD tends to email them to me all the time since they don't know my one Ryzen is not a fast one and my other AMD's are almost as old as this project