Hi,
Whats going on I\'ve been crunching along quite merrily when theres been work for a few weeks now all of a sudden I\'m not getting any work and getting this message from the server
\" |BURP|Message from server: Your computer has 1023 MB of memory, and 1024 MB is needed \"

I\'m 1 meg short of Ram ? are you serious ? I\'m running a twin core AMD 4800 clocked at 2.6 gig which flies through these work units 2 at a time no problem so how about somebody at HQ resetting the memory benchmark to whatever it was before please :)

best regards

You\'d be 1 meg short if you weren\'t running an OS or any drivers or anything -- it\'s showing your total memory, not what\'s available. The job would still be able to run, but would not be very efficient, and the idea is that BURP saves the WUs for folks that have the RAM to do the work without all the thrashing. That part of it has been discussed in other threads. On the up-side, the memory requirements are set on a job by job basis, so there\'s no global setting to change back to \"whatever it was before.\" It\'s just a matter of waiting for a job that requires less RAM.

EDIT: ...and if you\'re trying to do two of those memory-intensive jobs at once, then you\'re going to be more than a gigabyte short of the RAM requirements. I\'m running into that issue at the moment -- one of my boxes has enough RAM to handle one of the jobs, but it\'s thrashing like a champ with two simultaneous 800+ MB WUs.

Hi,
Thank you for your quick response and I sort of understand the thinking behind whats going on but its still a bit silly in its usage
heres what I mean the memory according to this project I have is 1023.48 MB
this is using twin sticks of hand tested dual channel memory not the cheap stuff
anybody who has built a pc knows getting 1024 meg out of what is supposedly 1024 meg of ram is very rarely achieved the operating system as you say mucks that up too ( xp pro here )

the stats for the project for my machine are as follows


Measured floating point speed 2606.33 million ops/sec
Measured integer speed 4770.39 million ops/sec

as you can see not bad for a medium twin core and well sufficiant for crunching here

I also run climate models on other duplicate machines which use huge RAM reserves but although rated at 1024 meg for the most hungry project they do not cut you off dead if you are half a meg out

still if you say more work units will be released for people only having 1023.48 MB of Ram then I\'ll just wait until they come along

thank you again for your response
happy holiday\'s


EDIT: just read your above edit thanks again :)

Yeah, one of my other machines is in the same situation you\'re in -- good processor (not as good as yours!) but not enough RAM to get work. The problem is that if there isn\'t enough RAM to hold the whole job, then the computer has to keep part of it on the hard drive. No matter how good the CPU, RAM, and hard drive are, working from the hard drive is many times slower than working from RAM. Still, it\'s frustrating because both of our machines could be getting some work done, even if it takes longer than it should. As long as we\'re not the last ones to turn in our work, then we\'re not slowing anything down by doing work instead of being idle. It would be great if BURP could automatically relax the RAM requirements when there\'s plenty of work and many idle machines.*

Merry Christmas and happy various and sundry other holidays to you, and to all the other BURPers!

* I guess relaxing the RAM requirement might make jobs error out more frequently, which would definitely hurt the overall productivity...

The real problem is that looking at the total memory is a meaningless measure. It should be looking at memory/cores. 2gb with 4 cores will still allow me to get (and run) 4x 1024mb tasks at once.

---

Reno, NV
Team: SETI.USA

Hi Zombie,

seems a bit unfair that somebody could be sitting with 4 cores only using 2 gig of memory and yet me with half the memory and yet half the cores cant :(

still thems the rules still waiting in more work

best regards

One of the things we will be looking into in the future is the multicore processors. Actually it is possible to harvest a nice little speed-increase by running a single WU in multicore mode, then the memory footprint will only be that of one WU rather than #cores*that. BOINC does not support this yet, though, although I know they are planning on adding it at some point during 2008-2009. Currently one workunit can use at most one core, multiple cores are utilized by running multiple workunits at the same time.

If it is true that BOINC allows 4 800MB tasks to run on a quad-core with 1GB RAM then it is certainly a bug in the BOINC client.

One of the things we will be looking into in the future is the multicore processors. BOINC does not support this yet, though, although I know they are planning on adding it at some point during 2008-2009.

But it wouldn\'t be a bad idea to make your app support it before BOINC does. When/if BOINC supports it, you remove your #define THREADCOUNT 1 and add calls to the new BOINC functions :)

---

One of the things we will be looking into in the future is the multicore processors. BOINC does not support this yet, though, although I know they are planning on adding it at some point during 2008-2009.

But it wouldn\'t be a bad idea to make your app support it before BOINC does. When/if BOINC supports it, you remove your #define THREADCOUNT 1 and add calls to the new BOINC functions :)

Well, static multithreading is pretty much easy to get to work (controlled by a server flag passed along on the commandline rather than a define probably) but when David talked about this he was aiming at something different, I think: Something about dynamically adjusting the number of running threads rather than running at a static number of threads the entire time. This may turn out to be a lot harder to get to work, depending on how the BOINC API for it turns out.

Well, static multithreading is pretty much easy to get to work (controlled by a server flag passed along on the commandline rather than a define probably) but when David talked about this he was aiming at something different, I think: Something about dynamically adjusting the number of running threads rather than running at a static number of threads the entire time. This may turn out to be a lot harder to get to work, depending on how the BOINC API for it turns out.

I know it will be dynamic. I meant using this:
int boinc_get_number_of_threads_we_should_use() { return 1; }
until multithreading is actually supported on BOINC. It would be good if the devs \"stabilize\" an API for it and implement such stubs, so that when BOINC adds the multithreading support, we may already have a few projects using it.

---

It would be good if the devs \"stabilize\" an API for it and implement such stubs, so that when BOINC adds the multithreading support, we may already have a few projects using it.

Agreed