Best Memory for Encoding?

[TitaniumDragon2001]

Hi,
I am about to upgrade my Computers Memory to 512 PC2100 DRR Ram, So my Encoding will go faster and not mess up as offen. What is the Best Type to get? There seems to be about 3 different types, I found this site and it seems to be the cheapest for memory

http://www.icentral.com/html/1stchoicememory/page24.html

I have also Seen stuff like this under some of the other Memorys I have looked at: 64x64, Gold Leads, 64x4. Which is best? Thanks for any Help you can give, Right now I cant even encode a DVD Movie to SVCD it always locks up my PC . Well Thanks again for any help.

TitaniumDragon2001

[TeeeRex]

As far as I am aware, memory is not all that important in encoding MPEG's - the core bottlenecks are the CPU and disk IO. Therfore I would personally spend my money on a faster processor or faster disk IO - such as putting in RAID0.

[DJRumpy]

If you've already verified that your memory is the culprit, then DDR is a good choice. Any manufacturer should provide at least the minimum specification for their memory, so it comes down to price. As far as encoding goes, memory isn't going to buy you much as far as performance. You should at least check to see if your motherboard supports faster DDR, like PC2400, or PC2700.

If you have the cash, I agree with TeeRex. Spend it on a cheap IDE Raid array. It will literally double your hard drive performance.

[epo]

Does HD speed really matter with MPEG encoding ??? Mux, demux yes, but encoding. I see rare LED blinks when encoding, but constantly burning LED, while muxing. For mux, I think, the better option than RAID is to set source and destination on different physical drive. Have speeded up mux up to 5x this way. It depends on application though - the larger the buffers are, the less effect You have. RAID still has to seek between source and dest. cylinders on drives.

[DJRumpy]

A raid controller will only help with disk IO tasks (multiplexing, muxing, etc). A raid controller handles all of the tasks related to seek, read, and write. These don't tie up your CPU since the chips on the on the controller handle it. Almost all raid controllers will give you at least 150% performance boost (200% is closer to norm these days) to HD performance. A hard drive only has to work 1/2 as hard, assuming the file is larger than the block size (almost always the case with MPEG, since most block sizes are between 16k and 2MB).

A properly configured raid array will always blow away the same drive in a single configuration, everything else being equal. Remember, a raid is already built up out of multiple drives, so it runs like your copying a file from one drive to the other all the time.

The idle times that you are seeing are ALL cpu, not memory. Your CPU is busy crunching out the compression for the MPEG. The only way to improve that is to up your CPU speed, or go with dual cpu's.

[epo]

A properly configured raid array will always blow away the same drive in a single configuration, everything else being equal.

Right and obvious.

Remember, a raid is already built up out of multiple drives, so it runs like your copying a file from one drive to the other all the time

No, it doesn't, because in 50% case (2drives) or 25% (4 drives) it still needs to write back to the same drive, it reads from. It still fills sectors in sequence, only this sequence is spread over 2 or 4 drives. And You don't get rid of seeks, while without RAID, You get.
So, In mux/demux dual drives blow RAID and at recording/playback vv.
At re-encoding drive configuration is totally irrelevant as We both agree.

[DJRumpy]

Your not factoring the reduction in overhead. The drives only have to work 1/2 as hard (2 drives), because their only writing half the data. They also have less file to read (half the data), and, each drive can pull the data in parallel. Almost all of the IDE drives today are single platter, making the heads move across the entire platter to get to the data. Raid essentially cuts that trip in half for each drive you add. Strangely, in higher drive situations (at least for cheaper IDE raid), the performance starts to drop off at 3 drives (with 2 neting the highest performance increase). Look at any of the benchmarks on the net. A single drive simply cannot compete. I run both configurations, with an IDE raid, a standalone IDE, and a SCSI subsystem, and can demux a file from raid to raid, faster than I can from single drive to single drive. CPU overhead makes up as little as 1% of the work being done, as it's handled by the controller. There is overhead as far as block size (smaller blocks create more work for the controller), but it's negligable. IDE does not stream well, like SCSI, so copying a file from one drive to another is not as efficient as you might think.

As another example, the seek time on a standalone, 100GB WD IDE drive is 8.5 ms. The seek time on the same drive, used in an array, with a 64K block size, drops to 5.6ms on my machine. Write performance doubles, and read performance saw about 150% increase.

I guess this is all besides the point, and rather useless info for TitaniumDragon
8)

[DJRumpy]

{*DOH!*) Color me wrong. The process of remuxing was faster from one drive to another, but the header rewrite that happens direclty after was faster on the raid.