I set Boinc to limit memory usage to 75% (while in use or not) on an old machine with only 8GB RAM. Attaching to the project Amicable numbers gave me an 8GB task, which locked the whole machine up. Why is it ignoring my preference? The event log stated it was limiting it to 6GB, but I watched it in the task manager rise to 8GB then Windows couldn't handle it.

So I tried 50%. Again, the event log stated 4GB max. Downloaded fresh tasks, this time it seemed to try to limit it, by causing a computation error in the task. Surely I shouldn't have been given this task?

I was going to ask this in Amicable numbers, but they have a spam filter on their forum, I can't post before I have average credit, catch 22. I can't get credit until I can complete tasks. Doh!

Haven't tried limiting memory but on CPDN it certainly won't send tasks that take up more memory than I have. If more testing work for openIFS tasks comes around I can try limiting memory to less than the tasks take and see what happens.

I was going to ask this in Amicable numbers, but they have a spam filter on their forum, I can't post before I have average credit, catch 22. I can't get credit until I can complete tasks. Doh!

Amicable Numbers have a "getting started" forums where you do not need credit to post.

https://sech.me/boinc/Amicable/forum_forum.php?id=5

I've just had a play with Amicable Numbers.
First try, use all memory and 50% of CPU (4Gb & 2 cores) - ran to completion.
Second, reduce cores to 25% (4Gb & 1 cores) - ran OK
Third reduce memory to 25% (2Gb & 1 core) - did not get any work, but a message

Amicable Numbers up to 10^21 needs 2861.02 MB RAM but only 1945.37 MB is available for use.

- and that's in line with expectations....

Just a thought - What version of BOINC are you using? I'm using 7.14.2 - if you are using one of the variants of 7.16.3 you might have uncovered another bug in that TEST version.

On Android, the reverse is true.
I set ram to 80%, and barely 10% get used.

In case of the 8gb, do you have swap file allocation?
It could help prevent system lockup.
I personally haven't seen any project get even near my max ram.
The highest I've ever seen was Rosetta, using 2GB of ram per core, allocating 16GB in Total (I had 32 GB installed in that machine).

From what I understand it is far, far harder (if not impossible) to restrict the amount of memory a GPU will commit to a particular job once the application has be complied. You may be asking for something that is not possible.

The limit you are looking at is that for the main board, NOT the GPUs, so I would be looking to this being an issue with the TEST version of BOINC you are using.

That is obviously the way the application has been written - What is the CPU usage by the application?
Depending how the application was written it will use whatever GPU memory it actually needs, and as much of the GPU processing cores at it needs. It will also use some (potentially a lot) of the CPU memory and cores.

BOINC, which does the scheduling, is not always informed correctly by the applications as to how much memory or CPU resource is actually required, and so cannot correctly act on the setting provided.
For example the SETI "SoG" application running on an nVidia GPU using the default setting is something like "0.2CPU cores", but will actually need nearly a whole CPU core, and that is alongside using a substantial proportion of the GPU's resources. This is down to the way the application passes the actual resource requirement during exectution to the operating system effectively bypassing BOINC.

I can't recall any mechanism within the BOINC client to confirm the application's memory requirements during execution, but it is obvious that some mechanism exists (for CPU applications) to "correctly" determine the amount of available memory when calling for work and stopping the server from sending data/applications that appear not to be able to run.

The project "declares" how much CPU resource they think (often wild guess) a GPU application requires.
It has nothing to do with CPU speed, it has to do with the work that CPU is being requested to do by the GPU - it may just be sending the GPU part of the application and the data to the GPU then picking up the results at the end, or it may be an integral part of the calculation, and what gets "shared back" may be highly dependent on the exact data set being worked on.

The project "declares" how much CPU resource they think (often wild guess) a GPU application requires.

It's even worse than that.

The relevant configuration value is <cpu_frac>x</cpu_frac> - default 0.1, and it's optional.

Remember that BOINC projects are operated by scientists, and they have three priorities - science, science, and science. Most of them have little interest in how BOINC works for us volunteers, and even less knowledge. (I once made a statement like that during a conference call, and received a hearty endorsement from the other end of the line. It came from one of the most experienced and involved project administrators of all - Eric Korpela of SETI)

Consider that '<cpu_frac>' again - "the fraction of total FLOPs that are done by the CPU". What's the speed difference between those devices? Often more that 1000 to 1, these days - aggravated by GPU speed being recorded at Peak, but the CPU speed measured by benchmark (unoptimised). In general, the <cpu_frac> you see in the BOINC client is arbitrary, and has zero connection with the real world - it has no relationship with the programming choices (OpenCL or CUDA) made in developing the app.

I have an open request to review the situation: Scheduler: estimate GPU app needs better. In just over a year, that request has attracted precisely one comment, and that came from a volunteer familiar on these boards. The BOINC programming team is rather bogged down in internal restructuring at the moment: only small changes are being attempted, and this would be a big job. Only when the message changes from "they should fix this" to "WE are going to damn well fix this" will anything change.

I think what might help, is to limit the project that uses large amounts of RAM, to 1 instance of it.
Some projects double the RAM with VRAM. Meaning, 500MB of VRAM, and the same amount of RAM is being used.

There's another thing that comes to mind;
I don't know if it'll help, but there's a setting somewhere to 'leave GPU tasks in RAM, after closing or pausing the client', or something in the likes of that.
Perhaps this setting might be useful to you?
It all really depends on what client, what OS.
But few configuration settings are on the BOINC Manager; and some do get overridden by projects.
Most of the configuration settings are found on the project's main page (when you visit their web page, go to your account or profile, and select project settings).