Return of the RAMDrive

[sdsean]

(No this isn't an april fool's joke. . .;-) )

I saw some ancient posts about about guy wanting to partition off some ram and make a ram drive for sage to use. . .

not sure he completely understood that recordings are obviously so big that this would be unwieldly to do. .

Or perhaps not . . ? . . .

My machine can take a whopping 24GB of RAM. . .right now i have 6GB installed. . .but even if you had 12GB, I only at max use 3GB, so why not have SageTV record to a RAMdrive as primary and then run an auto archive to back it up to more solid harddisks?

Just a thought. . .

[GKusnick]

What do you expect to gain from doing this? Keeping random-access files in memory makes sense when any page could be needed at any time. But (a) video files aren't random-access, they're strictly sequential, and (b) the OS does a good job of caching random-access pages in RAM already. By setting aside memory for a RAM drive, you'd actually be reducing the effectiveness of the OS page cache by forcing it to cache pages that may not actually be needed.

Plus there's still the size issue. You'd have room for at most a couple of TV recordings in RAM, so you'd have to dump them to disk right away to make room for the next recording, and set up an alternative disk-based recording directory to handle the case where you don't move them out fast enough. Seems simpler to just cut out the middleman and record them straight to disk in the first place.

[stanger89]

SSDs are cheaper, much cheaper, when you start getting into RAM densities that high. I just looked and I'm guessing you'd have to use 6x4GB to hit 24GB in your motherboard? That would be at least $1200 going by newegg's pricess. You could get about 512GB of SSD for that today.

[sdsean]

Yeah not saying i'm going to do it. . . i was just thinking about it. . .

It seems to me that the hard drive access is the one bottleneck that is hard to work around, especially if you have multiple recordings going (although the sequential notes and hdd caching are good points as well). Granted SSD would probably be a better option, but the 3Gb / sec throughput is lame-o. . .

Another reason I was thinking about it is that I'm convinced disk access plays a large role in the slow-ness of channel changing (especially b/c sage has no mode for a cirular buffer). . .There are other reasons too (HD-PVR overhead, building the DirectShow graph, etc), but i'd love to get it faster (i do have it a lot better after tweaking some settings. . . )

The only reason I was thinking about it was the amount of thrash the HDD takes, whereas RAM could obviously handle this thrash much better. . .not sure its a big deal at all, i was just thinking about it. . .

I should note though that I decided to move all my media that I keep to a seperate physical drive than where recordings happen in case of failure. . .

[paulbeers]

Honestly, disk throughput is not an issue. Since recordings are mostly sequential (as GKusnick) pointed out and any modern hard drive can do 70 MB/s+ in sequential writes (and a 1080i Mpeg2 recording is only about 2.5MB/s). You can write several streams to a hard drive at any one time before it even breaks a sweat.

As stated, if you really want fast hard drive storage, go with a Fast SSD. They can usually pull down 200MB/s regardless if they are sequential or not writes and then you could write something like 80 shows at once. I myself, I rarely record more than 4 shows at any one time and so I will stick to my large and cheap conventional drives.

Edit: Hard drives are not causing a delay in your channel changing other than maybe 20ms (the amount of time the head to find a free sector on the hard drive).

[sdsean]

Yeah you guys are right. .. like I said it was just more of a thought experiment. . .


>>Edit: Hard drives are not causing a delay in your channel changing other than maybe 20ms (the amount of time the head to find a free sector on the hard drive).

Curious why you say this? I know its been said in the past, but I also know that when I've installed faster hdds, channel changing got noticebly faster. . .and of course to me it makes sense since sage doesn't use a live bufffer, it must create a new file, continually append, close file, open new file, start again. . .

[stanger89]

Originally Posted by sdsean

Yeah not saying i'm going to do it. . . i was just thinking about it. . .

It seems to me that the hard drive access is the one bottleneck that is hard to work around, especially if you have multiple recordings going (although the sequential notes and hdd caching are good points as well). Granted SSD would probably be a better option, but the 3Gb / sec throughput is lame-o. . .

Huh?

Another reason I was thinking about it is that I'm convinced disk access plays a large role in the slow-ness of channel changing (especially b/c sage has no mode for a cirular buffer). . .There are other reasons too (HD-PVR overhead, building the DirectShow graph, etc), but i'd love to get it faster (i do have it a lot better after tweaking some settings. . . )

99% of the channel change delay is the time it takes the "tuner" to actually change channels. Maybe 1% of it is the time it takes to rebuffer the new file.

The only reason I was thinking about it was the amount of thrash the HDD takes, whereas RAM could obviously handle this thrash much better. . .not sure its a big deal at all, i was just thinking about it. . .

It's not going to do you any good if you can only "buffer" about one show in RAM. You're still going to be thrashing the HDD. Heck it would probably be worse, instead of slowly writing ~20Mbps to the HDD over the course of a show, you'd slam it with 6GB of data as fast as possible as soon as the show was done when it gets dumped back to HDD.

[paulbeers]

Originally Posted by sdsean

Curious why you say this? I know its been said in the past, but I also know that when I've installed faster hdds, channel changing got noticebly faster. . .and of course to me it makes sense since sage doesn't use a live bufffer, it must create a new file, continually append, close file, open new file, start again. . .

Most likely this is the fault of a failing drive or you went form some very old drive to a very modern drive (but even then I can't see it making more than a second worth of difference).

[davephan]

I did some experimenting many years ago, when IBM 386, 20 MHz computers were current technology, and IBM 386, 33 MHz computers were really fast. I had an IBM XT computer, which is very slow and ancient by today's standards. I compared the functional speed of a Chinese word processor program, which was very demanding of the hard drive. The program ran very slow on the IBM XT computer was was fast on the IBM 386, 20 MHz computer. I tried installing a RAM drive on the IBM XT. The program was just as fast on the slower XT computer using the RAM drive verses the IBM 386, 20 MHz which did not have a RAM drive. Back then, the RAM drive wasn't very big, but it did prove a point that programs can run drastically faster with a RAM drive, at least with those vintage computers and software that interacts with the hard drive a lot.

Dave

[paulbeers]

Originally Posted by davephan

I did some experimenting many years ago, when IBM 386, 20 MHz computers were current technology, and IBM 386, 33 MHz computers were really fast. I had an IBM XT computer, which is very slow and ancient by today's standards. I compared the functional speed of a Chinese word processor program, which was very demanding of the hard drive. The program ran very slow on the IBM XT computer was was fast on the IBM 386, 20 MHz computer. I tried installing a RAM drive on the IBM XT. The program was just as fast on the slower XT computer using the RAM drive verses the IBM 386, 20 MHz which did not have a RAM drive. Back then, the RAM drive wasn't very big, but it did prove a point that programs can run drastically faster with a RAM drive, at least with those vintage computers and software that interacts with the hard drive a lot.

Dave

There is no doubt that RAM drives used to make a difference and theoretically can make a difference for running applications even in today's computers (where hard drives sans SSD's are the limiting factor), but for media storage it isn't practical and doesn't make a lot of sense.

[GKusnick]

Originally Posted by paulbeers

...and theoretically can make a difference for running applications even in today's computers...

Well, yes, but perhaps not the kind of difference you want. RAM drives are a sort of poor man's virtual memory and date from the era before PC operating systems had VM and page caching built in. Now that OSes support those features internally, frequently-used disk pages stay in RAM anyway, without resorting to RAM drive hacks. Using a RAM drive to override that OS disk caching will probably result in worse performance.

[49studebaker]

If you want to create a RAM drive there is free program called "Ramdisk".

http://www.mydigitallife.info/2007/0...d-2003-server/

[Fuzzy]

To use a RAM drive just for a temporary high speed buffer that will eventually move to physical disk, is no different than setting up a massive write through cache. Though the Cache is much more flexible. I'm not sure on how customizable windows current cache mechanisms are, but I'm betting there's ways to tweak the size up considerably and gain everything you would from RAMDisk, wihtout the complications. There are also more advanced drive controllers that implement a large SDRAM based cache in hardware The rocketraid 3450's 256MB cache is more than enough to absorb any sage recording delay's that would be associated with hard drive congestion.

Of course, you could always splurge and buy one of these: http://www.ramsan.com/products/ramsan-300.htm

[tyke]

I have a i5 machine with 8G Ram, I made a 2G ram drive and moved my Outlook .pst, temp directory, IE and Firefox temp cache to it. Made Outlook crazy fast. Not sure if it really helps IE and Firefox. The free program loads an image to it at startup and does a backup at shutdown, so I don't loose things.

[Fuzzy]

Assuming you shut down properly...

[stanger89]

Yeah, an SSD will give you the same result too.