This is about MEMORY SIZE and confusion in the BOINC software about what to measure.
The normal Memory requirement limit when running a WU is address space or swappable memory. The BOINC run as an ordinary application and let the OS handle the physical memory and extension of the memory, using a disk swap file.

However, when a new WU shall be downloaded from the project server, the BOINC suddenly report installed physical RAM-size to the project server, that may deny downloading of WU:s based upon the reported RAM size.
On the WGC, where the minimum allowed RAM sizes traditionally is kept rather high, this make older computers unusable, to considerably irritation as these older computers will likely not be any use for anything else.

1) The above is a bug; BOINC shall report "available memory" (swap file size) to the project server, and not physically installed RAM.
Is there any modern BONIC to download that correctly report the memory to the project server?
(Latest download checked; see below)

2) The allocated memory can be set, and also be set to 300%, and if the GUI don't accept this the config file can be hacked manually. This enable the BOINC to report a large size RAM available, but it don't work, as BOINC report physically RAM-size to the project server.

3) Kindly note, that a PC with 4GB installed RAM, where BOINC report 4BG RAM-size to the project server, can have 3.GB RAM locked as unswappable reserved RAM by an operating system driver, so installed RAM is not available RAM!!

What I need is a BOINC version or a hack or a tool that REPORT 4 GB INSTALLED RAM TO THE PROJECT SERVER INDISCRIMINATELY OF WHAT IS INSTALLED IN THE MACHINE.
Note that if the WU actually downloads, no more problems exist, as BOINC will compute and upload the result. I only need help with some brain-dead project server setting.

Typical experimental results:
Project server require 128 MB RAM ("Minimum memory size"), the computer have only 96MB, and swap-file hard-drive power down due to inactivity during computation, as no swap file activity have occurred during the last 5 minutes.
(This was in 2007, when the current "old computer" had only 96MB.)

A Linux hacker report that about 32 MB of RAM is used by the current WU:s, but the project server require 400MB, and the target old computer have only 288MB.

****

I have now updated to 7.2.31 BOINC, and the issue is still as described above.
I would very much appreciate if a BOINC software hacker could check if the concept of Memory is inconsistent, as described above.

Thank you!

I wish to make clear that I don't want to extend RAM with some small amount; I wish to circumvent this server restriction completely by telling the project server a lie. The result will be that I will manually decide if a set of WU:s is suitable for the machine or not.

Please kindly note that:

1) BOINC, for some reason, make an API call and obtain RAM chips installed. This include RAM reserved for operating system use; it is the amount of RAM installed in the computer.

The BOINC output the figure in config file
<client_state>
<host_info>
<m_nbytes>280000000.000000</m_nbytes>
</host_info>
</client_state>

2) The BOINC transmit the number to the project server

3) The project server deny the computer WU:s, so the computer must sit idle for an hour, and the request is repeated.

4) It can be ruled out that the project administrator should lower the "Minimum Memory", that is address space, but the comparison is by comparing address space with installed RAM.

Do you see the bug ??

I wish the BOINC team to recognize this as a software error, and in future report "available memory"; the largest block of memory that can be allocated by malloc() or so to speak; that is to report address space and not RAM cells.


But, meanwhile, I wish to hack this, and simply report a constant number to the project server!

www.trng98.se

If the available memory (address space) is reported to the server, the problem disappears.