On Nov 1, 2004, at 1:48 PM, Maurits van de Kamp wrote: > Firewire also reduces processor load compared to IDE but is much > slower. This > means that you could actually notice an increase of possible tracks > when > switching from IDE to firewire (depending on how much strain you have > on your > processor using plugins etc). The RPM count of the used drive doesn't > enter > into this; the firewire interface itself will usually be the > bottleneck. An > interface that has to send one bit at a time through a long cable will > always > be slower than an interface that pushes 32 or even multitudes through > a short > cable with high quality demands. The communication physics will > continue to > be improved for all 3 interfaces. > > Part of this comment is in error. RPM does make a difference in drive performance, whether the interface is SCSI, ATA, or FireWire. I apologize in advance for the lengthy explanation that follows, with some added explanation that may benefit the overall discussion about track-counts. RPM influences two aspects of drive performance, raw data rate from the platters to the drive electronics, and average rotational latency. A 15K RPM SCSI drive operating at the same areal bit density (a measure of data bits per unit area on the platter) as an ATA/SATA 7200 RPM drive will deliver 100% more bits to the drive electronics in the same amount of time. Furthermore it will take 1/2 as long on average for the heads to be in the right spot to make a read or write (this is the affect of rotational latency). DAW drive performance is affected directly by both performance characteristics. Rotational latency more or less controls how many chunks of audio can be pulled from the drive every second, whether the chunk is small or large (within reason. I am speaking of the difference between a 200 msec edit and a 2 second edit). It fact it is not uncommon for rotational latency to be the overriding factor in track-count performance when the edit densities are high, especially if the edited raw audio tracks are long (in this case 10s of seconds or minutes) to begin with. Proper caching is the only way to mitigate a rotational latency restriction. Data transfer performance seems to get all the attention but that is often misplaced upon the interface instead of the actual raw drive performance. In the ATA world we have yet to have a 7200 RPM drive break the 75MB/sec barrier, so even the "slow" ATA-100 interface that was state-of-the-art 3 years ago is adequate for current drives. SATA drives *do not* improve raw transfer performance, they merely provide more headroom for potential future data transfer speeds. Drives with large built-in caches (i.e. 8-16MB) can at times saturate an ATA or SATA interface but the effect is short lived, and real-world tracking performance is rarely helped by a hard drive's native caching. SCSI drives obtain the well-deserved reputation for high performance from three primary factors, of which the SCSI interface itself is only ancillary. The first performance increase is that SCSI drives operate at high rotational speeds, 2X *most* ATA/SATA drives. This improves rotational latency a factor of two as explained. The second is raw data transfer. The raw drive data transfer rates are often not scaled directly with rotational speed because the tradeoff in drive manufacturing to obtain the faster rotational rate is to use less areal density. Still the faster drives spit out raw data faster. The final advantage is that SCSI drives historically are high-cost/high performance so they are manufacturered with superior track-to-track and average seek times to the more consumer ATA/SATA drives. The difference is not quite 2:1 but it is close. This used to be a much bigger advantage than today when drive densities were smaller and fitting audio files often took greater than 50% of a drive's capacity. Now drives are large enough that with proper partitioning it is reasonable to restrict audio files to a mere 10% of a drive's capacity, which has the dual benefit of decreasing average seek times dramatically, and increasing raw transfer rates by virtue of using the faster, outer-most tracks of the drive. This last aspect can approach 100% on typical drives today, be it ATA or SCSI. SCSI's fast, parallel bus transfer rate *helps* smoothly move the data between the drive and the host but it is only able to affect the performance by not degrading what the drive does on its own. There is some reduction of processor loading over ATA, and there is some potential for having multiple drives working almost in parallel, but beyond that the only reason that SCSI drives are faster than ATA is that they rotate faster, and have less average seek time. FireWire 400 was faster than the fastest 3.5" 7200 RPM drives up until around 18 monts ago at which point the interface itself became the limiting factor. However FireWire 800 is more than fast enough for today's generation ATA drives - the fastest ATA/SATA drive has a *peak* transfer rate of around 65MB/sec, well below FireWire 800's effective transfer capcity of around 80 MB/sec. In a real-world multitrack audio editing task a faster rotating drive will out perform the slower one, regardless of whether it is on a FireWire bus or connected on the internal ATA/SATA bus, unless the multitrack project is the degenerate case of a lot of really long tracks with few edits. Likewise one could also put a higher density (i.e larger capacity with same number of platters) 7200 RPM drive than the stock G5 Dual 160GB drives in an aging PowerMac G4 (say a 733 MHz Digital Audio Model, almost 3 years old), and obtain greater track counts with the G4 than the G5, simply because the drive is spitting bits out faster. How many more tracks is very much a function of the specifics of the project being edited! One last point regarding to the test data being discussed and its apparent contradictory nature. Drive technology advances so that doubling in areal density occurs almost every 12 months. If I test performance with the latest drive I can buy today, and report the findings, they will be no longer valid when compared against the same computer performing the same test six months from now if the computer has the then current drive installed. Next, partitioning can have a *great* affect on the test results. The size of the partition, as a ratio of the total drive capacity, and if the placement is at the outer rim, can tremendously skew the results compared to a situation where the partition is say the entire size of the drive. Also the actual project test data has enormous affect on the outcome, enough that unless the same project is used for all tests the results are suspect. Finally, track-counts are somewhat a misnomer. Its not the number of tracks that are important but the number of simultaneous overlapping audio chunks that can be played, especially simultaneously started. In this regard it is better to think of it as track polyphony and structure your performance tests with that analogy in mind. drK