CDogg,
First, I agree with your statement:
"...with as cheap as they are nowadays, it hardly makes sense not to get it"
That being said.....
As far as some of the comparisons go, I think people
might be comparing drives which have different uncached transfer rates, then attributing the differences to the cache (in error). For each link you listed I tried to verify this theory (using the WB99 Disk/Read Transfer Rate - Begin benchmark from storagereview.com), but the articles either do not list exact model numbers, or use models which are not in storage review's database.
In this quote:
Oh yes, and one significant test:
- At the pcextreme site above, you'll see that a WD1200JB outperformed two Maxtors in a RAID 0 array. Its sequential read was 57MB/s while the Maxtor array hit only 47MB/s.
Please look at that link again - the exact opposite is true, the RAID array has the 57 MB/s sequential read, the single drive has the 47 MB/s read. The article goes on to say:
Even though the RAID array beat the WD1200JB in buffered and sequential read times....
Again because we don't have an exact model number (we only know they are 7200 RPM) of the Maxtors (or the model number of the RAID device) we can't make this comparison meaningful by comparing unbuffered transfer rates and other attributes of the drives -- although I will grant you that the similar benchmarks are very suspicious considering the Maxtors are in a RAID 0 array!!!!!! That being said, I think it rash to attribute the benchmark
differences to the onboard cache.
For a test which really compares based on cache only, check this out:
These are 2 WD drives from the same line, which should differ only by the size of the cache (8 MB in the JB, 2 MB in the BB). In the WB99 Disk/Read Transfer Rates - Begin and End, the only benchmarks worth noting for streaming drives in an A/V setup, the differences are small enough to be irrelevant. The big differences are where I predicted them to be: day-to-day OS/app. use (represented by SR Office, SR Bootup, SR Gaming, individual application tests, etc.). The 10 MB/s. improvement in Sound Forge 4.0 at first seems to contradict what I'm saying, until you realize that Sound Forge is a simple stereo editor, not a multitrack audio editor that has huge streaming requirements - that is, its disk usage is going to mock typical applications more than a true heavy duty A/V application.
This quote:
"As far as buffering is concerned, random access reads, such as when reading in many small files, does NOT benefit in speed from larger on-drive caches. That cache is used mostly for multi-block read-ahead and write-back on sequential accesses, and is usually segmented into "areas", where sections of cache memory are linked to sections (cylinder groups) of the platters. The more cache you have on the drive, the less "thrashing" the drive has to do when many disperse files are written to, since it can group many operations into their appropriate "areas" of cache. This doesn't help as much for random reads (like maildir!) as for sequential reads."
is very interesting, but A/V should not be writing to "disperse areas" or "thrashing" very often. Cakewalk Sonar, for one, lines up audio tracks in a given project (at least as they are recorded) to best optimize multitrack playback - rather than stack each track up by itself on the disk, all tracks are split up and chunks are stacked together by their absolute time in the project - meaning the disk thrashes very little when playing all tracks of a song from beginning to end. The editor over at Prorec.com keeps telling people NOT to defrag their audio drives for this reason, and people want to argue with him all the time (defragging the OS disk is great, but doesn't apply to the audio drives when using a program that lays the tracks down correctly). Now his stock response is "take it up with the developers at Cakewalk."