Still receiving AMD tasks despite being disabled

Another twopence worth...

Did you disable the GPU in the same "location" as that to which the computer is assigned?  I seem to recall some folks having had issues with that in the past...

Cheers - Al.

An easy way would be to exclude the AMD gpu from Einstein in the cc_config.xml file by adding these lines:

<options>

<use_all_gpus>1</use_all_gpus>

<exclude_gpu>

<device_num>0</device_num>

<url>http://einstein.phys.uwm.edu/</url>

</exclude_gpu>

</options>

What that does first is tell Boinc to use all the gpu's, you probably already have that part, then it tells Boinc to exclude gpu #0 from Einstein but not from any other Project. You can add multiple lines if you want too but it's not necessary unless you have problems there too.

The one problem with this is I don't know which gpu is #0 your AMD gpu or your Nvidia gpu, but when you first start Boinc it tells you which is which near the top of the event log. So if the AMD gpu is not #0 then it will be #1 since you only have 2 gpu's in the box and you will need to adjust the file.

I'm sorry that I didn't fully understand your situation.  There was no mention of the 1660Ti in your original message and I misinterpreted your intention.  For some reason I got in in my head that you wanted to stop all GPU computing at Einstein.

In any case, I'm not sure the real issue with the "Radeon Vega Graphics" is a 2 GB memory limit.  According to BOINC, the capabilities of both GPUs are, "GTX 1660 Ti (4095MB)" and "Vega 8 Graphics (7204MB)".  You obviously have plenty of system memory and BOINC seems to think you have access to quite a lot of it.  If there is a limit lower than what is advertised, it's a BOINC problem.  A project is supposed to be able to use what BOINC says is available.

Even your latest problem task link no longer exists.  That's not surprising since, once the full quorum is completed, the individual tasks tend to disappear from the online database fairly quickly.  After all, as they say, size matters :-), and the project is desperate to trim the online database as soon as possible after the data is safely stored offline.

The easiest way to show people tasks of that type is just to point to the errors list for that particular search and mention to click on any example where the status shows "aborted".

I'm actually quite interested in a bit more detail about exactly what happened with these.  There are two quite different bits of information when you click any particular task ID link, "Client state: Aborted by user" and "Exit status: 201 (0x000000C9) EXIT_MISSING_COPROC".  I'm interested in what exactly happened.  I'm wondering if you did something like disable the AMD GPU with some existing tasks which then became "GPU missing" in BOINC manager, and then you had to abort those tasks to get rid of them, or was the sequence completely different?  Did these tasks definitely arrive after the setting had been changed?  In looking at the BOINC documentation, it seems that excluding various GPU types requires a client restart.  Did you actually do a full restart of the client at some point after the setting got changed and before the client made further work requests?  Is it possible that there wasn't a client restart and could that be why you got more of those tasks?

Do you know that for sure or are you assuming that's the case?  The examples I looked at show 0.00 for both CPU and Run Time.  You only get a memory problem after a short run time and the app then works out it can't store all the data.  There would be some stderr output to show this and there is none of that in your examples.

I'm really not trying to be difficult :-).  I'm just trying to understand the two conflicting bits of information mentioned previously.  I fully agree with you that using the internal GPU is not a good idea and I just want to understand why you had difficulty disabling it.

In the end the <exclude_gpu> directive in cc_config.xml, using the 'type' rather than 'device_num' might be the best way to go.  I don't know for sure as I've never needed to exclude particular GPUs.  Please note the "requires a restart" comment in the documentation if you set this up :-).

OK, thanks for that.  If Windows sees the 2GB dedicated and 7GB shared, BOINC must be looking at the wrong thing if the 'dedicated' value is something you can adjust to be a 'limit'.  The last time I used any version of Windows was XP in 2006 so I have no experience with current Windows behaviour.

Perhaps you should report your observations over on the BOINC boards to see if someone (like Richard Haselgrove for example) might take a look in the BOINC code to see how BOINC comes up with its 'available memory' figure.  If BOINC reported a 2GB limit rather than the much larger figure, then the Einstein scheduler (hopefully) would know not supply tasks that  need more memory.

I have a similar APU style processor (athlon 3000G) in a few hosts.  They don't use the internal GPU but rather a discrete AMD GPU (eg. HD7850, RX 460, RX 570) and I think I must have disabled the internal GPU in the BIOS/UEFI when I set them up - I don't remember - but I've never had any issue with BOINC trying to use it.  The CPU is identified as "AuthenticAMD AMD Athlon 3000G with Radeon Vega Graphics [Family 23 Model 24 Stepping 1] and there is only a single coprocessor showing, eg. "AMD AMD Radeon HD 7800 Series (1944MB)" for one with a 2GB HD7850 GPU.  Are you able to disable the internal GPU and would that solve the problem for you?

In puzzling further about the strange combination of error messages for these AMD tasks ("Client state: Aborted by user" and "EXIT_MISSING_COPROC") here's something more for you to think about.  I've been re-reading your original report and I'm now struck by this bit, "... I discovered today that I have had a lot of tasks recently aborted."  I've just realised that "today" was 8th Dec.  The tasks in question had earlier dates than that.  I had assumed that you had seen these tasks actually on your computer - ie. BOINC Manager tasks tab, and then you either aborted them or they tried to run and immediately failed.  However I'm now thinking that "discovered" means looking at the website list only.  I'm thinking that perhaps you never ever had them sent to you at all.  Direct question - did you ever see these listed on the tasks tab of BOINC Manager?  Or was it just a list of errors you saw on the website?

A little while ago there was a flurry of activity to implement some sort of 'check' at the project end to prevent any 'large memory' tasks being sent to unsuitable GPUs.  The 'mechanism' to do this was not explained.  I'm just wondering if that mechanism just happens to cause a 'MISSING_COPROC' status message and then the error condition gets set to a description that already exists like, "Aborted by user", even though (as you indicated) they weren't actually aborted by you.  If you only ever 'discovered' these later by looking at the website then perhaps you never did actually receive these tasks.  I know this is highly speculative but it would be interesting to know if you've ever seen these tasks listed on your machine.

If you can't or don't want to disable the internal GPU, the entry in cc_config.xml is not that hard to do - something like

<exclude_gpu><br />
    <url>einstein.phys.uwm.edu</url><br />
    <type>ATI</type><br />
    <app>einstein_O2MDF</app><br />
</exclude_gpu>

which goes in the options section of the file.  You could go with <device_num> instead but you would need to be sure what value BOINC was using for it.  The 'ATI' type should catch it unambiguously (provided 'ATI' hasn't been changed into a more modern word, or a different one for internal GPUs :-) ).  You wouldn't need to use this if you can disable the internal GPU in the motherboard firmware.

Sorry for the trailing <br /> stuff on the above lines.  Not sure what's doing that or how to prevent it.  Just omit those bits if you decide to use that example.  All the line endings should look like the very last one.