How About Solid State?

[Craig F]

Originally Posted by hear-this

Is anyone using a SSD as both a systems drive and a recording drive?

I was told that it isn't important to record to a separate drive if you're using SSD's because the original limitation was due to head scanning (which doesn't happen in SSD's). Since this is for my laptop rig, it'd be great to be able to stably record 16-tracks without requiring a second drive.

Any info, experience?

Thanks!

Wear Leveling kills write times
disquesed in this pod cast http://www.pro-tools-expert.com/home...odcast-50.html

I would not do it to the System Drive

[hear-this]

Originally Posted by Craig F

Wear Leveling kills write times

I have a feeling that this is very valuable information...but I don't really understand it

Originally Posted by Craig F

I would do it to the System Drive

You would do what to the System Drive? Record to it?

[Craig F]

Originally Posted by hear-this

I have a feeling that this is very valuable information...but I don't really understand it



You would do what to the System Drive? Record to it?

I would not record to the system drive
I have seen Pro Tools lock up and overwrite the System Folder when recording to the system drive

[Bill Denton]

Originally Posted by Craig F

I would not record to the system drive
I have seen Pro Tools lock up and overwrite the System Folder when recording to the system drive

Although Avid has never confirmed it, but I am reasonably certain that they were doing "direct disk access", instead of accessing the drive through the operating system. This was common practice back when we were using older, slower drives, as it allowed for slightly better disk performance.

It appears this practice was discontinued with the advent of Pro Tools 9.

When using "direct disk access", an application essentialy takes full control of the disk drive. This would be why Pro Tools was not approved for use with RAID drives, as RAID uses a "proprietary" controller, and Pro Tools would not be able to directly control a disk.

If an application is using direct disk access and another application writes to the disk via: the operating system, it would be very easy for a disk to get "scrambled".

However, as it appears that Pro Tools is now accessing the disk via: the operating system, the "scrableling" possibility no longer exists.

Note: The following is based on my own knowledge of computers (I work in IT), combined with my less demanding sessions, and my ability to take a certain amount of risk. YMMV...proceed at your own risk!

I would not be afraid to use a fast SSD as both an OS and a recording drive. As has been noted, there is no mechanically moving "head" with an SSD, so it should be able to perform quite well.

Depending on the computer's power and the disk's performance, I would be willing to try using a modern spinning drive for both an OS and a recording drive. However, I would do quite a bit of testing before using this setup for mission-critical work.

The "wild card" in this thing is the new hybrid drives, such as Apple's "Fusion Drive". While I wouldn't have a problem using it as an OS drive, from what I have read about it I would be somewhat leery of using it as a recording drive until a lot more "field reports" come in.

Again, these are just my "somewhat educated" opinions...YMMV...try this at your own risk, and if you're working for money test the hell out of whatever options you decide to try...

[CME]

And don't forget SSD's do have a lifespan. They can only be written to so many times (as with any disk, but SSD's are still relatively new and unproven). So recording to one will shorten it's life. Will it be enough to matter? I can't say. Just be sure and back up as often as possible. Regardless of which medium you're recording to.

Which brings up one more point. Spinning discs tend to give warning before failing. From what I've read SSD's just stop functioning. Much less warning. Again not trying to scare anyone away, just be aware of the situation.

[sunburst79]

Originally Posted by Bill Denton

Although Avid has never confirmed it, but I am reasonably certain that they were doing "direct disk access", instead of accessing the drive through the operating system. This was common practice back when we were using older, slower drives, as it allowed for slightly better disk performance.

It appears this practice was discontinued with the advent of Pro Tools 9.

When using "direct disk access", an application essentialy takes full control of the disk drive. This would be why Pro Tools was not approved for use with RAID drives, as RAID uses a "proprietary" controller, and Pro Tools would not be able to directly control a disk.

If an application is using direct disk access and another application writes to the disk via: the operating system, it would be very easy for a disk to get "scrambled".

However, as it appears that Pro Tools is now accessing the disk via: the operating system, the "scrableling" possibility no longer exists.

Note: The following is based on my own knowledge of computers (I work in IT), combined with my less demanding sessions, and my ability to take a certain amount of risk. YMMV...proceed at your own risk!

I would not be afraid to use a fast SSD as both an OS and a recording drive. As has been noted, there is no mechanically moving "head" with an SSD, so it should be able to perform quite well.

Depending on the computer's power and the disk's performance, I would be willing to try using a modern spinning drive for both an OS and a recording drive. However, I would do quite a bit of testing before using this setup for mission-critical work.

The "wild card" in this thing is the new hybrid drives, such as Apple's "Fusion Drive". While I wouldn't have a problem using it as an OS drive, from what I have read about it I would be somewhat leery of using it as a recording drive until a lot more "field reports" come in.

Again, these are just my "somewhat educated" opinions...YMMV...try this at your own risk, and if you're working for money test the hell out of whatever options you decide to try...

Your correct about drive access. Some one from Digi posted about the fact they were using Direct Disk Access or something analogous to it several years ago. It may have been a proprietary algorithm. I have no idea if it was changed in PT9 or not.

[Darryl Ramm]

Originally Posted by Bill Denton

Although Avid has never confirmed it, but I am reasonably certain that they were doing "direct disk access", instead of accessing the drive through the operating system. This was common practice back when we were using older, slower drives, as it allowed for slightly better disk performance.

It appears this practice was discontinued with the advent of Pro Tools 9.

When using "direct disk access", an application essentialy takes full control of the disk drive. This would be why Pro Tools was not approved for use with RAID drives, as RAID uses a "proprietary" controller, and Pro Tools would not be able to directly control a disk.

If an application is using direct disk access and another application writes to the disk via: the operating system, it would be very easy for a disk to get "scrambled".

However, as it appears that Pro Tools is now accessing the disk via: the operating system, the "scrableling" possibility no longer exists.

Note: The following is based on my own knowledge of computers (I work in IT), combined with my less demanding sessions, and my ability to take a certain amount of risk. YMMV...proceed at your own risk!
[/I]
/snip/

There is really no such thing as "access a disk directly" by bypassing the operating system that could be applicable to Pro Tools.

These disks have mounted file systems, you can't write anything to the underlying disk without going through the filesystems or you will corrupt that filesystem.

Even if a disk had its filesystem unmounted to allow a program to write to the raw (block) device the applciation software would not have to be fully aware of the specific filesystem data structures to read to or write to that volume. If a program just tried to naively use block level IO (e.g IO to the disk at the layer below the filesystems) that would again corrupt the filesystems, but even doing that is using huge part so of the operating system to write to disk. Bypassing the OS entirely to write to a disk would be a horrible mess involving dealing with the low-level SATA controller from user space, having to install a custom driver or jump around doing unnatural IO stuff in user space, not something any sane developer would ever do (and again even if you wanted to its is not something you could do on a mounted filesystem).

There are various flavors of advanced IO enhancements that different operating systems offer to provide better IO performance for demanding applications, various types of async IO (non-blocking disk writes) and various direct IO critters like F_NOCACHE/FILE_FLAG_WRITE_THROUGH etc. (various ways to bypass the disk buffer write cache--possibly at a decrease in performance when done to guarantee committed writes, or to allow applications to better manage their own buffer cache than using the general filesystem/OS cache--and Pro Tools probalby does not want to do that, since it can't afford to sacrifice much of its limited 32 bit address space, and I'm not sure it would pay off much if at all) type capacities, but none of these are really "bypassing the OS". There is also mmap and direct_map and other friends, ways of implementing stared memory via a file like interface, again nothing to do with bypassing the OS. And again I have no idea if Pro Tools uses any of these mechanisms (well I do in some cases, Pro Tools does occasionally call mmap() on OS X, I suspect that is to support the preferences databases, easy to check I just have not peeked far enough.)

The Direct IO type accesses might be what some people might mean by "direct disk access" but I'd be surprised if Pro Tools has historically used this for a variety of reasons, including it can decrease performance, and various aspects of poor cross-OS support.

There is an awful lot that application software can do to optimize IO, and that is the kind of stuff I expect Avid has optimized in recent IO changes, things like how it buffers the IO, when to read/write data and at what blocksize and when and how often the application decides to call the operating systems to write those blocks, separate read or write buffers the applciation might maintain, how the IO is multi-threaded, whether its worth using options like async or direct IO, etc.

I have no idea what Pro Tools is doing at a low level or what recent IO optimizations have occurred in Pro Tools 9 or 10. Especially on OS X the operating systems has beautiful low level strace based debug/tracing tools but Pro Tools unfortunately disables those (needed to prevent easy hacking of iLok licenses), not that is an absolute barrier, but I won't go there.... Anyhow my point is whatever Pro Tools is doing it is really not "bypassed the OS to write to disk".

I suspect issues with RAID storage and Pro Tools, may more just be the high variance of IO response times that some RAID systems provide. Maybe combined just with old code just not well optimized to take advantage of the performance of modern high-performance drives.

Darryl

[Darryl Ramm]

Didn't take to long to think about this to know what I wrote above was wrong in part, and so to correct that a bit...

Prior to Pro Tools 10, Pro Tools maintained a DAE disk playback buffer. Because the audio files ultimately exist on a filesystem Pro Tools can't bypass the filesystem, its either implementing this DAE buffer as a double cache on top of the usual file system cache or using the O_DIRECT/ F_NOCACHE/FILE_FLAG_WRITE_THROUGH type semantics to bypass the OS'es filesystemms cache (that would bypasses the cache (if used), but not all the other filessystem overhead/goodness. it might be somewhat spitting hairs, but Pro Tools really is not bypassing the operating system or 'writing direct to disk', except in the sense that it *might* (I have no idea here if it was) have been bypassing the filesystem buffer cache.

I just guess whatever they were needing to do to support old slow disks is no longer needed and they implemented a much cleaner IO subsystem (which hopefully involved more use of the general filesystem cache that lives outside the currently precious 32 bit process address space).

Anybody from Avid or elsewhere please feel free to correct... I'm not spending hours trying to mess with debuggers to look at IO systems calls.

Darryl

[chrisdee]

Originally Posted by CME

Which brings up one more point. Spinning discs tend to give warning before failing. From what I've read SSD's just stop functioning. Much less warning. Again not trying to scare anyone away, just be aware of the situation.

Im guessing the warning would probably be a slow SSD disk.

However, I'v had SSD as my system disk since 2009 and it's not showing any signs of slowing down yet. If you open Windows resource monitor and check the Disk tab you will se that there are many processes constantly writing to the system disk at any time. I'v been monitoring for a while now and I can se that windows writes just as much as it reads to the disk.

To me weither a disk last 7 years or 10 years doesn't matter. Most likely all my disk are changed within 7 years anyway.
Performance and reliability are most important. I dare say todays SSD's are just as reliable as spinning disks. Atleast thats my experience.

The drawback is the price.

[Mike Thornton]

Wear Leveling kills write times
disquesed in this pod cast http://www.pro-tools-expert.com/home...odcast-50.html

Thanks for the shootout on our podcast. My biggest concern is the direction of travel. As we discussed in Podcast 50, with reports from the EBU (European Broadcasting Union) and Tech Review about the suitability of SSD drives as audio media drives. Even though Avid have quietly announced on their hard drive compatibility page that they have approved SSD drives for both system drives and audio drives, our advice is to use SSD drives for your system drive but not for audio drives.

The benefits of SSD drives are that they can retrieve data very quickly because you don’t have to wait for the heads to get to where the data is on the disc, but there has been a limit to how fast they can deliver data in a stream or how fast they can write data, and there is a limit on the number of reads and write to each sector on the drive. Also they deteriorate with age and use. The EBU did some experiments and their findings were that for an audio drive SSD didn’t cut it over time, yes with a brand new drive in ideal conditions they were great but over time their performance deteriorated and once a sector has reached the maximum number of writes (between 10,000 and 100,000 depending on the type of chips used in the SSD) it can no longer be used. So for a system drive there are definite benefits but for audio drives, not yet would be our continuing advice. Although they would make good sample playback drives as they can retrieve data very quickly.

We need to lobby the drive manufacturers to develop SSD drives that will work reliably and have longevity for our kind of applications.