Hard drive enclosures.

T

track pusha

New member
Firewire works fine. Ideally an internal drive would be better but a firewire drive works. I've been using one as my audio drive for over a year now and i have noticed no detrimantal changes as compared to my other studio computer with a RAID setup. Best part is when you get a new computer you just plug and go. All your project files are where they should be.

As for hard drive don't get anything lower than 7200 RPM.
 
OK, a question from a computer tard. What exactly is the noticeable difference between a 2MB and 8MB cache? Do you need the 8 for recording audio?
 
The reason that the hard disk's cache is important is due to the sheer difference in the speeds of the hard disk and the hard disk interface. Finding a piece of data on the hard disk involves random positioning, and incurs a penalty of milliseconds as the hard disk actuator is moved and the disk rotates around on the spindle. In today's PCs, a millisecond is an eternity. On a typical IDE/ATA hard disk, transferring a 4,096-byte block of data from the disk's internal cache is over 100 times faster than actually finding it and reading it from the platters. That is why hard disks have internal buffers. :^) If a seek isn't required (say, for reading a long string of consecutive sectors from the disk) the difference in speed isn't nearly as great, but the buffer is still much faster

I pasted this so don't think I'm real smart.
 
pdadda said:
OK, a question from a computer tard. What exactly is the noticeable difference between a 2MB and 8MB cache? Do you need the 8 for recording audio?
Click to expand...

but those arent the drives, those are firwire enclosures, you put internal drive in the enclouse and hook it to the pc firewire
 
HogansHiro said:
The reason that the hard disk's cache is important is due to the sheer difference in the speeds of the hard disk and the hard disk interface. Finding a piece of data on the hard disk involves random positioning, and incurs a penalty of milliseconds as the hard disk actuator is moved and the disk rotates around on the spindle. In today's PCs, a millisecond is an eternity. On a typical IDE/ATA hard disk, transferring a 4,096-byte block of data from the disk's internal cache is over 100 times faster than actually finding it and reading it from the platters. That is why hard disks have internal buffers. :^) If a seek isn't required (say, for reading a long string of consecutive sectors from the disk) the difference in speed isn't nearly as great, but the buffer is still much faster

I pasted this so don't think I'm real smart.
Click to expand...

Depending on how you read that last sentence, what you posted is either exactly correct or completely backwards. If you have to seek, a cache doesn't usually buy you anything. Usually the track cache buffer in a drive keeps a cache of anywhere from one track to a handful of tracks as an entire track.

If your computer requests one block, the drive seeks to the track containing that block and reads the entire track, then returns just the block the computer asked for. If the computer later asks for another block on the same track, the drive doesn't have to wait for the head to fly around to the right spot in the rotation. It can simply return the data instantly from the buffer.

For consecutive reads, if the bus were fast enough, one could do that without caching and catch the next block... maybe.... There was some floppy hardware that could usually do this back in the day.... That said, you'd still often miss the next block and have to wait for the head to go all the way around, hence the reason for buffering. Sequential read (without interleaving) is actually the worst case performance for unbuffered drives, simply because by the time the data from the first block gets back to the machine and is processed, the sync bytes for the next block have invariably already flown past the heads. :D (Yes, I've written floppy disk drivers. How could you tell?)

That said, most operating systems do read-ahead if they detect a linear pattern to the data requests, along with read/write clustering and other tricks, making the effect of the drive cache largely superfluous, particularly since it is much slower than a cache within the system's RAM, and is also inherently much smaller. If you really need that very last inch of performance, the 8MB buffer might make a little difference, but... quite honestly, I'd be surprised if it made enough difference for most people to care except in very specific (and borderline pathological) access patterns.
 
HogansHiro said:
Firewire works fine. Ideally an internal drive would be better but a firewire drive works. I've been using one as my audio drive for over a year now and i have noticed no detrimantal changes as compared to my other studio computer with a RAID setup. Best part is when you get a new computer you just plug and go. All your project files are where they should be.

As for hard drive don't get anything lower than 7200 RPM.
Click to expand...

Depends on your DAW. Some DAWs are more sensitive to latency than others. If your DAW is latency-sensitive, a Firewire enclosure is the kiss of death. Of course, one could legitimately consider such DAWs to be severely broken, but I've seen one that literally tries to read the data at the very last possible moment, doesn't cache ahead at all, and when the read request takes an extra few microseconds because filesystem metadata got flushed from the OS's buffer cache due to memory pressure, the DAW utterly chokes.

Watch the data rate indicator on a high-end firewire enclosure. If your audio app sits for several seconds at 0k/second, then suddenly jumps to 38MB/sec. and a tenth of a second later, your audio stutters... well, you're probably using the same DAW I used to use (which will remain nameless, because I'm not quite that desperate to shame them into fixing it yet...).

That's why my dual G5 has 1.5 Gigs of RAM. My new DAW would probably work just fine in 256M, but I still have a few legacy projects I'm finishing in the old one.... Grrrrr....

Yeah. I've also done some quick-and-dirty performance analysis on certain pieces of audio software that I own. How could you tell? :D
 
dgatwood said:
Depends on your DAW. Some DAWs are more sensitive to latency than others. If your DAW is latency-sensitive, a Firewire enclosure is the kiss of death. Of course, one could legitimately consider such DAWs to be severely broken, but I've seen one that literally tries to read the data at the very last possible moment, doesn't cache ahead at all, and when the read request takes an extra few microseconds because filesystem metadata got flushed from the OS's buffer cache due to memory pressure, the DAW utterly chokes.

Watch the data rate indicator on a high-end firewire enclosure. If your audio app sits for several seconds at 0k/second, then suddenly jumps to 38MB/sec. and a tenth of a second later, your audio stutters... well, you're probably using the same DAW I used to use (which will remain nameless, because I'm not quite that desperate to shame them into fixing it yet...).

That's why my dual G5 has 1.5 Gigs of RAM. My new DAW would probably work just fine in 256M, but I still have a few legacy projects I'm finishing in the old one.... Grrrrr....

Yeah. I've also done some quick-and-dirty performance analysis on certain pieces of audio software that I own. How could you tell? :D
Click to expand...

the specs of my daw are p4 3.0 chipset 915, 1gig of ram, and a 80gb hard drive. do you think this will be fine.
 
You must log in or register to reply here.
Back
Top