Q: Pro Tools and NFS volumes

[Guest]

Archived from groups: rec.audio.pro (More info?)

Hi there,

just a short question. Will Pro Tools 6 on Mac OSX (10.3) accept a
Volume mounted via NFS? AFAICS Digidesign doesn't write anything about
it, except that network shares aren't supported for realtime
operation, such as recording and playback.
I just read the official Pro Tools storage guide, and now even the
reference guide, but I couldn't find anything covering NFS mounts,
only a very sluggish comment on "transfer volumes":

"Volumes that are not supported by Pro Tools for audio playback, (such
as network share volumes or CD-ROMs) will be designated as transfer
volumes by default."

Has anybody managed to use a NFS Volume as "performance volume", after
all there are NO technical reasons why this shouldn't be possible.

TIA Daniel

--
Reformatting Page. Wait...

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

Daniel Hojka <drums@sbox.tugraz.at> wrote in news:410f8386$0$30786
$3b214f66@aconews.univie.ac.at:

> Hi there,
>
> just a short question. Will Pro Tools 6 on Mac OSX (10.3) accept a
> Volume mounted via NFS? AFAICS Digidesign doesn't write anything about
> it, except that network shares aren't supported for realtime
> operation, such as recording and playback.
> I just read the official Pro Tools storage guide, and now even the
> reference guide, but I couldn't find anything covering NFS mounts,
> only a very sluggish comment on "transfer volumes":
>
> "Volumes that are not supported by Pro Tools for audio playback, (such
> as network share volumes or CD-ROMs) will be designated as transfer
> volumes by default."
>
> Has anybody managed to use a NFS Volume as "performance volume", after
> all there are NO technical reasons why this shouldn't be possible.
>
> TIA Daniel
>

NFS is not as fast as a locally connected drive. NFS is not a very good
protocol for streaming data. I have never had good results in this area.
NFS has it's advantages, but streaming data isn't one. Now a SAN is an
entirely different matter.

r


--
Nothing beats the bandwidth of a station wagon filled with DLT tapes.

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

Rich.Andrews <spmaway@ylhoo.com> wrote:

> NFS is not as fast as a locally connected drive. NFS is not a very good
> protocol for streaming data. I have never had good results in this area.

Well, it depends a lot on the environment... if you connect a suitable
NFS server via GBit or better ethernet links, you get more than enough
bandwidth to serve the client. NFS works fine enough for streaming
audio up to many, many tracks if implemented right.

> NFS has it's advantages, but streaming data isn't one. Now a SAN is an
> entirely different matter.

Yes, but a SAN is pretty dumb most of the time, unless you have enough
budget to spend to build a larger one. In my particular case it is
planned as a solution for a smaller environment, where a server should
handle all the tasks from streaming to automated backup.

So - still the basic question - anybody here has some kind of experience
how Pro Tools will react when you face it with a NFS share?

Regards, Daniel

--
CPU needs bearings repacked

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

Daniel Hojka <drums@sbox.tugraz.at> wrote:
>Rich.Andrews <spmaway@ylhoo.com> wrote:
>
>> NFS is not as fast as a locally connected drive. NFS is not a very good
>> protocol for streaming data. I have never had good results in this area.
>
>Well, it depends a lot on the environment... if you connect a suitable
>NFS server via GBit or better ethernet links, you get more than enough
>bandwidth to serve the client. NFS works fine enough for streaming
>audio up to many, many tracks if implemented right.

It's not optimal, but if you throw hardware at the problem, it should be okay.

>> NFS has it's advantages, but streaming data isn't one. Now a SAN is an
>> entirely different matter.
>
>Yes, but a SAN is pretty dumb most of the time, unless you have enough
>budget to spend to build a larger one. In my particular case it is
>planned as a solution for a smaller environment, where a server should
>handle all the tasks from streaming to automated backup.

Don't forget outrageously large read caches!

>So - still the basic question - anybody here has some kind of experience
>how Pro Tools will react when you face it with a NFS share?

IF Pro Tools just uses read() and write() to do I/O, everything should be
fine. If, on the other hand, it's banging the raw device, it almost
certainly will not be. Try using truss (or trace, or ptrace or ktrace or
whatever OSX calls it) to look at the system calls during a Pro Tools session.
If it's pounding on /dev/rdsk* or the like, you probably have a big problem,
but if it's just using open(), it should work. Though it will be slow when
compared to direct-attached devices, of course.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

Scott Dorsey <kludge@panix.com> wrote:

> It's not optimal, but if you throw hardware at the problem, it should be okay.

Yeah the very least way of elegance Let's say the advantages
outweigh the cons by far.

> Don't forget outrageously large read caches!

Latency is always an issue when you put something like that together.
As long as you try to cut down the number of possible delay lines
(switches etc.) in such an environment, it's ok. And thanks to the
modern ATA raid systems 40MB/s is not to hard to achieve these days.

> IF Pro Tools just uses read() and write() to do I/O, everything should be
> fine. If, on the other hand, it's banging the raw device, it almost
> certainly will not be.

Thanks for your hint - but I ment more if volumes mounted via "-t nfs"
would appear as "performance drives" or if Pro Tools would classify
them just as "transfer drives" because of this special mount type.

I have no running system by hand, but to be honest I can't believe
they wrote their own I/O routine on top of the raw device. There would
be so many things that had to be taken care of (was that english?),
starting with user access to raw devices, that I really think they use
OSX I/O storage subsystem.

> If it's pounding on /dev/rdsk* or the like, you probably have a big problem,
> but if it's just using open(), it should work. Though it will be slow when
> compared to direct-attached devices, of course.

"Slow" is just a definition that is was made because of very special
assumptions, if I see this right. On the other hand, if all you need is
something like 8 tracks (which is about 1MB/s @24/44.1) and your NFS
share is capable of streaming something like 40MB/s in a worst case
scenario - even latency should be neglectable.

The only thing I am concerned about - how will Pro Tools react when
it sees a NFS share.

Regards and thanks for your thoughts,

Daniel

--
Daemon escaped from pentagram