Subject: RE: [linux-audio-user] Submitted for your approval
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Mon Apr 07 2003 - 11:43:37 EDT
This response is now part of the 'very off-topic' nature of this thread.
Sorry, but as usual, my response below got a bit long. Typical for me I
suppose...
> -----Original Message-----
> From: linux-audio-user-admin_AT_music.columbia.edu
> [mailto:linux-audio-user-admin_AT_music.columbia.edu]On Behalf Of Steve
> Harris
> Sent: Sunday, April 06, 2003 12:44 AM
> To: linux-audio-user_AT_music.columbia.edu
> Subject: Re: [linux-audio-user] Submitted for your approval
>
>
> On Sat, Apr 05, 2003 at 04:13:28PM -0800, R Parker wrote:
> > I'm not sure how I'd manage the volume of production
> > that we do within any 24 hour period without hardware
> > scsi raid. And I don't care because anything else
> > would be penny wise but dollar foolish. I also don't
> > know anything about latency with raid. Perhaps it
> > applies only to kernel controled software raid. Ardour
> > includes a local/native raid 0 implementation that
> > shouldn't experience any computational latency.
>
> The latency in question is (I think) disk seek latency, which is unrelated
> the the kernel scheduling latency that we all sweat over reducing :) The
> potential problem is that something like ardour might be filling a
> fraction of the throughput, but the disks would be unable to respond in
> time.
>
Disk latency is what I meant also, however, with RAID controllers (of which
I'm no expert) there are potential additional latencies that show up because
of the work the RAID controller is doing. I don't think it matters whether
you use SCSI or IDE RAID for what I write next, although I expect the
'numbers' would be totally different.
Someone could educate me a bit, but I think when we talk of 'RAID' here,
we're mixing apples and oranges. There is 'RAID' which takes multiple drives
and makes them look like one larger drive. On this sort of RAID I do not
think the latency need be much larger in the worst case, and may actually
appear to be lower on the average case, since the seek time on the second
drive may be covered up by the data delivery time on the first drive. This
sort of RAID can improve apparent drive bandwidth. This is good, but
provides no redundancy which Ron requires for business safety reasons.
There is also 'RAID' which takes multiple drives and makes them look like a
single drive for safety purposes. This sort of RAID is almost always slower
(at least under Windows) than a standard single drive, since you are issuing
multiple, parallel, requests for the same data that exists on separate
drives, and then doing some sort of comparison of the data to ensure they
are identical. (Even if it's all done on the RAID card.) Some RAID cards (to
the best of my knowledge) don't return any data across PCI until they have
received the data from all of the drives and done their comparisons to
ensure it's good data. That's slower. Others return data from one drive
while waiting on the others, but then do not tell the system that the data
is there until they have checked it out. All of this can 'delay' the
application from getting an indication that the data is there, which is my
definition of 'latency' in this case.
Should there be a failure on a drive, then the system can go on running, but
extra cycles are used to inform the system that the drive has gone bad and
repairs are necessary.
As I understand Ron's need, he's using RAID for safety, not bandwidth, but
either way there are extra delays in the system. Nothing comes for free...
I don't think this has to matter much, in Ron's case, for the musicians
since he mixes from a console and not from the computer. As I understand his
setup, Ardour is just recording and delivering audio data. However, I do
wonder how these latencies show up between a track that was recorded by
itself, and then played back. The musician doesn't know that the first track
is coming off the disk earlier, and that his new recording is going on the
disk later, so the two should be out of sync by 2*latency, I think.
Additionally, there is some small latency through the console and the
A/D/D/A and all. Does Ron have to nudge this stuff to get it all back in
sync?
Cheers,
Mark
This archive was generated by hypermail 2b28 : Mon Apr 07 2003 - 11:58:58 EDT