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@xxxxxxxxxxxxxxxxxx > [mailto:linux-audio-user-admin@xxxxxxxxxxxxxxxxxx]On Behalf Of Steve > Harris > Sent: Sunday, April 06, 2003 12:44 AM > To: linux-audio-user@xxxxxxxxxxxxxxxxxx > 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
