Main Area and Open Discussion > General Software Discussion

In search of ... RAMdisk opinions

<< < (2/12) > >>

40hz:
wasn't sure how to make it work with a program.
-SQUIDMAN (September 23, 2012, 02:01 AM)
--- End quote ---

You generally just point where your program looks for its datafiles to the RAMdisk and cut the HD out of the equation.

Since nothing goes out over the drive's databus you're operating at close to systemboard speed for data I/O. There is some extra system overhead involved to administrate the RAMdisk. So it isn't at full system speed. But it is still very very fast.

Caveat: some improperly coded applications don't handle speed all that well and may become unstable when using a RAMdisk as opposed to a physical HD. Rare. But it does happen.

Renegade:
Caveat: some improperly coded applications don't handle speed all that well and may become unstable when using a RAMdisk as opposed to a physical HD. Rare. But it does happen.
-40hz (September 23, 2012, 02:20 AM)
--- End quote ---

I'm curious - how would you manage that? I mean, manage to get a program not to work there?

I'm still curious, so going to give the freeware version here a shot:

http://memory.dataram.com/products-and-services/software/ramdisk

4 GB is lots. I can't see needing more unless you're doing some pretty heavy lifting, though programs like Photoshop and video editing can easily chew that up... regular use? Seems like tonnes.

Shades:
I believe there was a discussion/thread before this one here on DC with regards to RAM disks. As this one also describes how to defeat man´s greatest enemy, called: sobriety, I´ll guess its warranted.   :P

For me the following concept is interesting though. Say I equip an 32-bit OS with 8GByte of RAM. The first 4GYte is then usable for Windows. The remaining 4GByte would ideally serve as RAM disk (with no possibility of the OS stealing any capacity away from the RAM drive).

And this would be the thread I was talking about.

40hz:
I'm curious - how would you manage that? I mean, manage to get a program not to work there?
-Renegade (September 23, 2012, 02:55 AM)
--- End quote ---

I don't remember the exact names of the apps. They were both mid-tier multi-user accounting/CRM applications used in the magazine and publishing industry. I tried moving certain data files into RAMdisk to speed up user searches and queries.

And...yikes!



Both apps experienced record corruption problems once RAM disks were introduced into the mix. I suspect something in the code encountered timing issues with the file handles or record locks. Either way both experienced similar problems. On exit from certain modules, the systems would throw a record or header exception about one time in four.

Fortunately, the internal data integrity checks did catch and fix (or at least move) the bad records so it wasn't like it was a full database corruption issue.

When asked, both devs said that RAMdisks were "not recommended or supported" so I'm guessing we weren't the only users that were having problems with that. Once we moved the data files back onto a HD everything worked perfectly.

f0dder:
I don't remember the exact names of the apps. They were both mid-tier multi-user accounting/CRM applications used in the magazine and publishing industry. I tried moving certain data files into RAMdisk to speed up user searches and queries.-40hz (September 23, 2012, 11:09 AM)
--- End quote ---
Sounds like badly programmed software.

Since the thread that Shades mentioned, I've upgraded my main system to 16 gigabytes of RAM, and my permanent %TEMP% ramdisk is now 1gig... plus I have the option of creating "plenty big" temporary ramdisks. I used an 8gig ramdisk while rebuilding my rt7-stripped-down windows ISO, and it cut down on the time spent on rebuilding quite a bit.

Navigation

[0] Message Index

[#] Next page

[*] Previous page