<core_client_version>5.2.7</core_client_version>
<message>The system cannot find the path specified. (0x3) - exit code 3 (0x3)
</message>

This happened again and again, that I was getting computation error. And then I was getting low virtual memory errors!

Now this strikes me as odd, as I have 1Gig of ram and a seperate 20gig HD as my swap space. Considering that before I go to bed, I close down all my services that windows allows me to close and then with this really nifty prog I found I kill everything else, including explorer.exe! Then I fire up this ram defraggor and cleaner. I fire up boinc, run a benchmark and hit the sack. Where I would normally compleate about 2-3 WU, I can complete 5-8 depending on the series.

Now I am sure that some people are going to say that this is a dumb way to do things and this is propbably how I got my error but I have been doing it since the early days of seti classic and have never had a problem before.

I am just wondering if maybe there is a memory leak in rosetta. and if any one has ever seen this problem before???

here is the error generate from the result ID:
<core_client_version>5.2.7</core_client_version>
<message>The system cannot find the path specified. (0x3) - exit code 3 (0x3)
</message>

---

Oh BTW, This error cuase me to lose 16 WU's,

---

...this really nifty prog I found I kill everything else, including explorer.exe! Then I fire up this ram defraggor and cleaner. I fire up boinc, run a benchmark and hit the sack. Where I would normally compleate about 2-3 WU, I can complete 5-8 depending on the series.
Now I am sure that some people are going to say that this is a dumb way to do things and this is propbably how I got my error

Errr... I wouldn't call it 'dumb' but it sounds like it could be the reason you got your error. Something that closes all services and TSRs could probably terminate a service handling the file system, such as 'workstation' or 'server', and therefore boinc couldn't possibly write to disk. As for ram defragger, they are like those car polish that 'make your car faster'.

Finally, since WUs completion time are CPU-bound, there's no way in the world that you could possibly complete one 250% faster without thrashing it.

I don't mean to rain on your parade, it's just my honest two cents.

---

Team CFVault.com
http://www.cfvault.com

>>> and this is propbably how I got my error

I think so too. With Seti classic, you are talking about a single simple process. With BOINC, we are 5+ years on, you are talking about several interacting components using the OS in ways "classic" never would have needed.

Memory de-fraggers are a waste of time, you don't read memory serially.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

yah, I guess you guys are correct, I havnt done that process yet and I am still processing almost the same amount of WU's.

But whats the point of a ram defragger then? Is it just novelty then ????

---

>>> and this is propbably how I got my error

I think so too. With Seti classic, you are talking about a single simple process. With BOINC, we are 5+ years on, you are talking about several interacting components using the OS in ways "classic" never would have needed.

Memory de-fraggers are a waste of time, you don't read memory serially.

Hence the name 'Random Access Memory' :)

Are there really RAM defraggers on the market?

---

But whats the point of a ram defragger then?

Erm, did you *cough* buy *cough* the ram defragger? Because if you did, then you've just discover its point :-) This kind of software is akin to those 10,000 dollars cables or 500 dollars wooden knobs that make your stereo erm, 'sound better'

In a nutshell, disk drives have a benefit to gain from being 'defragmented' or 'reorganized' because the data is read like an old vinyl record. Imagine the inside of your hard drive as a vinyl disk player and the playing head moving back and forth on the disk. If all the data you need to read is in one long ordered sequence, then the reading head would seek, land on the disk, read in one go, and go do something else. If the data is all over the place, the head lands, reads, takes off, moves, lands, reads.. etc. Takes longer as you can imagine.

Now the thing about RAM or anything solid state is that it can just be 'addressed'. The program says 'give me 3 bytes from that position' and the data is read. That's it. No moving heads, nothing to take time.

This is why defragmenting ram, memory sticks, sd cards and even solid state drives is possible, but completely and utterly without any consequence.

Here's a review of a ram drive that might help you understand. It's especially easy to draw comparisons with that one because it's DDR based, using the same sticks of ram you would usually on your mainboard. As you can see, even that review states that while it's possible to 'defragment' the drive, there is no advantage to it.

---

Team CFVault.com
http://www.cfvault.com

[quote]But whats the point of a ram defragger then?

Sounds like the purpose of a RAM defragger is to take some of your hard earned cash, and no other reason! :(

---

Regards,
Bob P.

Well, I am a simple person and I never bought the software, I just downloaded it from one of the many free software sites out there. I am running some benchmark right now too see if it make a performance boost or not. I will let you know

---

Um, well, there is an "it depends" in here, though, at the moment it is of only historical interest.

Firstly, all of the memory managers I am aware of in operation today, especially in the world of BOINC, are "page" based. All items are of fixed sizes called pages. The "page" is the actual 'stuff" that the computer works with, the programs and data.

As they are needed, they are "paged" into (or out of) "Page Frames" (which are the same size as the "pages") which are then referenced.

In earlier days there was a varient of memory management where the data was contained within "segments" which could, and did, vary in size. In this system, over time, the memory could become "fragmented" and could require reorganization to read in a new segment.

Ok, this is the historical interest ... as I said, not particularly relevant AT THIS MOMENT of computer history ...

Oh, you can also get fragmentation of the "heap" if the applications are too, um, careless in allocation and de-allocation of memory. But, again, the library functions *SHOULD* manage this transparently.

---