| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Active Research
Forum: Mapping Cancer Markers Forum
Thread: Memory requirement for the MCM work units |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 14
|
|
| Author |
|
|
sgoll
Advanced Cruncher Joined: Oct 24, 2006 Post Count: 87 Status: Offline Project Badges: 
|
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 Really funny, eh? That's the power when using an editor / text console and not a GUI.  Is the client sending the scheduler file with these values, or the real physical available to BOINC? I think this is what the client sends to the server, but I may be wrong. 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. I absolutely agree. But it _may_ work and even work reliable. And if someone want's to try it may be worth a test. Beside of this ... if a computer is equipped with 288 MB of memory even windows XP may not be very happy. And the CPU may be a bit slow. But ... well ... why not? Let's see if it works. Months ago, when I did this trick, all the workunits were valid. The memory requirement may be a bit overestimated. At least sometimes ...  Stephan  [Edit 2 times, last edit by sgoll at Nov 22, 2013 5:15:41 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Quote SekeRob
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. Yes, and this "Memory" is address space, swappable memory, right ? 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. Of course not, as this memory size is address space; a limit on the maximum about of address space that the WU is allowed to allocate. 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. But this is pure speculation, right? If the unit cannot run the WU:s, it can not meet the time limits that the server set, a limit on how long the unit is allowed to crunch berfore a result must be returned. Very likely, surely, since BOINC knows the required headrooms, one or more tasks will be paused with "waiting for memory". Absolutely not, because there are plenty of Memory on the machine, and this limit is on "Memory" in the form of how much you are allowed to allocate; this is address space. This is OK and works well. The problem is that, when a job is to be sent out, the BOINC do not report the amount of memory available on the machine, or the amount of memory allocated to the work units, it suddenly report something completely different, of a different type, and that is the amount of RAM cells installed on the machine. This is simply a software bug, and after some years I think that also this minor issue should be corrected. Only when a job is to be sent out is this measure of "Memory" used, all other settings and limits are address space. You cannot compare address-space-memory with installed-RAM-cells-Memory, there are of different units, like comparing feet with gallons! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
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 Really funny, eh? That's the power when using an editor / text console and not a GUI. Is the client sending the scheduler file with these values, or the real physical available to BOINC? I think this is what the client sends to the server, but I may be wrong. 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. I absolutely agree. But it _may_ work and even work reliable. And if someone want's to try it may be worth a test. Beside of this ... if a computer is equipped with 288 MB of memory even windows XP may not be very happy. And the CPU may be a bit slow. But ... well ... why not? Let's see if it works. Months ago, when I did this trick, all the workunits were valid. The memory requirement may be a bit overestimated. At least sometimes ... Stephan Actually, dear Stephan, when I started with BOINC 5.2, there was no GUI interface for prefs. The way to maintain them was creating and editing the override file and use that read-in function, now by and large superfluous. Why it's still there I do not know. Probably for testing reasons [used it for sleep when idle testing]. It's a good time to ask the devs. And for measure, once you start entering spurious values into the override file, you cannot use the GUI Local prefs, or they will be wiped or brought in line with the GUI checked ranges. Surely you've found that out already. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
TRN98, though the device specs were asked, the only piece you actually informed on is the 288MB [An Odd Value]. sgoll gave you the backdoor trick how to go around faking, with warnings.
----------------------------------------As I said "Could be emulated by any volunteer by lowering the allowed RAM after fetching MCM work and see what happens." Just tested it, and BOINC decided to pause 1 of 2 running tasks for lack of available/granted memory [RAM]. Over to you to report what the practical effect is by fooling BOINC > Servers to give you a job and run it. Elapsed v CPU time info will be of interest, not just for 1 result, for that could work out to be a small one, but a series, where you also encounter biggies. [Edit 1 times, last edit by Former Member at Nov 23, 2013 12:57:37 PM] |
||
|
|
|