With each work fetch, the scheduler files are transmitted to tell the server the latest configuration and allowed. At least set it to 100% when in use, to find what your OS will release to BOINC as usable. Not meeting those 'maximum possible' kills the request.

Whilst, scanning BOINCTasks history, mostly the models do not grow above 125 for the current batches. Unfortunately, predicting how the next task will evolve cannot be done,if only, so lowering the requirements does not seem an option. What you then get is borderline devices that crash out when they do get them, and a member coming all miffed to the forums voting and voting with feet if the desired solution cannot be offered.

Swapping 'in RAM' models out while the space is searchedby arunning tasks is likely going to kill the device's job efficiency. Could be emulated by any volunteer by lowering the allowed RAM after fetching MCMwork and see what happens. Very likely, surely, since BOINC knows the required headrooms, one or more tasks will be paused with "waiting for memory".

The last question can be answered with "if we could with confidence, we would, sorry." We've had during Beta established maximum ranges. In production they've been increased on occasion [like recently for CEP2]. Shrinking them... can't remember having seen that, only documentation being lowered to match a lower production setting.

edit: Don't know how/what you use the computer otherwise for and the physical limits [256MB/512MB RAM?], but PuppyLinux variants could be freeing up more, dual-booting from a USB stick. Dotch has a ready - minimalistic - kit including BOINC.

Strange... I have a dual core laptop with 4GB RAM also. It is running 2 MCM tasks at the same time, and hasn't complained about not having enough memory.

The computer run XP, and absolutely no other application. XP do not run any of its decorations. No application will launch while the BOINC runs. The computer have about 288MB installed RAM modules.

The problem is that the "Memory" that the WU needs is address space, or swappable memory; swap space. Next problem is that the Setting is of maximum memory; to guarantee that 100% of all WU:s can compute on this amount of allocated memory space; address space.
Finally, the Memory that is reported to BOINC is installed memory modules, which may or may not reflect the reality.

What I want is that the BOINC shall check on free available memory, that is swap space or address space, that shall be returned and compared.

The items compared is not of the same type; this is a software error, confusion on the Memory definition. Note that the maximum memory (the WU may or may not need) is also called minimum memory (that must hence be available).

My view is that this setting is just thought out, it has not been checked on old computers if a WU can really compute or not. Virtual memory is a complex thing. The relative speed of hard drive and CPU is also much different, compared to a modern fast PC. The amount of allowed hard drive activity is also something that is a policy better set by us at the computers.

I have had this issue previously in 2007 on FAAH-work units, where the 96MB computer stopped hard drive to idle after 3 minutes of hard drive inactivity. So much for that it should be "impossible"...

We arrive at the policy part; I am not allowed myself to investigate and decide, it is required to have installed 400MB RAM, and it is not checked if this is ever available for the WU or not.

I have never observed that a work unit should run low on the physical RAM with increased hard drive activity, making further use of the computer for such work units impossible or not recommended. Never, on any computer!

Earlier I downloaded WU:s using one computer with more RAM installed, and then computed these on a target computer that had illegal low RAM. Note that if the WU:s are installed, further Memory restrictions is by address space, and not installed RAM modules. The check of installed RAM modules is only when the project server send out the WU:s. Yes, computation of these was of course OK, with occasional hard-drive power-down due to swap file inactivity.

I'll search further on the net if I can find some application or tool, that can lie to the project server the short moment it shall decide if a WU shall be sent or not.

Absolutely hilarious. Set my win overrides to 180/200% for a 2GB system and on read, got this printed:

22/11/2013 15:46:08 | | max memory usage when active: 3683.12MB
22/11/2013 15:46:08 | | max memory usage when idle: 4092.36MB

Is the client sending the scheduler file with these values, or the real physical available to BOINC?

Whatever the outcome, do not expect this to ever get official endorsement. Get work this way and it going invalid/error. Not a WCG problem.