Subject: Re: [ecasound] Simultaneous disk read & write
From: martijn (mlina_AT_dds.nl)
Date: Thu Nov 29 2001 - 18:49:39 EET
Once upon a Wed, Nov 28 2001, J. Gareth Williams hit keys in the following order:
>
> Let's say I'm playing back a file, while recording to another one. Is
> there an advantage of using separate disks for reading and writing? I
Depends on your setup i think. In my case, i can use 10 outputs but just 2
inputs, so i'm thinking of using a software (striping) RAID partition across
my two disks, which will give me twice as much bandwidth. If you usually use
the same amount of inputs and outputs, i think your idea could be benifitial,
as long as the disks are on separate controllers. If both are on the same
controller, they can't be used in parallel.
> 1. I presume that IDE disks can only be given one DMA task at a time;
> but with a separate read & write disk, each can be processing one
> request at a time.
Some IDE disks are featured with tagged command queuing (although i don't
know if Linux takes advantage of that, FreeBSD does). The only ones i know of
are the IBM DPTA and DTLA drives. This feature optimizes the order by which
the commands are executed for better I/O performance. Don't know if that
would disturb low latency applications, but with ecasound's double buffering
feature this could be no problem.
> 2. Head movement. If you're switching back and forth between reading
> and writing, your disk head is going to be moving back and forth a great
> deal between the two operations, resulting in a longer seek time. With
> separate disks, consecutive reads (or writes) will tend to involve
> shorter seek times, and therefore higher throughput.
That's true, but if you're recording/playing multiple tracks, the disk would
be head banging as well. It's also better to put your audio partions physically on
the outer tracks of the hard disk. in that area the data comes by faster.
martijn
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Nov 29 2001 - 18:43:21 EET