Operating environment tweaks to improve bigadv (VM) Folding

[k1wi]

I use the EVGA bigadv VM image supplied by linuxfah and had a couple of ideas/vague thoughts to improve the performance of bigadv folding.

They might not be possible/too much hard work, but does anyone would know how to post-hoc implement the following to the bigadv VM images?

Hopefully, any solutions posted here might allow native folders to improve their performance too!

1. RAM disk
Environment: Computer with a UPS.
Goal: To decrease the time spent writing the completed file to disk.
Considerations: I know one of the issues with RAM disk is if you experience power loss you lose the contents of the drive, which in FAH's case would be fatal. With a UPS this is avoidable, but the major consideration is the safe power down: currently my system seems to take a while to power down esp with the VM and I haven't yet simulated a power cut yet. (I haven't received the UPS yet!)

Question: How could I (1) automate the image to load a RAM disk containing the folding folder on start up, (2)safely copy/back up the folder to disk at regular intervals (3) automate the image being saved to disk on VM shutdown/suspension? (4) Is it possible to also automatically back-up the folding folder to my host PC? (while keeping the most previous back-up intact)

2. VM bigadv & tear's upload/download decoupler 'Langouste'.
Environment: ADSL2+ (upload max speed=60kB/s, resulting in ~1 hour upload), system (hopefully!) using the above RAM disk.
Goal: To prevent my system from remaining idle while sending results back.
Considerations: I haven't attempted to use tear's decoupler 'Langouste' would it have a negative impact on bonus points given it's time sensitive nature?

Question: If it doesn't have an impact, what do I need to do (script to make/commands to type etc) to the bigadv VM image to get langouste running?

--------
Combined, these 2 initiatives could decrease the current 'downtime' (ie time my computer isn't actively folding) associated with these two issues by at least an hour, probably more like 1.5-2 hours.

Any help (from anyone) would be a great benefit. I'm all for improving the performance of my system and will credit you in my sig.

Kindest Regards,

K1wi

[EDIT:] I just realised that the title possibly suggests I've already developed a tweak, sorry about that!

[linuxfah]

For #1, there is a kernel module available to setup a RAM disk using some of the available system memory. The module is not built in the existing VM images but is fairly simple to add. I did notice that there is about 500MB of data in the work directory on average. The RAM disk would have to be fairly large to accommodate the files. I will see if I can get a RAM disk working on my virtual machine setup here and let you know.

I am not familiar with the decoupler. If you have a link with some more info on that, I can take a look.

[k1wi]

WOW, thanks for you speedy reply!

#1 Thanks for having a look at the RAM disk option, I've been taking a bit of look at making a RAMdisk, but I certainly still have my 'Linux Learner' plates on! It'd be great if there could be a couple of crons to copy the folder over to disk & possibly even to the host.

#2 Tear's decoupler is found here:
http://foldingforum.org/viewtopic.php?f=14&t=11615#p113412

As I understand it allows the download to occur at the same time as the upload?

[linuxfah]

I decided to try the ramdisk on my native Linux system first. I set the ramdisk up for 750000K just to make sure there was enough space. There was a bit under 500MB in the work directory. I copied the data from work to the ramdisk and mounted the ramdisk to the work folder. The folding application appeared to load quicker with the data on the ramdisk nearest I can tell.



With 8-core folding and memory usage from the RAM disk, it looks like I have nearly 1GB of free memory left out of 6GB. I am not sure how it will work out in Windows with only 6GB of memory due to host OS memory requirements but I plan to try that next. I am working on an updated VM image with some changes and I can add the ramdisk support in and a simple script to setup a ramdisk, copy the files, and mount the fs. I also added in cron support.

As for backing the data up to the host OS, Linux supports a file system called CIFS. This file system will let you mount Windows shared folders in Linux and files can be copied to that shared folder if write access is enabled.

[k1wi]

That's looking great.

The speeds for the ramdisk should be almost instantaneous for loading; I trialled a windows RAM disk and got speeds of about 1.5GB/s on a drive test, didn't see what sort of I/O figures it gave, but should equally impressive.

I look forward to seeing your updated image!

[linuxfah]

I have not posted this in the guide yet, but feel free to give the new image a try:

Linux FAH Image v0.4

There is a script called buildramfs. By default it makes a 750000K file system, which is dynamic. It grows as more space is used. It copies the files from work to the ramfs and then mounts the ramfs to the work folder. You can also specify a size for the ramdisk:

buildramfs 500000

I was able to complete a 1920 pt work unit via Ramdisk in VM today.

Screenshot
ChangeLog

I also made some adjustments to the kernel. I am seeing around a 2-3% performance increase with my frame times so far. I made the network share for the fah folder writeable so that you can transfer files to the Linux fah folder. The system also supports CIFS.

[k1wi]

Great stuff,

The changelog looks good, I'm downloading it now and will give it a twirl once my current bigadv finishes in a couple of hours.

Just quickly, will the 500MB ramdisk grow as well? or is it a fixed size?

k1wi

[linuxfah]

Any sized Ramdisk should grow. For example, if you set 500MB, then the file system ends up being around 500MB. If you put 75MB on the 500MB file system, then only 75MB of memory is in use. Running buildramfs without any arguments will set the fs size to 750MB.

[k1wi]

Thanks for that.

[DonMarkoni]

I have not posted this in the guide yet, but feel free to give the new image a try:

Linux FAH Image v0.4

There is a script called buildramfs. By default it makes a 750000K file system, which is dynamic. It grows as more space is used. It copies the files from work to the ramfs and then mounts the ramfs to the work folder. You can also specify a size for the ramdisk:

buildramfs 500000

I was able to complete a 1920 pt work unit via Ramdisk in VM today.

Screenshot
ChangeLog

I also made some adjustments to the kernel. I am seeing around a 2-3% performance increase with my frame times so far. I made the network share for the fah folder writeable so that you can transfer files to the Linux fah folder. The system also supports CIFS.

Hi!
I'll also test new image as soon as my big wu finishes. If it's still working when I get home cause I had some overclocking problems.
Just a couple of questions: image can be used without using ram disk, right? I'm asking cause I'm not using my UPS as it is 1000VA (~700-750W) and it's too weak for ~800W power draw. Is that 2-3% performance increase while using ram disk, or not? Cause I'm thinking it could be gain from not loosing time writing to HDD. I hope it's just kernel tweaks you did, cause it's better in my case.

Thanks for doing a great job! It's much appreciated!

[linuxfah]

Hi!
I'll also test new image as soon as my big wu finishes. If it's still working when I get home cause I had some overclocking problems.
Just a couple of questions: image can be used without using ram disk, right? I'm asking cause I'm not using my UPS as it is 1000VA (~700-750W) and it's too weak for ~800W power draw. Is that 2-3% performance increase while using ram disk, or not? Cause I'm thinking it could be gain from not loosing time writing to HDD. I hope it's just kernel tweaks you did, cause it's better in my case.

Thanks for doing a great job! It's much appreciated!

Hello

The image can be used without a Ramdisk. The Ramdisk is optional.

I tested with and without a Ramdisk and TPF was about the same in both cases. The run I did yesterday gave me an average of 2:53 while running a 1920-pt work unit. Most of the time I see around 3:02-3:04 for my average TPF. I have the kernel running natively as well and it seems to be performing well so far.

[DonMarkoni]

Hello

The image can be used without a Ramdisk. The Ramdisk is optional.

I tested with and without a Ramdisk and TPF was about the same in both cases. The run I did yesterday gave me an average of 2:53 while running a 1920-pt work unit. Most of the time I see around 3:02-3:04 for my average TPF. I have the kernel running natively as well and it seems to be performing well so far.

Great! I always look forward to more speed!
While making some customizations to VMware's config file (like priority.ungrabbed = "idle", memsize = "5428" and turning of cd automount) I have seen the following line: ide0:0.writeThrough = "TRUE". Does that mean if I set it to False then WriteBack cache would be enabled, or something like that? It could pose a danger to work, but unlike ramdisk, cache is eventually flushed to hdd.

[k1wi]

After the ramdisk:

Code: Select all

[17:16:12] Finished Work Unit:
[17:16:13] - Reading up to 52544928 from "work/wudata_01.trr": Read 52544928
[17:16:14] trr file hash check passed.
[17:16:14] - Reading up to 46181412 from "work/wudata_01.xtc": Read 46181412
[17:16:16] xtc file hash check passed.
[17:16:16] edr file hash check passed.
[17:16:16] logfile size: 205517
[17:16:16] Leaving Run
[17:16:19] - Writing 99096773 bytes of core data to disk...
[17:16:27]   ... Done.
[17:16:43] - Shutting down core
[17:16:43]
[17:16:43] Folding@home Core Shutdown: FINISHED_UNIT
[17:19:37] CoreStatus = 64 (100)
[17:19:37] Sending work to server
[17:19:37] Project: 2683 (Run 13, Clone 10, Gen 12)

I'd describe the decrease in time as amazing. I've got a UPS so it's not as important, but if there was a cron for backing up the folder I'd recommend it to everyone who can squeeze out a little bit of RAM. (I've got 6GB)

Thanks linuxfah

[linuxfah]

Great! I always look forward to more speed!
While making some customizations to VMware's config file (like priority.ungrabbed = "idle", memsize = "5428" and turning of cd automount) I have seen the following line: ide0:0.writeThrough = "TRUE". Does that mean if I set it to False then WriteBack cache would be enabled, or something like that? It could pose a danger to work, but unlike ramdisk, cache is eventually flushed to hdd.

I believe that would be the case regarding the writeThrough option. The writeBack caching is generally the alternative caching method to writeThrough mode.

[linuxfah]

After the ramdisk:

Code: Select all

[17:16:12] Finished Work Unit:
[17:16:13] - Reading up to 52544928 from "work/wudata_01.trr": Read 52544928
[17:16:14] trr file hash check passed.
[17:16:14] - Reading up to 46181412 from "work/wudata_01.xtc": Read 46181412
[17:16:16] xtc file hash check passed.
[17:16:16] edr file hash check passed.
[17:16:16] logfile size: 205517
[17:16:16] Leaving Run
[17:16:19] - Writing 99096773 bytes of core data to disk...
[17:16:27]   ... Done.
[17:16:43] - Shutting down core
[17:16:43]
[17:16:43] Folding@home Core Shutdown: FINISHED_UNIT
[17:19:37] CoreStatus = 64 (100)
[17:19:37] Sending work to server
[17:19:37] Project: 2683 (Run 13, Clone 10, Gen 12)

I'd describe the decrease in time as amazing. I've got a UPS so it's not as important, but if there was a cron for backing up the folder I'd recommend it to everyone who can squeeze out a little bit of RAM. (I've got 6GB)

Thanks linuxfah

The write time looks excellent. Glad to hear the Ramdisk worked out for you. I have a bigadv unit running via a Ramdisk in VMware currently and so far there have been no issues. I gave the VM 5000MB of memory and setup the client for 7-core folding. So far there is around 730MB of available memory in the virtual machine and 500MB of memory available in Windows out of 6GB.