Need someone to test a ramdisk thingy

Delaying the writes to the disk/filesystem will not help that much. It still needs to write to the disk at some point.
 
402blownstroker said:
Delaying the writes to the disk/filesystem will not help that much. It still needs to write to the disk at some point.
Click to expand...

If the issue is iops, it could help a great deal. You can delay the writes for an extraordinarily long time, at which time you'll get to do a more ordered sync.
 
Not applicable because the application repeatedly calls fsync(). No tunables will help with that.
 
What is the proposed benefit to running in a ramdisk? Is the proposal used with v6 or v7 client or both? Isn't there a utility for the v6 client to download the next WU before the current one finishes similar to what the v7 client does by default? What other benefit would a ramdisk provide?

I guess what I'm asking is: are there measured improvements running the same WU on ramdisk vs. hard disk vs. SSD?
 
The ramdisk can be used with v6.

As for the benefits i have no idea :D
 
402blownstroker said:
About a billions times faster read and write performance over disks. And about a million times over SSD or RAID arrays..... about +- 10%.
Click to expand...

i think what is being asked is "will ramdisk get me more ppd?"

i was going to try it tonight on my machine that currently runs combined 50k/day on a cpu:11 and 4 gpu that get ~6k each.

i will be using windows7 with the ASRock XFast RAM utility that automagically backs up/restores on reboot.

so my plan is to uninstall F@H, keeping data, install to Ramdisk, copy data files to ramdisk and start running F@H again and see what improvement there is.

One improvement will be less read/write to my SSD, so there will at least be that.
 
bigted said:
i think what is being asked is "will ramdisk get me more ppd?"

i was going to try it tonight on my machine that currently runs combined 50k/day on a cpu:11 and 4 gpu that get ~6k each.

i will be using windows7 with the ASRock XFast RAM utility that automagically backs up/restores on reboot.

so my plan is to uninstall F@H, keeping data, install to Ramdisk, copy data files to ramdisk and start running F@H again and see what improvement there is.

One improvement will be less read/write to my SSD, so there will at least be that.
Click to expand...

My admittedly limited experience with Windows ramdisks showed no improvements with write times. This was with the 6.41 Windows GPU client back when the first beta QRB units were around. Don't let that discourage you, though. I didn't try very hard.
 
Not going to work for FahCores as they are static binaries, sorry :)
 
I'm going to follow #33 guides until someone disproves it. So far, it is very proven.
 
tear said:
Not going to work for FahCores as they are static binaries, sorry :)
Click to expand...

Not a lot of recourse on that. Hooking with kprobes would be expensive, SELinux expensive.

Could lazy mirror with mdadm, make ram-based snapshots with dm, or pvmove a lvol to ram and back to disk.

Sounds like they got bit by the ext4 writeback bug and decided to go nuts with fsyncs.
 
The best "solution" to this that I have seen is using MDADM with a RAID0 setup between a RAMDisk and a Physical Disk, very very customized such that all the writes initially go to the RAMDisk and then are flushed over to the physical disk.
I have never done this myself so I don't have any actual data on how well it works, but it seems like it could be a decent setup. However just using ext3 directly on top of a real disk is so much simpler and works just fine.
 
extide said:
The best "solution" to this that I have seen is using MDADM with a RAID0 setup between a RAMDisk and a Physical Disk, very very customized such that all the writes initially go to the RAMDisk and then are flushed over to the physical disk.
I have never done this myself so I don't have any actual data on how well it works, but it seems like it could be a decent setup. However just using ext3 directly on top of a real disk is so much simpler and works just fine.
Click to expand...

I've done this before in mdadm raid1, with the spinner as the far disk and using a write intent log on the ramdisk. It does work.

I'm testing the LVM idea and it works. Love it but I need to script the startup/shutdown to make sure LVM doesn't crap itself.
 
What is wrong with running/folding off a ramdisk and using rsync via cron to backup to a persistent media? I have been doing that 6+ months with zero issues. Why make it complicated when there is zero reason to do so :confused:
 
402blownstroker said:
What is wrong with running/folding off a ramdisk and using rsync via cron to backup to a persistent media? I have been doing that 6+ months with zero issues. Why make it complicated when there is zero reason to do so :confused:
Click to expand...

If you could tweak it with dirty pages, it would have been more simple than ramdisk, just a script you run at the end of a normal install. But it's not, so oh well.

LVM is very simple though.
 
Sounds like they got bit by the ext4 writeback bug and decided to go nuts with fsyncs.
Click to expand...
You're assuming there was thorough thought process involved...

Either way, this whole fsync() write() fsync() is useless -- if something happens and you end up with a short file -- it's not usable by FAH anyway.

In other words, there's no benefit of having consistent short file.

We have devised a tmpfs + periodic copies to a backing store (SSD/HDD), as described here: http://hardforum.com/showthread.php?t=1751872
 
Last edited:
I remember seeing the fsync() discussion on foldingforum and I ended up ditching ext4 on my /var/lib/fahclient directory for CentOS/Fedora systems. It helped tremendously especially since I was on the v6 client at the time and didn't bother trying langoste or whatever it's called (predownload next WU).
 
With version 6.34 of the client, using a ramdisk and langoste gives a nice point increase on bigadv and bigbeta projects.
 
Does anyone find 6.34 with or without this setup offers better PPD compared to v7.2? I know tear and others recommend 6.34 and I've typically used origami to manage my 6.34 clients, but I've not found a way to automate the langoste, etc (I've honestly not looked into langoste since v7 was released).
 
You must log in or register to reply here.
Back
Top