Hard Disk alternation

[raddygast]

The other day I was extracting all the contents of an .ISO file, and noticed it took a lot longer than I thought it should. Then I tried doing it to a directory on a different drive (and different IDE channel). The speed was almost double.

Granted that's for a straight copy, but I was wondering if it is more efficient to constantly juggle drives in that way for DVD-RB.

For example, have the source files on Drive 1, and then have DVD-RB use a working path on Drive 2. Then, finally, in the Rebuild phase, have the Output Path back on Drive 1. Would this speed anything up, or is it just important to have the source files on a different drive than the working path?

Then again all this encoding is CPU-intensive, maybe not IO-intensive like ripping, so perhaps it doesn't matter.

[jdobbs]

You have to keep your drive defragmented. That can make a huge difference. I have a partition set aside on one of my drives that only holds DVDs for processing. That way every now and then it gets empty or close to empty so it can get cleaned up.

It can also depend on the type of drive, seek time, buffer size, spin speed...

But by far in encoding MPEG-2, CPU speed is the single most significant determining factor in speed.

[edeus]

Fastest way to get max speed in raw io (prepare/rebuild) is to defrag like mentioned.

have 2 hard drives on two different buses (ie sata or 2 ide cables)

store source on hard drive 1, store work temp on hard drive 2 and then output back onto hard drive 1?

I am pretty sure that would boost everything it can without having to upgrade cpu.

I'm lazy and have 3 drives each doing something, but then because two are ATA100 and on the same ata bus, instead of 30MB/s speed i get 10-15MB/s which is a big hit.

I might change it when i get home :)

Best bet is raptor SATA drives. 3x faster prepare/rebuild stages.

[borgraf]

There's not alot of speed to gain unless you have fairly slow drives. Relative to the encoding time it's almost nothing, like previously mentioned. To put less strain on the drives, and as a bonus gain a little speed, I have Source and Work on physical drive X and Output on physical drive Y. This because of how RB does it's reads and writes during the rebuild stage.

[fewtch]

Originally posted by edeus
I'm lazy and have 3 drives each doing something, but then because two are ATA100 and on the same ata bus, instead of 30MB/s speed i get 10-15MB/s which is a big hit.
How did you measure that? I've got two Seagate drives (one ATA66 I think, the other ATA133) on the same bus as master/slave, and get approx. 40MB/sec with one and 50MB/sec with the other, according to HD Tach. That's tested separately of course, with one or the other drive idle at the time.

I've certainly noticed large gains when using two drives and I/O intensive operations (encoding is generally not one of them). As stated, alternating source/destination drives seems to work best. I think this is partially a function of seek time, i.e. drives with slower seek times will benefit the most from this approach.

[TheSeeker]

Just a question... What do you guys use to defrag your drives? Is the defrag util in XP any good or is norton better? Any other utils I should know about?

[Boulder]

I give my vote to Raxco's PerfectDisk.

What comes to measuring HDD speed, the values HDTach (or any other benchmarking program) gives are theoretical so they really do not apply well to the real world. Try encoding on the same HD, then reading from one IDE/SATA channel and writing to another. You'll see what the gain is on your computer.

[edeus]

Originally posted by fewtch
How did you measure that? I've got two Seagate drives (one ATA66 I think, the other ATA133) on the same bus as master/slave, and get approx. 40MB/sec with one and 50MB/sec with the other, according to HD Tach. That's tested separately of course, with one or the other drive idle at the time.

I've certainly noticed large gains when using two drives and I/O intensive operations (encoding is generally not one of them). As stated, alternating source/destination drives seems to work best. I think this is partially a function of seek time, i.e. drives with slower seek times will benefit the most from this approach.

Yeh I used to get 45+ MB/s in Tach. its a great program for benchmarking and optimising your drivers but real world it is not.

A good test i found is run shrink with no processing, just backing up to iso on the other drive. With that I get about 30MB/s.

I dont know where i tested it, i just know thats about what I get. I get it on linux or windows 30-40 there abouts with 7200rpm 8mb cache WD drives. Newer drives are faster i know.

Seek times are only important when your making butterfly reads and writes. If your dumping contents to disk, it is much less of a concern.

If you want it to be fast, get raid 0 or 5 with raptors. nothing more to say :)

[fewtch]

Originally posted by edeus
If you want it to be fast, get raid 0 or 5 with raptors. nothing more to say :)
Sure there is, it really can be faster having two HD's and using one for input and the other for output. Depends on what you're doing, of course. Encoding, makes little difference. Demuxing, muxing, moving/copying huge files... IME it really helps, as both drives can read/write sequentially rather than continually seeking back and forth. Shouldn't matter too much if the two drives are on the same IDE controller, as long as they're both in UDMA mode.

[raddygast]

Can someone explain the processes RB uses? I thought it would be best to have Source on 1, Work on 2, Output on 1. But someone here posted that Source and Work on 1 is best, then Output on 2.

What does RB do in the prepare phase? Seems it takes from Source, and puts a pile of stuff on Work. The disk does a lot of churning here, but maybe it's mostly reads on the source, because the result in Work is just small files and avisynth scripts.

In the encode phase, I take it it's reading from Source and encoding, and writing m2v's to Work. In this phase I take it having different drives probably makes least difference, right, because the encode is CPU intensive anyway.

In the rebuild phase, it's heavy IO, packing the now-encoded m2v's with other stuff and building a new DVD structure on the Output.

So perhaps that poster was right and I was wrong, and it's best to have SOURCE and WORK on the same drive, and OUTPUT on a different drive? Just want to know how to maximize my efficiency.

[jdobbs]

Frankly I'm not sure it makes a lot of difference. But here's the IO pattern:

PREPARE: Reads from SOURCE writes to WORKING.

ENCODE: Reads from SOURCE and to a lesser extent WORKING, writes to WORKING.

REBUILD: Reads from SOURCE and WORKING, writes to WORKING or OUTPUT (depending on the setting).