capturing on slave drive

[johns0]

I plan on getting another hdd to put on my second ide and wondered if there was any drawbacks to it being connected as a slave drive and keeping my liteon dvd burner as master drive,right now i dont drop any frames but just need more space.

[redwudz]

Maybe just my opinion, but with newer MB's I don't think there is any problems. Even using a slave as a capture drive, unless you are transfering or reading from/to the master at the same time, I doubt it would slow down.

[johns0]

Thanks for the input,nforce2 mobo`s are very peculiar with the ide especially the ide drivers,cdr burns were screwing up until i switched to ms drivers instead of nvidea crap drivers,just dont want anymore ide problems.

[budz]

Just some info for you regarding nforce 2 mobos. There is a site you may download from that fixes some of the nforce driver problems. Take a look at this site:
http://mwarhead.motherboardfaqs.com/

[johns0]

Been down that road before,what i do know is install the nvidia drivers but not the s/w ide drivers,any nvidia s/w ide driver causes problems and many people are complaining but nvidia isnt helping.

[redwudz]

johns0: I see we are using similar MB's. I wasn't aware of any problems as you have mentioned, just lucky with my setup, I guess. Good info to know, though. I ran out of IDE channels and installed a Promise TX2 board for a backup drive and DVD ROM. No problems so far.

[lchiu7]

Just a point of experience but I run a 60G C drive as master with a DVD Writer as slave off that, a 250G D drive as master on the secondary with a DVD ROM drive as slave off that. This allows me to

1. capture to a drive which is on its own IDE channel so I can work away on usual apps (which are stored on the C drive) and not affect capture

2. Not limit burning speeds by having the source for most burns (the 250G D drive) going to the burner on the other IDE channel. I can burn 4X DVD+R with no problems - don't have a 8X drive yet.

Works well for me but YMMV

[SaSi]

Slave drives suffered in performance in the PIO mode 4 days. With UDMA, especially at 100Mbps, there is no such concern.

The only important issue about a capture drive is to be fast itself. 7200rpm drives are almost 40% faster compared to a 5000rpm drive. Be careful, because 5000rpm models still exist.

Another issue is that the first half of a drive is always almost 30% faster compared to the remaining 50% of the drive. This is because writing to the outer cylinders (more sectors per cylinder) is faster compared to the inner ones.

I would use a huge drive (200Gb) split it in half and use the first half for capture and the second half for ripping, authoring, conversions etc.

[gmatov]

SaSi,

I would like to see a reference to the 40% faster for a 7200 over a 5400 RPM drive. Yes, it spins 40% faster, but it will write at a, possibly, very little faster rate, if faster at all. Access times are within tenths of a millisecond..

And, with smaller cylinders on the inside half of the platter, writing at, say, 10 MBPS, bits will be closer together than on outer cylindes, greater circumference, but still write/read at same rate.

And 8 MB or 2 MB cache testing shows very little improvement, as the drive will write so fast the cache never fills up. What possible advantage there might ne is more likely improvement to the drives firmware, greater efficiency of throughput, but they can't charge as much for that as they can for the extra 6 MB of cache, aka RAM.

I'll link to some tests when I get a chance. Anectdotal evidence don't cut it, here.

Cheers,

George

[johns0]

I plan on getting a maxtor 160 gb 7800 rpm 8 mb cache and using it just for mega captures and dvd ripping and video editing.

[proxyx99]

Wherever you will put it it will work the same, no matter if on IDE or ATA Promise controller. Partition it into 2 or more. At first, with no files all part. will be equally fast but when you keep stuff they will get slower (amount of data stored affects the speed). In this case use Sandra util. to benchmark your drive part. Fastest part. will be on the outside, take notice. Speed of slowest and fastest may vary vastly depending on how much data you have (drives do not write in contiguous manner but rather spread stuff wherever they please). Use Sandra from time to time and watch your performance.

Now, the real stuff. All of the new ATA 100, 133 and SATA is so fast that whereever you put them and whatever you do you won't most likely drop any frames provided PC soft side is maintained properly and capture is the only task open. That's it. What is preferred when burning is to use different IDE channel for the source and writer (as a rule: writer will more reliably write stuff from the other IDE channel rather then its own). Adjust your Temp writing directories accordingly if needed.

[lchiu7]

Now, the real stuff. All of the new ATA 100, 133 and SATA is so fast that whereever you put them and whatever you do you won't most likely drop any frames provided PC soft side is maintained properly and capture is the only task open. That's it. What is preferred when burning is to use different IDE channel for the source and writer (as a rule: writer will more reliably write stuff from the other IDE channel rather then its own). Adjust your Temp writing directories accordingly if needed.

Concur with that. Last night I was capturing off TV using IUVCR PicVideo compression (720x576) to a 250G drive on the secondary IDE channel. At the same time I was running Mainconcept to encode a 10G file to mpeg2 sitting on an external USB 2.0 drive with output to my drive on the primary IDE channel. Over the entire hour of the capture, didn't drop a single frame

Have authored and written DVD's while capturing on the other drive but only when I had to

[SaSi]

SaSi,

I would like to see a reference to the 40% faster for a 7200 over a 5400 RPM drive. Yes, it spins 40% faster, but it will write at a, possibly, very little faster rate, if faster at all. Access times are within tenths of a millisecond..

And, with smaller cylinders on the inside half of the platter, writing at, say, 10 MBPS, bits will be closer together than on outer cylindes, greater circumference, but still write/read at same rate.

And 8 MB or 2 MB cache testing shows very little improvement, as the drive will write so fast the cache never fills up. What possible advantage there might ne is more likely improvement to the drives firmware, greater efficiency of throughput, but they can't charge as much for that as they can for the extra 6 MB of cache, aka RAM.

I'll link to some tests when I get a chance. Anectdotal evidence don't cut it, here.

Cheers,

George

In principle, I am in total agreement with you. Re-reading my post it doesn't look all that nice.

I quoted the 40% faster based on personal tests I made with database queries on a rather large (5Gb) database. This (in my opinion) is a good test of overall disk subsystem performance (if done on the same PC using different disks).

To be more specific and precice, in capturing (which in terms of the disk subsystem is a sequential raw data transfer, i.e. write), the reality is as follows:
Actual access times make little difference, as no random writes are done - typically. If the disk is heavily fragmented, access times make a difference, although the performance is going to be rather poor anyway.

On-disk cache makes little contribution, as large blocks many times as large as the on-disk cache are constantly written to the disk. Actually, a small disk cache might be prefferable - especially if the implementation is not clever.

System RAM makes little contribution, for the same reason as above, especially if one is capturing in the range of Gigabytes.

I offer you an objective benchmark that anyone can use: VirtualDUB's AuxSetup program. It includes a nice bechmark option. Use that to test sequential write and read of, say 500 Mb or more on a disk.

I tried this with my system's disks:

Disk Drive Write Speed Read Speed
C: 20Gb, 5000rpm 15,701Kbs 13,716kb/s
D: 75Gb, 5000rpm 18,974 26,193
E: 200Gb, 7200rpm 42,500 43,634
F: 200Gb, 7200rpm 45,637 46,878
G: 45Gb, 5000rpm 15,930 11,119 (this is my oldest disk)
H: 200Gb, 7200rpm 52,261 51,519

I must admit I was surprised by the results. The (older) 5000rpm disks can sustain a 17Mbps transfer rate on average. The newer 7200rpm disks can sustain 45Mbps averate transfer rate. This is practically 3x difference

All disks are formated with NTFS, are reasonably frequently defragmented (by copying the entire contents to another disk and then back - for safety) and the first 2 are connected to the on-board EIDE chipset controller while the 4 last connected to the on-board additional EIDE controller (all using UDMA-100 ribbon cable).

I would be most curious to see comparative results from other viewers.

And, as always, I am open to criticism.

Regards

[gmatov]

SaSi,

I'll have to probe deeper to offer any rebuttal but one.

That is an article, a sidebar, really, in Feb. 2004 PCWorld magazine, www.pcworld.com , an article by Scott Spanbauer, in "Test Center" that seems to lay to rest the defrag truism, you MUST defrag religiously, which is often preached here, "I defrag after every capture, works wonders, never a dropped frame!".

Maximum PC did similar tests with the 8 MB vs 2 MB cache drives, and found no to little speed advantage.

I will agree that some of those here will say even a little is better than what I had. But these are the same people who want a machine that will perform an endless loop in 3 seconds flat.

Cheers,

George

[proxyx99]

Although I agree with the principle, I'd say that defragging every 2 weeks should suffice if computer is used quite freq. I'd suggest testing the drive/partition be4 and after the defrag to determine performance levels as well as degree of its degradation if not defragged. Then, instead of defragging, run the test util. again from time to time to see how normal activity affects drive performance. This should give you an idea when, how often and what to defrag.
Large capture files are written quite contiguously so if a particular drive or part. is devoted to captures or storing large files then the need for defrag is quite substantially diminished. Storing video files on drive C: may be more problematic as there is usually a fair number of system related activities that cause higher defragm. level (system temp files, internet temp. files etc. etc.). In that case defragging may be req. more often.
I recommend testing the HD read/write speed from time to time to get a "feel" what and how affects its perf. May save a lot of time for unnecessary defrags as well as explain lots of perf. related questions.

[disturbed1]

Most disk benching apps are not accurate.

Here's what I get running V-Dub's with a 750MB test file.




Here's test reports from ATA100, SATA150, and U320 SCSI.


I just added a Seagate 120 8MB cache drive. It's ~0.02% faster than my 80gig 2MB cache Seagates. Maybe on paper it could be faster, but I sure don't feel any speed difference.

But going from 5400RPM drives to 7200 RPM, there's a difference. But there are slow 7200's and fast 5400's.

SaSi's 5400's are about as fast as some of my 7200RPM Maxtors

[WuphonsReach]

5400s also tend to run a lot cooler and usually quieter then the equivalent 7200rpm drive. (I capture to a 5400rpm WD 160Gb drive at around 9-10 Mb/s.) 5400s are great for putting inside of external firewire/USB enclosures, since those enclosures usually have poor ventilation and a 7200 will likely cook itself.

I'm old school, I don't put more then 1 device on an IDE cable.

[SaSi]

Some additional thoughts about capturing.

If you use a slow or Cpu intensive codec to save the AVI with, you might (will likely) get dropped frames constantly, as the cpu is choked.

If you don't use a video codec at all and save uncompressed video, especially at full DVD resolution, you might also get dropped frames as the bitrate requirement get's quite high

720pix x 576pix x 3bytes per pix x 25 frames per sec gives more than 30Mbytes per sec transfer rate requirement. A fast, unfragmented and empty (AND HUGE) disk will probably allow no dropped frames, but disks giving 15Mbps won't make it.

Finally, some (older now) disks had a peculiarity to stop writing every few hundreds of megabytes for a brief moment. A couple of years ago these disks would not allow smooth playback of video and were considered not multimedia compatible. Some disks that did not have this "problem" were branded "multimedia compatible" or "multimedia ready" or something. Such a disk will certainly drop a few frames every now and then, no matter how fast a CPU you have or how you have attached the disk on the system.

And YES, 7200rpm disks run hot. I have 4 extra fans in my system, besides the PSU and CPU ones.

And, @disturbed1, I really like your disk. "Too fast to measure"!!! What a perfomer...Although it's strange. All my disks appear to be faster during write compared to read (which I find a little strange...)